Grass / forest / 3Dshapes wel of niet verbinden aan wegen

tekstlijn · 2010-11-26T15:06:38.000Z

Het valt mij op dat enkele OSM’ers area’s met gras en bos verbinden aan wegen. Mijn voorkeur heeft dat niet omdat het dan lastiger is om onderhoud te doen (lees: die wegen te selecteren). Prima dus zoals 3Dshapes worden ingevoerd, omdat de 3Dshapes geen verbinding maken met de naastliggende wegen.

Wat doen we in Nederland: wel of niet gras/bos verbinden met de wegen?

Johan

Ldp · 2010-11-26T16:50:03.000Z

Ik doe het niet, en zie het ook liever niet.

Niet alleen omdat het editen inderdaad een stuk lastiger is (niet mijn hoofdargument), maar dat we wegen mappen als lineaire dingen. Dus als een vector met breedte 0, om een weg met een wel degelijke breedte aan te duiden. Vlakken daarentegen mappen we op hun exacte afmetingen. Een grasveld komt bv niet tot het midden van de weg, maar tot aan de kant. Alleen al daarom zou er een kleine ruimte moeten zitten tussen een vlak en een weg. Zolang het niet om een weg gaat die we als area mappen, zoals een voetgangersgebied, natuurlijk.

Er zijn enkele mappers onder ons, waaronder een enkele GIS’er, die zeggen dat uiteindelijk alles op alles moet aansluiten, en dat er dan dus geen gaten mogen zitten tussen objecten. Dat werkt echter alleen maar als we wegen ook mappen met hun echte oppervlakte, dus als gebied ipv lijn.

Ik zie het nut ook niet in combinatie met 3dShapes. In 3dShapes zijn uitsparingen voorzien voor de wegen. Een weg zou dus netjes door het midden van die uitsparing moeten lopen. Iemand die een weg verbindt met het 3dShapes-vlak is in mijn ogen niet bezig met het mappen van de werkelijkheid.

De argumenten pro en contra zijn er genoeg geweest, over de laatste jaren, en een echte consensus zal er voorlopig ook wel niet komen.

datalogg · 2010-11-28T22:31:18.000Z

