Nationaal park Veluwezoom

Hallo mappers,

Het viel mij op dat Nationaal Park Veluwezoom niet gerendered wordt op de kaart.

Hij is echter wel aangegeven als national_park.
https://www.openstreetmap.org/way/204253859

Zijn buurman Nationaal Park De Hoge Veluwe wordt wel netjes gerendered (groene rand en de naam in het midden met groene letters). Andere nationale parken (Dwingelderveld bijvoorbeeld) worden ook netjes gerendered. Lijkt dus een probleem met Veluwezoom.

Wellicht dat iemand die hier meer kennis van heeft kan uitvinden wat het probleem is. Zou toch wel netjes zijn als het eerste nationale park van Nederland ook wordt weergegeven op de kaart :).

Groeten,
Mark

Ik denk dat het hiermee heeft te maken:

https://forum.openstreetmap.org/viewtopic.php?id=56641

Edit:
Ben echter niet zeker van mijn zaak, ben er nu naar aan het kijken.

Ik heb zojuist de missende tags toegevoegd. Het zou binnenkort op de kaart te zien moeten zijn. Kan een tijdje duren voordat het op alle zoomniveaus goed werkt.

(Had niets met toponym te maken)

Edit: inmiddels vanaf zoom 13 bij mij zichtbaar.

Hallo Marc,

Ziet er super uit.

Zo te zien misten dus de tags leisure=nature_reserve en type=boundary. Goed om te weten :).

Groeten,
Mark

Ik denk alleen type=boundary, leisure=nature_reserve is overbodig, kijk maar naar https://www.openstreetmap.org/relation/2745855

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dnational_park

Volgens mij was de tagging voor Marcs wijzigingen juist, en was er alleen sprake van een renderingprobleem op OSM Carto.
Marc heeft twee tags toegevoegd:
leisure=nature_reserve
type=boundary
De eerste lijkt inderdaad overbodig, de tweede is alleen bij een relatie nodig, niet bij een weg (polygoon/veelhoek bedoel ik dan, geen weg waar je op kan rjiden).

Ik heb inmiddels enkele tiles opnieuw laten renderen door /dirty achter de URL van de tile te typen, dan ontstaat opeens wel een donkergroene rand rond het gebied. Hoe dat moet staat in de wiki: Slippy Map.

Ook andere Nationale Parken (Lauwersmeer, Biesbosch, Hoge Veluwe, Schiermonnikoog) worden keurig gerenderd zonder deze extra tags, dus toevoegen van deze extra tags schopt alleen de renderaar weer wakker voor dit gebied, maar zijn verder overbodig.

Ik heb even twee testgebieden opgezet en geprobeerd. [edit: inmiddels weer verwijderd]

  1. Deze met leisure=nature_reserve
  2. en deze zonder.

Ik zie de naam wel op de kaart verschijnen (en ook in JOSM zie je dat direct) bij 1, bij 2 zie ik de naam niet.
Mijn conclusie is voorlopig dat de toevoeging van leisure=nature_reserve de doorslag geeft. type=boundary kan inderdaad weer weg.
Opvallend is trouwens dat de rendering in Firefox snel zichtbaar is, maar in chrome duurt dat veel langer!



Lijkt me dus een bug in de renderer. Veluwezoom heeft eerder wel gerenderd toen ik die parken aan OSM toevoegde. De tag leisure=nature_reserve staat daar los van en mag niet de doorslag geven.

Maar dan ook in JOSM, waar de naam ook alleen maar verschijnt als je leisure=* hebt toegevoegd.

Dat noem ik geen bug maar een missing feature :wink:
Bij NP Lauwersmeer verschijnt ook niks.
Of is area=yes dan weer doorslaggevend om het wel te renderen op de osm.org kaart? :confused:

Dat is vreemd, daar zie ik wel degelijk de naam verschijnen, maar hier dan weer niet!

Met deze overpass zie je ze allemaal als ze als way zijn getagd:
http://overpass-turbo.eu/s/uKn

