Edits omgeving Staphorst

Dag Gerrit,

Zit deze data nu alleen in de umap? In openstreetmap.org kan ik het niet terugvinden?

Dick, er zijn al plaatsen waar men bezig met die highway:area. Of het echt populair gaat worden weet ik niet.
Verbinden met bestaande polygonen wordt makkelijker gemaakt via de JOSM plugin: ContourMerge

Het gebruik van contourmerge vindt ik ten opzichte van BGT een zeer slechte zaak ( niet doen), de import en conversie moet zo wezen dat het precies op zijn plaats ligt en dan andere kunnen aansluiten. Alles moet al kloppend zijn bij import, zo niet dan doen we iets fout. Want de data is kloppend. 1 bron/1 uitkomst.

http://overpass-turbo.eu/s/hrT

https://www.openstreetmap.org/way/430493818#map=18/52.63354/6.23020
landuse=residential industrie terrein
rose landuse=industrial groot vlak, daarbinnen landuse=residential

https://www.openstreetmap.org/way/432065268#map=17/52.60891/6.16356
name PandOntwerp, misbruik name tag
pand is building, dan ga je geen landuse gebruiken.

een bouwkavel, heeft geen name
http://www.openstreetmap.org/way/432066334
landuse binnen landuse


En andere:
Dubbel landuse gebruik, waarom schijnbaar om de erfscheidingslijntjes zichtbaar te maken.

Zie area en highway tag en de validation, …
Dit zijn alle problemen van eerste link overpass en validatie.

Als er niets aan de manier van importeren van Gerrit gedaan wordt, is het einde zoek.

Voor iemand die de wereld als rond ziet, heb je een opmerkelijk vierkant gedrag…

Gerrit Dankelman is weer actief.

Ik heb twee changesets reverted:

  1. tekent landuse=industrial in terwijl dit slechts plannen zijn en overlapping areas
  2. tekent een gebouw in met landuse=residential en name=PandOntwerp

Ik heb mijn reverts in de comments op de changesets op de kaart in het engels geschreven; dit op verzoek van de DWG.

Verder: ik heb geen zin, mochten zijn edits zich weer massaal in de verkeerde richting begeven om alleen de fouten te herstellen; ik zal botweg de gehele changeset reverten.

http://www.staphorst.nl/inwoners/actuele-berichten_42822/item/staphorster-ambachten-straatnamen-nieuw-bedrijventerrein_124534.html

Gerrit,

Er bestaan op de wereld een aantal types mensen, pak eruit wat je eruit wil pakken.
Probeer te relativeren hierin. Ik kan me voorstellen dat je je best in bepaalde gedragsregels kunt comformeren.

Ik ben het eens met de reactie die Martin net heeft geplaatst.
.
PS,
Ik heb een reactie (lees: een vraag) geplaatst op de aangemaakte note door gerrit_dankelman.

Industrieterrein is gereed, kavels zijn allemaal uitgegeven en de Gemeente heeft het de naam Bullingerslag gegevens http://www.openstreetmap.org/way/431833012

Gerrit,

Het is nog steeds een zooitje: overlappende landuses, geen gebruik van multipolygoonrelaties.

Ga ja dat nog aanpassen?

Martin, Multipolygon is geen goede toepassing van modellering van de werkelijkheid. Polygonen hebben door de lokatie al een relatie, deze hoeft niet specifiek gemaakt te worden, is tevens moeilijk onderhoudbaar. https://twitter.com/geoinformatie/status/686538362199633920

Eh…ja. Want in werkelijkheid is het onmogelijk dat een plas water volledig omgeven wordt door bv. gras.
En twee lijnen over elkaar heenleggen is daarentegen wel goed onderhoudbaar?
Oh wacht… in jouw voorbeeld liggen ze niet over elkaar maar zit er zelfs nog een strookje “niets” tussen. Jammer dat je de nodes er niet bij hebt getekend.

Maar ik vind het prima. Maak een proposal op de Wiki en zie of je meer mensen kunt overtuigen zou ik zeggen.
Tot die tijd werken we bij OSM met multipolygons, goed?

I’m with Gerrit :slight_smile: Het grootste probleem van OSM zijn de editors die nogsteeds niet goed kunnen omgaan met een van de meest fundamentele en bijzondere features van OpenStreetMap: het feit dat je gratis en voor niets nodes kunt hergebruiken. Als men dan ook conceptueel begrijpt dat vlakjes thematisch gezien onderdeel zijn van een aansluitende ondergrond vallen er geen gaten in een landuse.

Verder ben ik sowieso tegen importeren :wink:

Ik weet niet of ik je ironie goed kan plaatsen, maar:

Het zijn niet de editors die het gebruik van MP’s voorschrijven.

Persoonlijk begrijp ik ook niet waarom je voor een simpel topologisch geval als een eiland in een meer, een parkeerplaats in een bos toch een MP nodig hebt.
Maar: als je bijv. een parkeerplaats in een bos zonder MP mapt zie je in Mapnik de getekende boompjes ook op de parkeerplaats nog.