Mijn mening is heel anders. Ik werk de laatste tijd veel in stedelijke gebieden met multipolygons, en “hergebruik” dan straten om area’s zoals parken en pleinen te maken. De aardigste voorbeelden van het resultaat van deze methode zijn de TU Delft (http://tile.openstreetmap.nl/?zoom=17&lat=52.00214&lon=4.3712&layers=B000000FFFF ) en Leiden Stevenshof-West ( http://tile.openstreetmap.nl/?zoom=17&lat=52.15025&lon=4.44744&layers=B000000FFFF ). Laastst had ik een discussie met een andere mapper over de voor- en nadelen van deze werkwijze, en heb ik de argumenten voor deze manier van werken op een rij gezet:

Grenzen tussen verschillende landuse-area’s worden in de echte wereld vrijwel altijd gevormd door straten of andere “lineaire” features (waterwegen etc) die wij in OSM abstraheren tot een lijn. In principe vind ik die abstractie niet correct (daarover zometeen meer), maar als je toch daarin meegaat, lijkt het mij volkomen legaal om te zeggen dat wanneer een weg bijvoorbeeld de grens vormt tussen een park en een residential area, dat je dan die weg hergebruikt om de landuse=park en de area=residential mee te maken (dus opneemt in een multipolygon). Het komt niet helemaal overeen met de werkelijkheid, maar als je wegen abstraheert tot lijn, en dan het symbolische gegeven toevoegt dat de weg de grens vormt tussen park en residential, dan mag je van mij die weg hergebruiken als grens. Op het abstractieniveau van OSM klopt dat perfect.

(Terzijde: eigenlijk ben ik het met de GIS’ers eens dat alles op elkaar moet aansluiten en dat alles als vlak gemapt zou moeten worden (met eventueel een soort “center-spline” voor routeringsdoeleinden etc.) De reden is eenvoudig: alle punten op de aardbol hebben een 1:1 relatie met een punt op de kaart/database. Abstracties zoals “een driebaansweg is een lijn” kloppen in dat model niet, want alles is eigenlijk een geprojecteerd vlak. In de toekomst gaan OSM of afgeleiden zeker richting GIS, en dat is prima, want van de GIS-data kan je de simpele kaartdata destilleren. Uiteindelijk is een waarheidsgetrouw model het echte resultaat dat we willen.)

Het hergebruiken van lineaire features als area-grens houdt het beeld in de editor schoner. In plaats van allemaal vrij willekeurige poly’s die losjes tegen elkaar aanschurken heb je één echte lijn die je hergebruikt. Dat schept duidelijkheid.
Het hergebruiken van lineaire elementen houdt de poly-count van de kaart/database laag. Minder poly’s per oppervlakte, dus minder te downloaden om de kaart te kunnen renderen (al moet je wel de multipoly-definities etc downloaden, dus veel zal het niet schelen).
Geen restvormen en lappendekens op de renders betekent een mooier kaartbeeld. Gebieden gemaakt met multipolygons zien er strak uit; zeker niet onbelangrijk.
Dan een tegenwerping van een tegenargument, in plaats van een argument vóór: het editen van multipoly’s in JOSM is iets moeilijker dan normale poly’s, maar dat moet geen reden zijn om ze te mijden. (0Sowieso vind ik het argument dat multipoly’s “te moeilijk” zijn voor casual editors zwak, want we hoeven ons niet te richten naar de grootste gemene deler.) Ter voorbeeld. Tags van een multipoly editen: dubbelklik in het Relations-venster op de naam van de multipoly; de multipoly wordt in magenta geselecteerd; de tags kun je nu editen in het properties-venster. Multipoly maken: klik in het Relations-venster op “Create a new relation”. Geef in: type=multipolygon plus eventuele andere tags. Selecteer ways in het edit-gedeelte. Haal ze in de relations editor van de rechter- naar de linkerkant. Als je een gesloten lus hebt geselecteerd, zie je een soort slang die zichzelf in de staart bijt; als de lus open is, zie je twee open endpoints; uit de context zal duidelijk zijn welk wegstuk er nog ontbreekt. Selecteer dat stuk, haal het in de relations editor van het rechter- naar het linkerveld, en klik OK om de multipoly te maken. Een multipoly uitbreiden of inkrimpen gaat op dezelfde manier: straten selecteren en toevoegen aan de “lus”. Extra lussen, en uithollingen maken kan ook maar dat gaat nu even te ver. Mijn punt is dat het werken met multipoly’s weliswaar advanced is, maar helemaal niet zo lastig, en met een beetje oefenen zelfs heel eenvoudig.

Voor het mappen met alleen poly’s is natuurlijk ook wat te zeggen, maar dit zijn de argumenten die ik kan aandragen voor mijn eigen, wellicht impopulaire, manier van werken.

EDIT: Hm, na herlezing is mijn post niet helemaal ontopic, omdat we het niet hebben over het mappen met multipoly’s maar over het verbinden van wegen met vlakken. Laat in dat geval de multipoly’s nu even buiten beschouwing en focus op mijn argument over het abstractieniveau van OSM, want dat is het eigenlijke punt dat ik wilde maken. Verder is het editen van overlappende wegen niet zo heel lastig, dus mijn argument over de moeilijkheid van het editen kan, mutatis mutandis, ook blijven staan.

cartinus · 2010-11-29T01:16:37.000Z

datalogg:

EDIT: Hm, na herlezing is mijn post niet helemaal ontopic, omdat we het niet hebben over het mappen met multipoly’s maar over het verbinden van wegen met vlakken.

Sterker nog het topic is niet het verbinden van wegen met vlakken, maar het verbinden van wegen met een bepaald soort vlakken.

De berm loopt niet door tot het midden van de A2. De berm is gras, de A2 zelf is asfaltbeton.

De Dam in Amsterdam daarentegen is wel verbonden met de wegen die de begrenzing vormen.

landuse=residential is een fuzzy concept met arbitraire grenzen.

Dat zijn dus drie verschillende zaken die je elk op hun eigen manier moet modelleren.

Het eerste gaat om het fysieke oppervlak, het tweede om de topologie en het derde om een abstracte indeling. Helaas zijn in OSM twee van de drie in landuse terecht gekomen.

theun · 2010-11-29T06:46:56.000Z

Om op tekstlijn zijn oorspronkelijke bericht terug te komen. Omdat het in de editor lastig is om het onderscheid te maken moet je denk ik je data niet aanpassen. Ik neem aan dat het over potlatch gaat want met JOSM is het met de filtermogelijkheden eigenlijk makkelijker om landuse/ways te scheiden.

En uit datalogg zijn verhaal distilleer ik denk ik ook van niet doen. Want een weg is een lineaire weergave van een vlak. Mocht de weg ook als area zijn gemapt dan kun je het natuurlijk wal op de naastliggende landuse laten aansluiten.

Wat betreft de multipolygons. Denk dat dit de beste manier is om alles in detail te mappen (ik vindt het Lexmond van Cartinus een mooi voorbeeld), maar dat is best wel lastig voor de niet multipoly-professional. Dat datalogg dat een zwak argument is vind ik onzin. OSM editors zijn voor de meeste mensen te ingewikkeld, en hierdoor schrijf je een heel groot deel van potentiële kaartverbeteraars bij voorbaat af. Daar moet toch iets voor te vinden zijn dat je op verschillende niveau’s kan editen en dat dat via een of andere conversie in de database terechtkomt. Niet dat ik zelf op dit gebied brilliante ideeën heb, maar denk toch dat een uitgangspunt moet zijn dat de kaart door iedereen is te verbeteren. Maar dit wordt wel heel erg off topic.