Het valt me op dat we in Nederland nogal losjes omgaan met het taggen van residential area’s middels landuse=residential.
Volgens mij zijn er een paar OSM-conventies waar we ons niet aan houden. Of dat erg is of niet hangt misschien af van waar we /ik ons op de schaal van het autistisch spectrum bevinden.
Een paar basisprincipes uit OSM die, imho, ook voor het mappen van residential zouden moeten gelden:
we laten verschillende landuses netjes op (alle) nodes aanluiten, de verbinden lijnen tussen de nodes liggen dan automatisch op elkaar.
we laten geen gaps tussen verschillende landuses
we staan geen overlap toe van verschillende landuses; bijvoorbeeld een park in een residential area dienen we met een multi-polygoonrelatie te fixen
het gebruik van layer=-1 voor l.u.=res. om eiland-elementen als parken te laten ‘zweven’ boven de l.u.=res. (voor de renderer?) is niet correct; de landuse, tenzij er sprake is van ondergronds wonen, bevindt zich immers op normaal niveau (=0)
Ik realiseer me terdege dat het maken en vooral onderhouden van formeel juiste multipolygoonrelaties een hell of a job is en voor enthousiaste beginners vaak te veel gevraagd
Ook lijkt het dat de Mapnik-renderer nogal vergevingsgezind is als het om het weergeven van eiland-polygonen volledig ingebed in grotere polygonen gaat en de ‘eilandjes’ netjes weergeeft.
Kortom: moeten we/ik überhaupt moeite doen dit te repareren en te blijven controleren of andere mappers weer eens een grasveld of parkeerplaats getekend hebben zonder de multipolygoon aan te passen?
Ongeacht waar op de schaal van het autisme-spectrum ik me bevind: ik heb er weinig zin in om voor Don Quichote te spelen en al helemaal niet om het werk van anderen in deze te corrigeren en hun ‘streng’ toe te spreken
Maar als we het hier als community over eens kunnen worden over wat mag en moet dan kunnen we deze consensus gebruiken, te pas en te onpas.
Jullie meningen graag en wellicht kunnen we daarna de wiki aanpassen (het is me niet gelukt om hier in de diverse wiki’s iets eenduidig over te vinden tot nu toe)
Wat mij betreft houden we de losse aanpak zoals nu veelal gebruikelijk. In de stad Groningen zijn de verschillende wijken/buurten afzonderlijk omgeven door landuse=residential met naam van wijk/buurt. Die naamgrens is strikt genomen ook onjuist, aangezien de gemeente een iets andere officiële indeling kent in wijken, buurten en subbuurten, die dan soms weer afwijken van het CBS, en die vaak ook weer afwijkt van wat voor bewoners gemeengoed is (de gemeente heeft bv. wel een bestemmingsplan Beijum, maar kent geen wijk Beijum, enkel de buurten Beijum-West en Beijum-Oost, met diverse subbuurten die niemand kent). Maar dat is een probleem apart.
Voor zover ik heb kunnen zien geeft de losse aanpak residential voor de renderer geen probleem (maar ik ken ze niet alle). Daarbij heb ik gemerkt dat al dan niet opnemen van layer=-1 geen verschil maakt (behalve dat sommige validators klagen); in de praktijk heb ik deze layer tag daarom niet gebruikt.
Persoonlijk vind ik het gebruik van multipolygonen met outers en inners een wangedrocht om het probleem van ‘eilanden’ te ondervangen. Het heeft ongetwijfeld een historische achtergrond, maar je zou e.e.a. ook kunnen opvangen met bv. een tag ‘render=0’ (default), ‘render=1’ (komt bovenop render=0) etc. De tag ‘render’ heeft dan enkel betekenis voor de renderer, en geen fysieke betekenis zoals ‘layer’.
Ik pleit tegen een strikte benadering. Er zijn genoeg andere nieuwe zaken vast te leggen, dan wel oudere te corrigeren (zie de validators).
ik dacht net dat je landuses wel aan elkaar liet aansluiten, maar nooit ging verbinden met wegen. JOSM geeft daar trouwens ook een warning voor. Of begrijp ik je verkeerd ?
Je begrijpt me verkeerd, wellicht omdat ik me verkeerd uitdrukte…
Ik bedoel dat we landuse op de nodes laten aansluiten, de verbindende lijnen (‘ways’) sluiten dan natuurlijk automatisch aan.
Ik heb de tekst aan de hand van je opmerking verduidelijkt. Dank.
Van het aansluiten van landuse area op highways (de andere ‘ways’) ben ik ook niet zo’n voorstander - het bemoeilijkt het editen in hoge mate, maar aan de andere kant dient landuse wel zo ‘nauw’ aan de highway getekend te zijn dat ook bij hoge zoomwaarden geen lege ruimtes ontstaan.
Ik ben zeker geen landuse specialist, maar ik sluit me zeker aan bij de meeste van je punten.
Enkel bij de overlap stel ik me vragen. Wat met landuse=residential and landuse=construction? Die kunnen toch beiden gelden voor 1 gebied. En zo zijn er nog misschien nog wel te vinden.
Ik weet niet zeker hoe ze in de andere landen met die overlap vs. multipoligoon omgaan. Ik dacht dat ze in Duitsland nogal negatief stonden tov van de multipoligoon relaties voor landuse. 't kan zijn dat ik die discussie niet volledig juist heb begrepen.
layer-tag wordt momenteel genegeerd door de standard rendering. Dat heeft math1985 hier al eens uitgelegd dacht ik.
Bovendien gaat de standard rendering steeds het kleinste vlak bovenaan tekenen bij een overlap, of je nu layer gebruikt of niet.
Als je heel strikt omgaat met multi-polygonen, zou je - naar mijn idee - ook alle gebouwen als inner moeten opnemen bij een multi-polygoon landuse=residential.
Lijkt me absoluut niet wenselijk. Het is al lastig genoeg zo en de landuse=residential ligt nu al vaak in de weg, loopt over gebouwen, etc.
Buildings zijn toch geen landuse-elementen dus geen multipolygoon nodig hebbend? Ik dacht dat die discussie al heel lang geleden gevoerd was en beklonken?
Behalve als een building een binnenplaats heeft, dan moeten we het gebouw zelf als multipolygoon-relatie beschouwen met een outer (het gebouw) en een inner element (de binnenplaats)
De reden voor de huidige situatie is dat, voor zover ik weet, de meeste landuse=residential-vlakken nog hun oorsprong hebben in de AND-import die in 2007 heeft plaatsgevonden. Het omvatte toen hele steden en dorpen. De Mapnik-rendering rendert bijna altijd landuse=residential onder andere vormen van landuse, dus wat rendering betreft hoeven er niet per se eilanden geknipt te worden. Ik denk dat dat ook heel erg veel werk zal zijn. Zie bijv. dit vlak dat grofweg de stad Utrecht ten oosten van de A2 omvat: https://www.openstreetmap.org/way/6337072.
Bij landuse=residential (of industrial) wordt het mappen lastiger met multi-polygonen.
Je werkt met een vrij groot gebied bij een stad.
En als er dan een park is waar een meertje tussen de bomen op een grasveld ligt heb je al geneste multi-polygonen.
De kans op fouten bij het aanpassen wordt dan steeds groter.
Misschien zie ik het ook te moelijk omdat vanuit de AND import de landuse=residential eigenlijk een combinatie van landuse=residential en boundary=administrative zou moeten zijn? Waarbij je dan binnen een stad/dorp de landuse=residential kunt splitsen bij wegen.
In dit draadje dat momenteel loopt op de tagging mailing list, lijken de meesten voorstander te zijn voor kleine gebieden voor landuse. Zodat je ook geen multipolygonen nodig hebt.
De default (openstreetmap-carto) renderer rendert op volgorde van grootte: kleine landuse vlakken worden boven grote landuse vlakken getekend. Gaten knippen is qua rendering dus inderdaad niet nodig.
Betekent dat grosso modo dat we een groot aantal van de multipolygonen feitelijk voor de kat zijn … moeizaam intekenen?
Of taggen we (niet) voor de renderer? ;-0
Blijft overigens de vraag hoe om te gaan met de buitenranden van residential, die worden ook vaak slordig over ander landuse (forest, grass, farmland e.d.) getrokken…
Ik denk dat het antwoord zowel “ja” als “nee” is. Ofwel, de huidige situatie is historisch gegroeid. Multipolygonen hebben zeker een waarde, bijv. als je alleen landuse wilt tonen, zonder bijv. water. Als je het meertje niet d.m.v. een multipolygon eruit knipt, zie je niet dat daar iets anders is. Aan de ene kant wil je wel dat de situatie verbetert, maar aan de andere kant zijn er genoeg andere zaken die belangrijker zijn.
Misschien een MapRoulette challenge o.i.d. van maken?
Martin, ik heb me daar ook schuldig aan gemaakt. In het kader van een HOT meeting, wilde groepen huizen zonder de gebouwen markeren en voorzien van landuse=residential en ja naar inzicht van de ene naar de andere hoek, zo nauw mogelijk maar op 't oog. Dus niet gebaseerd op iets, maar voldoende voor de helpers om een plaats oid te vinden.
In de Wiki kom ik deze uit langst vervlogen tijden tegen, "There is no consensus about this. If you look in the mailing list archives, you can find multiple heated discussions which way is best. The only conclusion that can be drawn from them, is that you should do what you think is best, uit 2008. Dus weet jij nu hoe het moet, persoonlijk zou ik hier de bebouwde kom aanhouden, maar die is slechts op enkele punten buiten zichtbaar en heeft meer met snelheden dan bebouwing te maken
Offtopic:
De zoekfunctie op het forum is niet erg goed (en dan ben ik nog positief…).
Ik wist dat ik eerder over dit onderwerp een vraag had gesteld en zocht dus naar “Residential” in de onderwerpregel (en op het NL forum). Maar dan wordt dat topic niet gevonden.
Ik moest dus al mijn posts doorbladeren…
Ooit schreef AnkEric over een goede methode om met Google op het forum te zoeken, maar dat verhaal kan ik nu dus ook niet meer vinden…
Ver in mijn geheugen sluimerde ook nog wat en inderdaad: ook tot de ervaring gekomen dat de zoekfunctie niet goed werkt…
Er lijkt me in ieder geval voorlopig nog geen consensus.
De veel toegepaste praktijk dat we in de residential area gelegen ‘eilanden’ als daar zijn grasvelden, bomenpartijen, voetbalvelden, parkeerplaatsen niet als een multipolygoon intekenen daar kan ik wel mee level, al is het alleen maar dat dit voor beginnen mappers veel gemakkelijker is, zonder dat zij aan M.P. dienen te werken (wat sowieso volgens mij alleen met JOSM gemakkelijk gaat).
De praktijk (?) dat de standaard renderer (Mapnik) kleinere eilandjes volledig omgeven door een andere landuse als bovenliggend presenteert wist ik niet, maar maakt dit natuurlijk veel gemakkelijker.
Ik weet ook niet of het moet / nut heeft om de landuse=residential met een layer=-1 uit te rusten, want ik begrijp uit een van de antwoorden hierboven dat dat toch niet goed rendert (man_made=bridge; layer=1 voor een brug outline laat de onderliggende weg ook zien…)
Blijft natuurlijk de vraag waarom we een eilandje in een vijver wel met een M.P. dienen te maken?
En hoe we de buitenbegrenzing van een landuse-residential dienen te laten aansluiten aan het omliggende land - hier zie ik ook vaar slordig getrokken lijnen die geen aansluiting hebben met de nodes van het omliggende land.
Het voorstel dat ik ergens gelezen heb om individuele woonblokken, tussen de straten in elk voor zich als residential te mappen, met de outline grenzend aan de straatkant lijkt me volstrekt overbodig. Precieze ligging van de straat vaak onbekend en onrustig kaartbeeld bij inzoomen en heel veel werk. Ik laat de lijnelementen van highways door/over de residential area lopen.
Martin,
Blijft natuurlijk de vraag waarom we een eilandje in een vijver wel met een M.P. dienen te maken?
Om de simpele reden dat het anders niet “rendert” op de mapnik of afgeleide kaarten.
Je kunt ze wel tekenen, maar op de kaart komen ze echt niet tevoorschijn.
Water bovenop landuse grass is geen probleem voor rendering. Soms ontkom je er niet aan om dat te doen, omdat ik als de dood ben dat rivieren komen droog te liggen. In de Biesbosch heb ik het nieuwe water over de oude landuse heen getekend. Het “nieuw” uitgegraven water staat overal in verbinding met de rivier. Dat zijn allemaal multies van de 3dshapes. Zodra je daar aan gaat rommelen is het eind zoek.
Dus ik houd het voorlopig maar kiss. (keep-it-simple-and-stupid) Op de kaart ziet het er gewoon goed uit. http://www.openstreetmap.org/#map=16/51.7878/4.8636