Dit is dus editor-onafhankelijk!

Dit aanpakken of vereenvoudigen dient via de geëigende routes te gebeuren en niet door anarchie. Er lopen voldoende discussies hierover, maar zolang het ei nog niet gelegd is…

Maar ik kan het mis hebben.

Ho ho, nu gebruik je zelf dus een taggen-voor-de-renderer-argument. Het zou jou als editor echt helemaal niets uit moeten maken wat mapnik doet, tenzij je actief betrokken bent bij een tileserver. Indien dat lataste het geval is schiet je een incident in bij de cartogafie boys en girls, maar ga je niet de multipolygon-edit-religie propageren.

OpenStreetMap blijft een do-ocracy. Als Gerrit volledig los wil gaan op highway area’s, dan zou ik zeggen: dat moet je faciliteren. Er komt alleen een belangen verstrengeling. Want naast mensen die kaartjes maken zijn er ook mensen die routeplanners maken, en zullen er vast ook nog wel andere toepassingen zijn die de OpenStreetMap DB gebruiken. Dat maakt free-style editen lastig.

Om een concreet voorbeeld te geven waarom ik Gerrits topologie verreweg suprieur vind aan multipolygons: als ik een routeplanner maak die area’s ondersteunt zal ik voor multipolygons alle arbeid moeten verrichten [zodat er routes ontstaan] die Gerrits single-line-topology al voor me heeft gedaan. Zelfs dan is dat gerealiseerd door een algoritme en niet door een mens die begrijpt hoe topologien er uit zien.

Highway area’s gaan het voor routeplanners ook nog knap lastig maken, want je zult iets met hartlijn extractie moeten doen. Of zeer elegante manieren moeten vinden om surface routing toe te gaan passen. Dat kan, in plaats van lijn naar lijn best van vlak naar vlak. Toch is het een compleet andere benadering [gegeven de OpenStreetMap structuren] dan nu.

Als ik in de relation wiki lees:

“However, this model only works for areas the outline of which consists of one single way, and which do not have holes. Any area that is more complex than that (e.g., because its outline consists of several ways joined together, or because the area consists of multiple disjunct parts, or has holes) requires a multipolygon relation.”, dan hou ik me daar aan.

Dat is niet taggen voor de renderer; dat onjuist getagd een verkeerde (standaard!)rendering oplevert is slechts een onderbouwing.

En een mooie term hoor; do-ocray, maar we hebben in OSM democratisch regels afgesproken en als je die eigenhandig bewust meent niet te respecteren dan noem ik dat anarchie.

Maar ik kan het mis hebben…

De laatste keer dat ik de highway area proposal heb bekeken heb ik toch echt begrepen dat dat niet bedoeld is om te routen.
De highway=xxx blijven gewoon als lijntjes bestaan voor routers, maar het idee was om deze niet meer te renderen als ze bovenop een highway area liggen.

Het grote voordeel van een highway als area is dat je ze dan weer aan de overige landuse kunt koppelen zonder “gaten”. Bij highway als ways is het niet de bedoeling om ze te koppelen aan de omliggende landuses. Maar als je echt een mooie topografische kaart wilt maken zijn “gaten” erg onwenselijk.

Ik kan zeker wel wat met het idee One String Polygon van Gerrit als hij bedoelt dat de ways over elkaar heenliggen (ik tenminste neem aan dat hij bedoelt dat er op de hoekpunten van bijvoorbeeld C maar 1 node staat, en ik neem aan dat de 2 naast elkaar liggende rode lijntjes in werkelijkheid over elkaar liggen en nodes delen).

Zoals Stefan de Konink, al aanhaalde “OpenStreetMap blijft een do-ocracy. Als Gerrit volledig los wil gaan op highway area’s, dan zou ik zeggen: dat moet je faciliteren. Er komt alleen een belangen verstrengeling. Want naast mensen die kaartjes maken zijn er ook mensen die routeplanners maken, en zullen er vast ook nog wel andere toepassingen zijn die de OpenStreetMap DB gebruiken. Dat maakt free-style editen lastig.”
De laatste stelling komt ook recht uit mijn hart, ik krijg af en toe de indruk dat de database en de weergave ondergeschikt is aan de routing. Je kunt geen wegvak meer omleggen wijzigen en dergelijke of je hebt of krijgt last met een route. Ik bouw geen routes maar wel een kaart en zie daarmee routes als hinderlijk. “Leg die in een ander level, zodat je er als je op of aan de basis werkt geen last van hebt of krijgt.” :wink: Je wilt tenslotte ook geen blijvende schade aanbrengen er zijn al genoeg routes, die als incompleet te boek staan.

Volgens mij bedoelde Stefan niet routes als in route-relaties, maar gewoon routes die een routeplanner dynamisch maakt via highways.
En wat ik al zei, volgens mij hoeft het een het ander niet te bijten.