@ligfietser:
Kijk eens op de Sallandse Heuvelrug die jij hebt gemapt een jaar of 5 geleden.
Dat is een relatie en die heeft ook geen naam!
Het wordt steeds raarder!

Edit: bleek een zoomprobleem, naam verschijnt wel vanaf zoom 13. Was dat bij jou bij het Louwersmeer misschien ook het geval?

Niet in Josm, wel op osm.org. Wat ik bedoel is dat in de algemene stylesheet van Josm boundary=national_park niet wordt gerenderd. Dat is een keuze. Bij osm.org is er sprake van willekeur, soms wel soms niet. Dat noem ik een bug.

Een tag area=yes lijkt echt iets uit te maken voor de standaard Carto rendering. AnkEric heeft 6 dagen geleden deze tag verwijderd bij Schiermonnikoog. Ik heb net op zoomlevel 12 een tile dirty verklaard, en prompt verdwijnen de naam en groene rand op deze tile. Bij het Lauwersmeer (waar area=yes nog wel opstaat), lukt het me niet om de naam en rand op deze manier te verwijderen. Tijd om een issue aan te maken bij carto rendering lijkt me. Als we het als feature request brengen, wordt het waarschijnlijker positiever opgevat dan als bug ;).

Hier wordt het reeds aangekaart https://github.com/gravitystorm/openstreetmap-carto/issues/1141
Het schijnt toch met een relatie te maken te hebben, dus door type=boundary toe te voegen en een relatie te maken van die ene way?
Of is dat weer taggen voor de renderer (die dat niet wil oplossen want het staat al drie jaar open). Leisure=nature_reserve tag is in feite ook taggen voor de renderer.

Deze relatie https://www.openstreetmap.org/relation/2745874 heb ik nu aangepast in type=boundary ipv multipolygon omdat dit nu de meer gangbare manier van taggen is. Mogelijk rendert het dan ook beter.

Ik heb het nu zo getagd: https://www.openstreetmap.org/relation/7897828

De way 204253859 als enigste weg als outer in de relatie 7897828. In feite hoef je de weg 204253859 geen tags mee te geven, maar ik doe het toch omdat er mappers zijn die wegen zonder tags willen weggooien. Soms als er een hek om het park staat kan je er een barrier tag op zetten.

Edit:
NP’s Schiermonnikoog, Lauwersmeer en Dwingelderveld ook zo aangepast.

Waarom zet je niet gewoon de tag area=yes op de weg? Volgens het issue bij openstreetmap-carto wat je gevonden hebt, zou dat ook moeten helpen om de weg als polygoon te classificeren. Dan wordt de juiste rendering ook toegepast. Voor de zekerheid kun je er een note bij zetten dat de tag nodig is voor de rendering, om te voorkomen dat iemand 'm weer verwijderd.

Het introduceren van een relatie met maar een member, lijkt me nodeloos ingewikkeld. In beide gevallen is IMHO sprake van taggen voor de renderer, dus daar zie ik ook geen verschil.

Ik kom trouwens bij de al bestaande relaties veel outers met allerlei tags tegen die weg kunnen of op de relatie thuis horen. Ook zie ik tags die niet gedocumenteerd zijn.

Je hebt gelijk dat een relatie met maar één member ingewikkelder is maar ik vind dit consistenter, de meeste boundary relaties worden tegenwoordig zo getagd. Zo kan je een gebiedje binnen die area wat niet binnen het park zou vallen makkelijker als inner toevoegen. Toen ik vijf jaar geleden het in osm zette waren de regels niet zo uitgekristalliseerd. Er zijn toen met de import idd heel wat tags meegenomen die er niet toe doen en eigenlijk opgeschoond mogen worden. Soms zittenn alle tags zowel op de outer als op de relatie. Met de kennis van nu had dat beter gemoeten, zo’n import zou nu niet eens mogen zonder eerst uitgebreid met de community te overleggen en alles in een wiki te documenteren. Zoals bv de BAG import. Ik zou er niet eens aan begonnen zijn als ik het nu zou moeten doen :wink: