Centrum Den Haag staat blank...

Beste mappers,

Zoals sommige van jullie denk ik wel weten, ben ik bezig met een eigen op ArcGIS gebaseerde renderer. Nu viel mij bij een recente her-rendering van heel Nederland op, dat het stadshart van Den Haag ineens blank stond. ;(

Een beetje zoeken leverde de volgende relaties op:

http://www.openstreetmap.org/relation/3328155

Een “man_made=bridge” die complete waterlopen beslaat en ook nog onder het regeringscentrum doorloopt…? Ik volg het niet.

Het blank staan werd veroorzaakt door nog een andere relatie:

http://www.openstreetmap.org/way/293473286

met de tag “natural=water”. Ook deze mist duidelijk een “inner” om het stadshart droog te houden.

Er liggen hier echter nog veel meer van dit soort relaties op elkaar. Deze zijn van het type “type=bridge”. Een van de basisproblemen hier, lijkt de opname in al die “brug” relaties van een closed way te zijn (http://www.openstreetmap.org/way/144190520#map=14/52.0764/4.3138).

De bewerkingen lijken terug te voeren op de volgende (proposal) pages van de relatie van “type=bridge/tunnel”:

Relations/Proposed/Bridges and Tunnels
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels

Proposed features/man made=bridge
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge

Tag:man_made=bridge
http://wiki.openstreetmap.org/wiki/Proposed_features/Simplify_man_made%3Dbridge_mapping

Toen ik deze pagina’s zag en las, was mij meteen duidelijk dat de schrijvers daarvan, nog nooit zelf met Mapnik / osm2pgsql een kaart kunnen hebben gerenderd. Deze voorstellen zijn zo complex, en gaan van dusdanige vergaande aannames uit - de lijnen van highways moeten straks alle relevante properties zoals “layer=x” van de type=bridge relatie erven, of de properties via een nog moeilijkere ruimtelijke / spatial operatie in een GIS / render database bepalen - dat ik uit ervaring weet dat dit nagenoeg niet te realiseren is in de huidige op RDBMS technologie gebaseerde render pipeline… Als het al in SQL statements te vatten is, dan is de performance daarvan waarschijnlijk abominabel.

En de schrijvers denken dat het “makkelijker” wordt:

"This will make it easier to keep the data consistent, easier to render man_made=bridge and avoid routing problems. "

Ik denk dat deze voorstellen een onontwarbare kluwen van bridge relaties gaan opleveren… dit is daar een voorbeeld van.

De voorstellen zijn ook met zoveel onduidelijkheden geschreven, dat ik er in ieder geval niet uitkom hoe een “bridge” nu precies getagged zou moeten worden. Ook het openlaten van bepaalde opties en / of niet verplicht stellen van bepaalde zaken, maakt het consistent taggen en een rendering daarvoor ontwikkelen tot bijna een onmogelijkheid. De volgende zin van deze pagina (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels) is illustratief:

“If neither outline nor edge is given, the “across”/“through” ways would be used to derive a nominal outline for rendering purposes for example.”

Dus je mag ook doodleuk “outline” en “edge” weglaten. De renderer (Mapnik / osm2pgsql of enige andere) mag vervolgens op “magische” wijze maar uitzoeken hoe het probleem wordt opgelost… als voorstel door de bestaande highway lines over de brug aan elkaar te knopen als alternatief…

Kent iemand hier gebruiker “frenz” (http://www.openstreetmap.org/user/frenz), de maker van deze relaties? Hij / zij heeft al meer dan 8000 bewerkingen gedaan…

Ik heb met Frenz van het voorjaar gemaild over het taggen van fietspaden. Hij stond open voor kritiek dus stuur 'm een mailtje hierover en nodig hem uit op het forum.

Tsja, sommige mensen lijken niet van het KISS principe te houden.
Nadeel van al dit soort snik/snak is, dat het voor andere mappers onmogelijk wordt om het nog te onderhouden en aan te passen.
Als de maker van dit moois aan zijn stutten trekt, probeer er dan nog maar eens uit te komen.
Dezelfde soort problemen als bij 3D, highway als area en nog zo wat. Prachtig, maar zo ingewikkeld en lastig en arbeidsintensief.

Eerst maar eens proberen OSM op een simpele manier op de dikte te krijgen. Dat kost al moeite en tijd genoeg.

Nu snap ik ook waar op de OpenFietsmap al die in het oog springende labels ‘bridge’ vandaan komen waar de randstadrail in Zoetermeer een water of andere weg kruist… M.i. een ongewenst en lelijk bij-effect van de inspanningen van mapper frenz, maar misschien ontgaan mij de hogere doelen van het in een relatie zetten van bruggen en viaducten…

Dat label bridge zet ik op alle brug areas, omdat er anders plein zou staan ( ik maak nl gebruik van hetzelfde garmin polygoon type). Ik zou er ook brug van kunnen maken, maar daar ben ik te lui voor want dan moet ik dat voor iedere taal apart doen in de style sheet en daar heb ik geen zin in. Helemaal geen label tonen zou beter zijn maar dat is nog lastiger. De plaatselijke mappers zouden dit kunnen oplossen door de naam van de brug in de name tag te vermelden.

En bovendien zijn al zijn edits “no comment”…

@ligfietser, bedankt voor de toelichting. Niet opvatten als kritiek hoor - met je uitleg is het duidelijk en voor mij acceptabel waarom die labels op OFM zichtbaar worden. De tip om de bruggen te taggen met hun naam - voor zover beschikbaar - is een goede, lijkt me. Als er geen gewone naam beschikbaar is, hebben vele bruggen ook vaak een registratienummer van de organisatie die de brug heeft gebouwd (of laten bouwen).

Ik zal proberen user frenz vandaag een berichtje te sturen.

Nu ik nog wat beter gekeken heb, is mij wel duidelijk, dat user frenz consequent en netjes tracht de “bridge” relaties aan te maken. Los van het evt. nut en de relatieve complexiteit van de bridge relation tagging, is dat natuurlijk goed.

Het voornaamste overblijvende probleem, lijkt daarmee het vergeten te zijn van de “inner” polygonen / vlakken op dit natural=water object, dat ik al eerder aangaf:

http://www.openstreetmap.org/way/293473286#map=15/52.0764/4.3036

Als zowel een “inner” polygoon voor het centrum van Den Haag wordt toegevoegd aan dit natural=water watervlak, als meerdere “inner” vlakken voor het Westbroekpark, waar meerdere eilanden in liggen, dan zou de weergave ook in mijn ArcGIS renderer, en andere GIS pakketten als QGIS, goed moeten gaan. Het daarvoor benodigde vlak is voor de binnenstad al aanwezig, dit is namelijk deze polygoon:

http://www.openstreetmap.org/way/144190520#map=14/52.0775/4.3121

Bij het Westbroekpark zouden de eilanden als inners moeten worden toegevoegd.

Dit lijkt mij niet de juiste insteek. Als je hier consequent mee door zou gaan, heb je straks één grote polygoon (natural=water) ter grootte van heel Nederland, met eilandjes voor alles dat geen water is.

Op zich vind ik het een vooruitgang dat de losse vlakjes onder de bruggen weg zijn. Die komen nog uit de 3Dshapes import, maar ben ik in de BGT nog niet tegengekomen.

De gekozen structuur is volgens mij echter onnodig complex. De juiste oplossing zou volgens mij de volgende zijn:

Maak maak voor ieder op-zichzelf-staand stuk water (Houtkeetsingel, Houtzagersingel etc.) een aparte gesloten weg, tag deze met natural=water en zorg er voor dat deze vlakken netjes op elkaar aansluiten. In de meeste gevallen is hier geen relatie voor nodig.

Het klopt dat er dan (in de editor) een lijntje staat tussen verschillende stukken water, dat er in werkelijkheid niet is. Maar het is nu eenmaal ondoenlijk om al het water in één grote relatie te zetten. Bovendien sluit het aan bij wat ik tot nu toe in de BGT heb gezien. En de BGT zal in de nabije toekomst een belangrijke rol gaan spelen als bron voor watervlakken.

Verder staat op http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels nog ter discussie of role=under wel zinnig is. Het water hoeft waarschijnlijk niet in de bridge relatie, wat het geheel er weer een stukje eenvoudiger op maakt.

Je hebt gelijk dat eindeloos doorknopen van waterlopen tot een grote landsdekkende polygoon volstrekt ongewenst is. Er zullen inderdaad ergens artificiële en arbitraire grenzen getrokken moeten worden. Desondanks denk ik dat bij de gegeven multipolygon, het opnemen van een aantal “inner” holes, een redelijke oplossing is. Deze multipolygoon is nog niet extreem groot, en daarmee onbehapbaar.

Redelijk mee eens ja, ik denk dat het schrappen van de role=under voor water, de bridge relaties een stuk behapbaarder maken. Het administratief direct koppelen van de waterloop aan een brug via een relatie, is niet perse nodig. Een simpele ruimtelijke selectie in een GIS kan deze info achterhalen. Voor de rendering is dat verder ook niet zo nodig. Hooguit dat als er meerdere waterlopen boven elkaar kruisen - een grote zeldzaamheid - dat er dan meer waarde aan dergelijke administratieve relaties zit, maar ik kan het op dit moment nog niet zo zien.

Ik heb nu nog even verder gekeken naar de bewuste objecten, en mij gerealiseerd dat het basisprobleem van Den Haag en de watervlakken, toch nog wat anders zat dan ik dacht.

Feitelijk was er al wel een correct natural=water mulitpolygoon aanwezig. Dit is:

http://www.openstreetmap.org/relation/5515953

Probleem was echter dat de outer way van deze multipolygoon, namelijk het object dat ik in mijn eerste post refereerde (http://www.openstreetmap.org/way/293473286), de natural=water tag dupliceerde. Dit is in de moderne benadering van multipolygoonen niet toegestaan, en leidt tot duplicering en opvulling van het inner vlak met “water”, alsgevolg waarvan Den Haag centrum blank stond…

Ook waren de outer en inner ways als objecten met de role “under” aan al die eerder genoemde bridge relaties toegevoegd, terwijl feitelijk niet de outer en inner ways, maar de multipolygoon als “under” zou moeten worden ingesteld.

Wat ik nu heb gedaan ter correctie:

• Verwijdering natural=water tag van de outer
• Verwijdering van alle inners en de ene outer van alle bridge relaties door verwijdering van de role “under” van de inners en outer.

Hiermee zou in ieder geval dit probleem opgelost moeten zijn.

Ik had nog geen reactie van frenz. Misschien dat ik nog een berichtje stuur met deze wijzigingen, maar voorlopig kan het er zo mee door.

Marc, {“Verwijdering van alle inners en de ene outer van alle bridge relaties door verwijdering van de role “under” van de inners en outer.”} Is of staat er in de Wiki een beschrijving van ‘under’ en zo ja waar, ik zag t niet, maar dat kan aan mij liggen, denk ? De tekst van je quote is IMHO vrij summier.