Ik probeer wat te gaan micromappen en heggetjes in kaart te brengen. Volgens de wiki zou je ook een vlak met heggetjes kunnen toewijzen met area=yes & barrier=hedge. Maar helaas… dat werkt blijkbaar toch niet zo? Zie hier:
En de wiki: NL:Tag:barrier=hedge - OpenStreetMap Wiki
Iemand een idee??
Sinds een paar jaar rendert de Carto-laag barrier=hedge met area=yes niet meer als vlak. De reden hiervoor is dat de barrier=* eigenlijk altijd lineair zijn, plus een paar aanvullende vage argumenten van de Carto-maintainers.
Om dat gat op te vullen is natural=shrubbery bedacht. Die is voor struiken, bosjes, en heggen, en wordt altijd ingetekend als vlak:
(Gras en heggen om het parkeerterreintje heen.)
Als je die combineert met shrubbery:density=dense geef je aan dat je te maken hebt met struiken met een hoge dichtheid. Een heg dus.
Helaas wordt deze op de Carto-laag helemaal niet gerendert vanwege weerstand door dezelfde Carto-maintainer die barrier=hedge als vlak gebroken hebben. Maar, natural=shrubbery wordt wel op andere lagen en in apps zoals OsmAnd en OrganicMaps getoond. Trek je daarom niet te veel aan van het ontbreken van rendering in Carto. Dit komt vaker voor. Tag de objecten gewoon met de geschiktste tags.
Grofweg:
barrier=hedgenatural=shrubberyStruikenperken zijn shrubbery, en heggen zijn lange smalle struikenperken, en soms hele dikke struikenperken met een duidelijke barrierfunctie. Maar de barrierfunctie zit niet in natural=shrubbery.
Dus er gaat wel informatie verloren als je een dikke heg als een struikenperk mapt.
Jawel, in shrubbery:density zelfs expliciet. Verder geldt dat of bosjes, struiken, heggen, etc. fysiek voorkomen dat je er doorheen kan gaan natuurlijk subjectief is, maar de tag definieert dat in de dichtheid. Daarnaast is de algemene stelregel dat alle natural=shrubbery als barrières gelden voor normaal gebruik, tenzij er een highway=* doorheen loopt (daarmee geef je aan dat er dus een pad is). Je wil immers niet door de bosjes gestuurd worden als je gewoon een route plant naar het station.
Dit is in tegenstelling tot landuse=grass waar de aanname geldt dat je er waarschijnlijk wel over heen kan zonder highway=*.
Maar let op: dit maakt verder helemaal niet uit, want geen enkele navigatietool doet iets met vrij navigeren over zulke vlakken. Als die er wel komt, dan zal de in eerste instantie vrij navigeren alleen over pedestrian areas en wellicht gras doen.
Absoluut niet. Je voegt enkel informatie toe door de volledige vorm in te tekenen in plaats van een lijn die hem benadert.
Vergelijk het met andere vlakken die als barrière gelden als er geen pad doorheen is getekend. Een building=* is net zo goed een barrière immers. Daar is geen barrier=*-tag voor nodig.
Ik bedoelde het net ietsjes anders.
Er zijn veel OSM objecten waar je niet doorkan, maar die zijn niet speciaal bedoeld als barrier. Hekken, muren en heggen worden speciaal geplaatst als barrière. Struikenperken (shrubbery) zijn meestal niet bedoeld als barrier, maar als opvulling.
Dus ten opzichte van barrier=hedge (ev met area=yes voor de exacte vorm indien van toepassing) is natural=shrubbery een teruggang in informatie. In plaats van een geplaatste barrière die uitgevoerd is als heg, tag je een struikenperk waar je misschien wel of misschien niet doorheen kan.
Als ik een schoolterrein of begraafplaats heb met driekwart stalen hek en eenkwart metersdikke heg eromheen, dan wil ik de hele omtrek als barrière taggen, en niet een deel als barrier en een deel als natural. Dat is totaal anders dan pakweg de groene verkeerseilandjes op een ontsteend verkeersplein.
Jouw schoolterrein heeft ook dikwijls een fietsenhok of aanbouw staan die als barrière voor een deel van het terrein dient. Daar kun je ook niet 100% omheen met een barrier=*. Dat is met natural=shrubbery niet anders.
Zeker als je shrubbery:density=dense toevoegt is er niets aan de tagging waardoor je de indruk zou krijgen dat je er doorheen kan lopen. Net als de building=shed ernaast. Die ga je toch ook niet dubbel een barrier=wall tag geven? Toch is zo’n schuurtje aan de rand van het schoolterrein wel degelijk bedoeld als barrière toen de rest van het terrein ommuurt of omheind werd.
En net als bij een kerkhof met een klassieke Britste lich gate (voorbeeld) kan je dus best een barrière rondom hebben die onderbroken wordt door een object zonder barrier=*. Hier is dat een building=lich_gate met een pad erdoorheen. Net zo kun je een natural=shrubbery hebben met shrubbery:density=dense en een pad erdoor, hoewel ik zelf dan gewoon de opening inteken.
Dichte bosjes en heggen zijn vrijwel altijd aangelegd met de praktische uitwerking dat ze een barrière vormen. Een heg is niet altijd per se bedoeld als barrière, maar is dat wel, en dat telt voor OSM.
In de volksmond wordt dit gewoon een keurig bijgehouden beuken heggetje genoemd.
Ik zal het omzetten naar
natural=shrubbery
shrubbery:density=dense
Alleen het lijkt alsof het toch niet helemaal goed de lading dekt…?
Dat vraag ik me af, ik ken geen enkele router die van de wegen/paden af wijkt tenzij het een soort van rechte lijn mode is die helemaal geen rekening houdt met barrières en gerust door een gebouw, water of een hek gaat.
In OSM is alles een barrière tenzij het een pad/weg is.
Zo’n router zou ook moeten beginnen met een whitelist aan vlakken die beloopbaar zijn. Dat komt in de praktijk neer op highway-vlakken, aangevuld met gras en zand met daarop een penalty (want het is meestal fijner een pad te nemen als je niet te veel omloopt).
Wat mis je nog? Veel meer kun je er niet van maken, behalve dan eventueel height=0.5 toevoegen. Met dat laatste kan een 3D-renderer dan weer uit de voeten.
Voor een router. Voor een mens staat een huis wel in de weg maar je gaat het geen barrière noemen. Ik ga ook geen dikke muren als building taggen, omdat een renderer zegt dat-ie geen dikke muren kan verwerken. Die informatie is: er is een barrier, namelijk een dikke stenen muur, en die zet ik in OSM als outline met barrier=wall + area=yes.
Inhoudelijk prima mapping aanpassen wegens een botte weigering van één renderer, die ook nog eens geen alternatieven accepteert, ik doe het niet meer. We mappen niet voor een renderer of voor een router.
It’s a bug in OSM Carto. To fix it, someone would need to implement something like I described here.
I do not believe that corrupting the data (pretending that a hedge is a shrubbery) is the way forward. While there may be some overlap, in real life most hedges are nothing like shrubberies, and vice versa.
If anyone wants any help standing up a raster or vector tile server that shows area hedges properly in the Netherlands or elsewhere let me know. I don’t believe that it’s worth trying to argue the case with the OSM Carto maintainer.
Entschuldigung, dass ich auf Deutsch schreibe.
Ich stimme @Peter_Elderson zu.
Soweit ich die Diskussion auf github verstanden habe ist es problematisch, wenn der Umring eines Flächenelementes gleichzeitig mit barrier=hedge/wall gemappt wurde. Die ganze Fläche wurde dann als Hecke oder Mauer gerendert. Um dieses fehlerhafte Rendering zu beheben wurde entschieden, hedge und wall immer nur als Linie zu rendern, auch wenn der mapper bewusst ein area=yes gesetzt hat.
In meinen Augen hat man falsch dargestelltes Rendering korrigiert, indem man falsches Mapping (zwei features an einem OSM-Objekt) korrekt darstellt und dafür korrektes Mapping falsch rendert und damit dem Mapper auch noch einer visuellen Kontrolle beraubt.
Hedges are nothing more than dense shrubs (shrubbery:density=dense) managed, trimmed, planted, and pruned by people, often of a particular height (height=1.2 or height=2) sometimes pruned into a box shape (shrubbery:shape=box). We defined natural=shrubbery to account for all of that. There is no pretending, just documenting what’s there.
Fixing things in Carto is currently a waste of time. Any PR, regardless of quality or merit, will just get criticized and rejected, like all the other high profile bugs with valid PRs. Been there, done that, several times. Besides, it was a deliberate choice to break this rendering. Do you feel it likely that the Carto gatekeeper is going to backtrack on that?
Besides, there is this school of though too:
By now, barrier=* being defined as linearly by Carto has had an effect on the tag’s use too. I’m not even sure going back hedges with area=yes is sensible at this point.
It makes more sense than caving in to the cabal of carto.
There is also merit in heaving a barrier (such as a wall) as an area. if it’s a single brick width wall you might want to put as a linear object; however there are plenty examples where walls are several meters thick; wich would merit to map it as an area.
Why the same does not apply for a hedge is a mystery to me.
Tha aside; there is als merit for Shrubbery as maintainted bushes. Wether they function as intended barrier (such as a hedge) or not. Similarly; not all hedges are bariers.
Hedges as barrier and area are similar to me as water as waterway= (line), and natural=water (area).
barrier=hedge adds the most value when it crosses a linear object like highway or waterway.
To me a hedge does not cross a highway. There is typically a gap in the hedge; or there is a gate which I would tag as a fence with a gate in it.
