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 
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 
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.” 
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.
Ik bedoelde inderdaad geen relaties. Relaties maken mijn leven vreselijk moeilijk Wat ik doen is zeg maar de topologie trekken uit OpenStreetMap. Wellicht is dat ook wel eens leuk om op een mappingparty te laten zien, dat geeft ook direct weer wat je nodig hebt om lekker data te koppelen met OpenLR.
Hebben we al ontdekt dat er een “Gerrit Dankelman” is met een LinkedIn account ?
Skills
FME ICT Spatial Analysis GIS ArcGIS etc, etc
Is dat dezelfde ???
Lees met maar wel een serieuze ondertoon:
Op de kleuterschool snapte ik al niks van dat ‘kleuren tot de randjes’. En op de lagere school begreep ik niet waarom ik wolken moest tekenen, want het papier was toch al wit? Het zal dan ook niet verbazen dat ik mijn heil zocht op de kunstakademie waar het begrip ‘negatieve ruimte’ bestaat: je kunt een vorm ook definiëren door de ruimte er omheen te definiëren.
Anders gezegd: als een area omgeven is door andere area’s is het daarmee geen gat meer. Dus als een highway al omgeven is door gras, bos of ander gebied hoef je er geen area meer aan toe te voegen.
Niet mee eens. Een highway is namelijk maar een lijntje en wordt door de meeste renderers met een een arbitraire breedte getekend. Dat is nooit voldoende om ingewikkelde kruispunten met verkeersscheidingen e.d. volledig conform de werkelijkheid op de grond te laten zien.
Dus voor echt hoge zoomlevels heb je echt wel area’s nodig voor een mooi kaartbeeld.
Kars,
De oude niet meer verkrijgbare topos kenden toch ook witte vlakken ? Die bevatten bouwgrond, farmland. Maar ze waren er wel en nu worden die blanke gaten veelal opgevuld met een licht tint groen / geel.
Kars,
Dan moet je kiezen wat je wilt, de aangehaalde of eerder genoemd topo’s werden ook steeds aangepast. Op 10.000 staat alles, de basis kaart, Op 25.000 staat veel met kleuren een wandelkaart, op 50.000 staat veel geminimaliseerd, fiets en wandelkaart, 100.000 is een goede fietskaart of autokaart en 200.000 is een autokaart die niet slechts geminimaliseerd is maar ook sterk verarmd maar wel met kruispunten en verkeerspleinen.
Dus de basis kaart in OSM laat alles zien op alle zoom niveau’s, nee toch, ook daar maakt de renderer een keuze.
Als iedereen de weg en berm breedten mee neemt bij een survey, kan de renderer, die gegevens gebruiken om het kaart beeld te bouwen.
De wegbreedte en bermbreedte kunnen wel veel verschillen, waardoor je voor elke paar meter weg een nieuwe way nodig hebt. Ook kunnen de overgangen in breedtes recht, schuin of gebogen worden uitgevoerd, waardoor het juist renderen van deze breedtes onmogelijk wordt.
Daarnaast heeft het idee ‘We mappen alle area’s om de wegen, waardoor we impliciet de wegen mappen.’ een groot nadeel. Het wordt namelijk niet duidelijk gemaakt dat het bij dit gat om een weg gaat. In principe is een gebied dat niet tot een area behoort, een nog niet gemapt gebied. Doordat wegen altijd als ways zijn gemapt, is hiervoor in eerste instantie niet gedacht aan het mappen van wegen als een area.
Vooral op een hoog detailniveau is dit erg nuttig. Een voorbeeld is hier, waar een gebruiker de Ada van Hollandstraat op een zeer hoog detailniveau heeft ingetekend. Helaas zijn er standaardtags als highway=pedestrian voor de stoep gebruikt en is de weg geen area. Dit is geeft een mooi kaartbeeld, maar het zorgt ervoor dat bijvoorbeeld het pad naar de Raamstraat niet meer verbonden is met de Ada van Hollandstraat.