Landuse - overlapping - relation - layering - ordening?

Een onderwerp dat ik al eens eerder aangesneden heb, maar volgens mij niet afgesloten.

Wat mij opvalt is dat velen, zo niet bijna allen, landuse=residential ‘plomp’ mappen en overlap met allerlei andere soorten landuse toestaan, zowel aan de buitenranden (bos, landbouw, gras, …) als ook binnen in (gras, park, parkeerplaats, …)

Formeel zou dit volgens mij niet mogen(?), voor zover er formeel iets wel of niet mag in OSM: aan de buitenranden zou l.u=r netjes moeten aansluiten aan bos, landbouw etc. en de andere landuse oppervlakken geheel binnen de l.u=res. zouden als inner delen van de multipolygonrelatie ‘residential’ ingetekend moeten worden.

De genen die dat niet doen, onder wie gerenommeerde mappers, lossen dit soms op door layer=-1 aan de l.u=res. te geven, maar ook als dat niet gebeurt worden landusedelen binnen de residential outline keurig gerenderd in de standaard OSM-opmaak (“Don’t mention rendering…!”)

Stel dat dit formeel allemaal gerepareerd zou moeten worden door multipol. relaties, dan lijkt mij de kans uiterst groot dat een andere mapper, die een parkeerplaats, grasveld e.d. binnen de residential outline tekent, vergeet om deze als inner landuse in de m.p. relatie op te nemen, en zo blijven we bezig…

Bestaat er soms een ordening in landuse-elementen die voor veel van dergelijk elementen-combinaties het maken van een multipolygon niet noodzaakt?

Zoals we een building, dat een surface-element is, niet als inner surface in een m.p.relatie opnemen (om van lijnvormige en puntvormige element natuurlijk maar te zwijgen)

Denk bijvoorbeeld ook aan een meertje in een bos, op de heide of in de wei, een parkeerplaats in het bos…

Groetend en benieuwd naar jullie mening.

Martin

Martin,

Dit zijn allemaal heel goede en terechte vragen! Vragen die ik mijzelf ook heb moeten stellen naar aanleiding van het werk aan mijn OSM Renderer for ArcGIS.

Ik zal dus vanuit die laatste optiek proberen een antwoord te geven op je vragen, vooral ingaand op de vlakkenproblematiek. Bij lijnen en punten speelt dit natuurlijk nagenoeg niet:

Je hebt helemaal gelijk dat in een ideale situatie, veel van de overlappende delen als multipolygonen zouden moeten worden opgelost. Er is echter GEEN harde regel hiervoor te geven, immers, moet je een gebouw nu “uitsnijden” uit een grondperceel, of er “op plakken”. Voor beide methodes valt soms wat te zeggen. Snij je het gebouw uit, dan representeert de resterende perceel netjes het onbebouwde oppervlak, snij je het niet uit, dan is het perceel weer mooi representatief voor het totale kadastrale eigendom.

Nu is het meestal wel zo, dat mensen “intuïtief” een duidelijke voorkeur hebben. In het geval van de building=x uit het bovenstaande voorbeeld, is het wel zo, dat bijna niemand hiervoor multipolygonen creëert (en met die keuze voor een feature die meestal “op/boven” het landoppervlak staat, ben ik het persoonlijk wel eens, nog los van al het werk en de onderhoudbaarheid).

Deze “intuïtieve” keuze heeft in ieder geval in hoge mate de ontwikkeling van mijn eigen ArcGIS renderer bepaalt, en ik vermoed ook die van de osm2pgsql / Mapnik / openstreetmap-carto rendering pipeline. Alle “features” of tags, worden bij mij, in een door mij gekozen volgorde, gestapeld, in de vorm van thematische ArcGIS layers (*.lyr files, niet te verwarren met de layer=x tag!) die soms meerdere vergelijkbare tags groeperen / representeren. In mijn geval, gaat het inmiddels om >200(!) “lagen”. Je moet je wel realiseren dat deze "stapel"keuze eigenlijk arbitrair / subjectief is, ik heb alleen naar render-resultaten gekeken (die natuurlijk weer een afspiegeling zijn van de tagging / editing praktijk). Ik heb dan ook niet de ijdele hoop hiermee alle potentiële problemen voor te zijn, iemand anders kan wel eens aan een andere volgorde de voorkeur geven.

Ik weet dat bij de Mapnik rendering, er ook nog gestapeld wordt op basis van de grootte van de objecten. Kleine objecten belanden zo dus automatisch “boven op” de andere, ook als er niet uitgesneden wordt. Dit vindt plaats door een database sortering op basis van oppervlak. Volgens mij is de grootte van de objecten zelfs leidend als het gaat om de vlakken bij de standaard openstreetmap-carto rendering, maar ik ben niet precies hierin thuis, want ik heb zelf nog nooit met die render pipeline gewerkt.

Het zou natuurlijk het mooist zijn, als er wel vaste afspraken waren over wanneer iets moet worden uitgesneden of niet, maar in de praktijk blijft dit wat beperkt, hoewel de Wiki soms nog leiding geeft.

Ik zelf doe op dit moment helemaal niets met het layer attribuut voor vlakken. Alleen bij highways en railways maak ik daar gebruik van om de verschillende wegen en spoorbanen op de juiste manier te stapelen.

Hoe de default Mapnik render pipeline hiermee precies omgaat, weet ik ook niet precies, dit is 1 van de zaken waar ik nog wel meer over zou willen weten… volgens mij maakt de default rendering, wel ook gebruik van layer=x voor vlakken, maar hoe dat dan weer samenhangt met de rendering op basis van oppervlak… wellicht eerst sortering op basis van layer, en dan op basis van grootte, dus een sortering op twee keys.

Ik was net met landuse bezig:

Om het probleem bij Dwarsgracht eens te verhelpen
http://www.openstreetmap.org/#map=17/52.72542/6.03613

Op zoek naar de bebouwde kommen.

Met een paar steekwoorden een oud topic opgezocht
http://forum.openstreetmap.org/viewtopic.php?id=24640, met methode van omzetten via QGIS naar shape in de juiste referentie wat JOSM snapt.
bodemgebruik 2008 - bebouwd woongebied
een tip van ligfietser

maar dan van tot …

en dan kwam ik jouw probleem tegen
speelplaats is dat residential, de wegen bebouwde is dat residential.
Er ging bij mij door het hoofd van is dat residential wel landuse of is het eigenlijk meer een grens van een gebied, een boundery bewoond.
Weer maar eens stukken gelezen over bebouwde kommen en de verschillende soorten.

Dwarsgracht rechts van het water bebouwd woongebied, nat natuurlijk terrein aan de linker kant van het water, er staan daar nogal wat huizen links, waarbij ik dacht die behoren bij bebouwde kom dwarsgracht en zijn een woongebied.

Dus nog niet opgelost.

Want kan een woning in een nat natuurlijk terrein staan, nee.

Ik weet dat jullie in Nederland nogal snel naar multipolygonen grijpen om landuses uit te snijden. In België en ik dacht ook in Duitsland geven we de voorkeur aan kleinere landuses.

Verder gaan landuses echt over het gebruik, dus huis + tuin in natuurgebied moet residential worden.

Hm, het is hier idd een zootje. AND en 2shapes import duidelijk niet goed gegaan. Ben voorzichtig wat aan het opschonen. Lokale mappers daar?

Kom daar wel eens.

Eigenlijk is alles daar wel wetland, natte natuur en rietbouw. landuse=grass is het niet

Ik was eerst op zoek gegaan naar betrouwbare vervangende, te gebruiken informative, zoals bewoond, wetlands

data 2005
http://geodata.nationaalgeoregister.nl/wetlands/wms?
er is alleen meer bijgekomen vergrote gebieden, stoppen veehouderij
maar dit klopt niet want op vele plaatsen is het gewoon nog veehouderij.

Martin, t ziet er weer netjes uit. Loopt daar allemaal door elkaar, ziet eruit als een leuke uitdaging.

De vraag is: beetje bij beetje herstellen of van scratch beginnen…

of wachten tot of na 2016
dan zal er toch een behoorlijke opschoning zijn. Aansluitende lijnen.

Allroads, lost die opschoning dan ook alle overlappingen op die nu al aanwezig zijn en er nu ook nog al of niet haastig en veelvuldig in gemaakt worden ? Anders zou ik zeggen langzaam aanpakken en polder voor polder of deel voor deel splitsen en oplossen. Tijdrovend ja, om alles juist te benoemen en er generaliserend geen grauwsluier overheen leggen, dus varend het gebied in.