proposal natural=shrubbery voor struikgewassen en barrier=hedge

Momenteel ben ik bezig de Oefelter Meent en de Maasheggen te updaten
Wegen en landuse aan te passen en Waterwegen en water toe te voegen, en heggen die nog niet op de kaart staan.
Ik gebruik nu de tags barrier = hedge en area = yes
Is het misschien beter om alvast de tag natural = shrubbery te gebruiken

https://www.openstreetmap.org/#map=15/51.7094/5.9367

als je het voorstel een goed idee vind dan kun je inderdaad al je steun aangeven door de tag te gebruiken. Mocht het voorstel het niet halen dan kunnen we het altijd gemakkelijk omtaggen.

Even ter zijde, is het niet meer natural=wood of landuse=forest? Vanuit deze hoek lijken het voor mij bomen.

https://www.maasheggenunesco.com/nl/

Dat zijn de typische maasheggen
De sruiken die in bloei staan zijn de vuurdoorn en de sleedoorn

Top, dan is het prima. Was niet helemaal goed te zien op de foto hierboven maar duidelijk zo.
De shrubbery hier in combinatie met barrier=hedge op een vlak lijkt mij binnen de definitie van natural=shrubbery te vallen.

Het virtuele stemlokaal is geopend voor natural=shrubbery. Iedereen met een wiki account kan zijn stem nu uitbrengen de komende 2 weken.

Een opmerking, het proposal gaat alleen over de tag natural=shrubbery. Mogelijke combinatie met barrier=hedge zoals eerder hier is besproken is verwijderd en zal (zoals te lezen is in het proposal) later worden uitgewerkt maar dat staat los van het huidige proposal. Het gaat dus alleen om de tag natural=shrubbery zoals sommige van jullie deze al aan het gebruiken zijn.

https://wiki.openstreetmap.org/wiki/Proposed_features/shrubbery

In Hoogkarspel hebben ze al het nodige aan struikgewas! Dan wordt het maar even niet weergegeven op de kaart. Hoe lang duurt zulks nou normaal gesproken voordat het wordt gewijzigd?

Een geaccepteerde tag wil toch niet meteen zeggen dat dat ook gerenderd wordt met een onderscheidend kenmerk?

Hoe loopt dat proces? Moet er ook een apart traject ingezet worden om de tag gerenderd te krijgen?

Uit de OSM wiki begrijp ik dat je een tag ook gewoon in gebruik kunt nemen en bij de betreffende pagina kunt toevoegen. Bij algemene acceptatie bereikt de tag dan geen “approved” status maar “de facto”: https://wiki.openstreetmap.org/wiki/Any_tags_you_like

Ja, zodra een tag is geaccepteerd word hij op carto in ieder geval niet meteen gerenderd. Mateusz zei dat ik pas een render verzoek kan overwegen als de tag tussen de 2000-10000 keer is gebruikt, eerder wordt die bij voorbaat afgewezen. Tot die tijd kun je de tag wel gebruiken maar wordt hij nog niet gerenderd. Over de duur van niet renderen is niets te zeggen. Hangt er vanaf hoe snel mensen het accepteren.

Van de wiki:

Sommige beweringen schijnen geen onderbouwing te vereisen. Ik ga perfect aangelegde en onderhouden ‘barrières’ toch echt niet omkatten naar een natural, vooral omdat alle renderers dit prima weergeven, behalve die van OSM. Dit komt neer op de renderer wijzigen omdat de renderer was gewijzigd.

Het feit dan Carto barrier=hedge + area=yes niet als vlak renderd was vooral een startpunt voor dit idee maar zeker niet de enige reden, vooral een bijkomstig voordeel als je het mij vraagt. Bij dergelijke vlakken die nu met natural=shrubbery, barrier=hedge of natural=scrub getagt worden is vaak de vraag, in hoeverre heeft dit vlak een barrier functie. Vandaar dat we met het idee van density kwamen. Het is namelijk mogelijk om veel objectiever te bepalen wat de dichtheid van de begroeiing is dan of een vlak een barriere functie heeft. Het is vervolgens aan de data gebruiker om te bepalen wanneer iets een barrier functie heeft afhankelijke van eigen eisen. Carto kan dan bijvoorbeeld besluiten on shrubbery:density=dense als barriere functie te zien en ook zo te renderen.

Het maakt in algemene zin dus de data ook objectiever

Dat heb ik geschreven. Van welke bewering mis je de onderbouwing? Dan kan ik dat toelichten.

Nee jij niet, maar houdt jij bij of alle tienduizend met area=yes gemapte heggen in Nederland niet stap voor stap vervangen worden door natural=scrub nu omdat beginnende en pragmatische mappers nu gewoon een defecte rendering zien? Een defecte, dus niet een ontbrekende, maar gewoon een gebroken rendering.

Als de standaardrenderer zo’n sterk standpunt inneemt waarvan ze niet willen wijken (ik en vele anderen hebben dat geprobeerd, zie GitHub en de Tagging-mailinglist), dan is meebuigen soms de enige route die je hebt. Op de talk-page van dit voorstel staat een idee om een equivalente taggingoplossing te bieden voor als vlak ingetekende heggen. Dat we ze in Nederland veel gebruiken (dankzij de luxe van de BGT-onderlaag waarover we de beschikking hebben) speelt zeker mee in die gedachte.

Het alternatief van niets doen en gewoon stug area=yes blijven toepassen op barrier=hedge kan ook, maar het maakt de kaart niet beter, en ook andere renderers gaan barrier=* steeds meer zien als een exclusief lineaire feature. Dan werk ik liever naar tagging toe waar Carto wel achter kan staan (de bezwaren tegen area=yes op barrier zijn technisch van aard en toegelicht in de betreffende GitHub-issues), die tegelijk geen afbreuk doet aan de semantiek.

Ik heb niet geschreven dat ik iets mis. Het ontbreekt gewoon. Tweede regel.

Ik houd gelukkig niet heel Nederland bij.

Sorry, ik begrijp niet wat je bedoelt.

Ik vind dit niet alleen taggen voor de renderaar (waar ik nog wel wat nuance in kan zien), ik vind het taggen voor één renderaar en dan niet zomaar omdat het toevallig mooier is, maar omdat de renderaar de juiste rendering (die er gewoon was, dus technisch prima mogelijk) afgeschaft heeft. Veel onjuister kan het in mijn ogen niet worden!

Ik snap je standpunt, en ben het mee je eens wat betreft de ondoordachte en ongecoördineerde actie van Carto, maar wat stel je voor als alternatief? Op de Tagging-ML is men grotendeels van mening dat de huidige tagging in orde is, maar Carto gaat het niet meer aanpassen.

Dat betekent dat mappers die tagging nog wel kunnen gebruiken, maar dat de referentierenderer van het project het pertinent fout rendert, en afgeleide renderers dus ook. Wel staan ze open voor andere taggingoplossingen.

Is dat fijn? Nee.

Hebben ze gelijk in hun redenering? Deels, maar niet volledig overtuigend.

Kunnen wij verandering in Carto afdwingen? Nee. :frowning:

Wordt de kaart er beter van als we de status quo van gebroken rendering handhaven?

Waar we nu op zinspelen in een vervolg op natural=shrubbery is om het probleem vanuit een andere hoek aan te pakken. De tag-combinatie barrier=hedge plus area=yes geeft weliswaar aan dat je het over een heg hebt die als vlak is ingetekend, maar het is ook niet de meeste elegante oplossing. In de basis zijn heggen en bosjes allebei door mensen beheerde natuur in de vorm van bosjes of struiken. Een simpele renderer die de focus niet op algemeen gebruik heeft zou bosjes en heggen prima dezelfde groene kleur kunnen geven. Met dat als uitgangspunt willen we kijken wat nou de eigenschappen zijn die je nodig hebt om iets een ‘heg’ te noemen, en hoe een renderer die wel nuances heeft op dat vlak daar iets mee zou kunnen.

Één eigenschap hebben we vrij helder voor ogen: de ‘dichtheid’ van de begroeiing kun je relatief goed inschatten als je daar (bijvoorbeeld) waarden als ‘dunbegroeid’, ‘middel’, en ‘dicht’ aan hangt (en in documentatie daar goede voorbeelden bij geeft). Dit is op het gebruik van wood:density voor natural=wood gebaseerd. Dus met natural=shrubbery plus shrubbery:density=dense heb je al één onderscheidend kenmerk van de meeste barrièreheggen te pakken. Als je aan de hand van de dichtheid de rendering ook ‘dichter’ (drukker of voller) maakt, heb je in ieder geval een alternatief voor barrier=hedge plus area=yes.

Andere kenmerken waaraan wellicht te denken valt zijn shrubbery:sculpted, zijn deze struiken in een vorm gesnoeid? Een generieke ‘yes’ of misschien iets als ‘box’ gaat voor veel heggen die als barrière ingezet worden zeker op.

Verder blijft de hoogte natuurlijk een kenmerk die bij heggen relevant kan zijn.

Voor navigatie veranderd er niet echt iets. Bij normale voetgangersrouting zou een slimme renderer je best over een grasveld kunnen sturen als daar geen pad ligt, maar niet door bosjes, of het nou een heg is of niet. Alle bosjes zijn voor de meeste voetgangers barrières, net als natural=water dat is.

Dit zijn nog ruwe ideeën die we later in een draft uit zullen werken. We hebben dit met opzet losgeweekt van de eerste iteratie van natural=shrubbery, omdat het een lastig probleem is. Maar: het idee is dat we tags introduceren die kenmerken documenteren van een object. Dat een renderer daar dan iets mee kan is mooi meegenomen. Het voorstel lost dan zeker een renderingprobleem op, maar de tags zijn ook zonder dat aspect correct en valide.

Let wel: ik ben het helemaal met je eens dat de manier waarop de Carto maintainers de rendering van een vastgestelde tagging-combinatie eruit sloopten niet is hoe het hoort. Er zit best wel een iets in hun uitleg wat het redelijk genoeg maakt om een alternatief voor te stellen. Alleen: dat deden ze niet. Stap één was „we slopen het eruit”, en stap twee „kom maar met een voorstel om het anders op te lossen”. Ik heb mijn best gedaan om daar goede argumenten tegenin te brengen, en anderen met mij, maar Carto weigert om het terug te draaien. Nu worden de heggen in Nederland gerenderd op een manier die er niet uit ziet:

Terwijl ondertussen OSM in de standaardlaag Carto op ontiegelijk veel plaatsen gebruikt wordt. Ik kom het overal tegen; gisteren nog bij het aanvinken van een Bever-filiaal voor het ophalen van bestelde schoenveters. En waar grotere media nog wel hun eigen OSM-rendering gebruiken (via diensten zoals LocalFocus), werken lokale media vaak dankbaar met Carto screenshots (de Leeuwarder Courant regelmatig). Het staat dan nog al amateuristisch als een groot vlak ‘heg’ er uitziet als hier boven.

Dus dan lijkt mij dat de keuze effectief tussen de poot stijf houden en area=yes blijven toepassen op barrier=* is, of om tagging te vinden die hetzelfde doet, op een manier die taxonomisch verantwoord is (dus de tags zijn op zichzelf ook correct), en die straks ook weer goed gerenderd kan worden. Ik was in eerste instantie van mening dat vasthouden aan de tagging beter was, maar dat maakt de kaart uiteindelijk niet beter. Bij alle heggen die nu netjes ingetekend zijn met area=yes loop je het risico dat ze op termijn vervangen worden natural=scrub of zoiets door mappers die dit als een bug zien. Moeten we als Nederlandse OSM-gemeenschap die mappers er dan steeds weer op wijzen dat we deze tagging gebruiken uit principe en dat de gebroken rendering geaccepteerd wordt? Ook merk ik bij mezelf een weerstand om een heg in te tekenen nu, ook als dat wel logisch is vanuit de kaart gezien; ik ben vast niet de enige die dat heeft.

Nog een losse gedachte: misschien dat Matthijs Melissen (als Nederlandse maintainer van Carto) het standpunt van Carto eens kan toelichten aan de NL gemeenschap?

Begrijpelijke argumenten, maar mijn reactie in het algemeen daarop is dat de gekte bij Carto een keer zal ophouden. Ik zou daarvoor niet de kaart aanpassen.

Het gaat met heggen nu net als met stijgers en pieren, als je er voor kiest om het geheel juist op te nemen en daarmee netjes en nauwkeurig werkt wordt een pier op de manier van de heg weergegeven. Maar Carto kijkt dus ogenschijnlijk ook niet naar de breedte van heg noch pier, niet juist denk ?
Maar dat kan Mathijs dan gelijk toelichten, misschien in de volgende digitale Geo meeting ?
Of wil ie terug naar het oude lijnenspel ? Waarbij alle wegkenmerken (dus al het meubilair) aan die ene lijn worden gehecht, want daar horen ze thuis, toch ?
Persoonlijk niet mijn idee, daarmee verdwijnen dan alle man made bridges, is dat gewenst ?

Het zorgt op de lange termijn ook voor objectievere data waar OSM over het algemeen van profiteert. Nu is vaak de vraag, heeft een vlak een barrier functie of niet. Door objectief te beoordelen wat de dichtheid van een struikgewas is neem je die discussie weg. Laat het over aan de data gebruiker (waar carto ook een van is) om te bepalen bij welke dichtheid een struikgewas een barrier functie heeft. Verschillende projecten zullen daar waarschijnlijk verschillende wegingen aan hangen.

Niet helemaal eerlijk om het op “de man” te spelen.
Carto maakt beslissingen, niet de persoon die er (mede) aan werkt.
Ik begrijp de beslissingen die carto maakt meestal wel.
En daar is Jeroen een oplossing voor aan het bedenken, door de community hierbij te betrekken, en zo “heurt” het.

Ik kan me nog goed herinneren dat rond 2014 de parkeerplaatsen ineens een andere kleur kregen (mede met andere kleurscharkeringen, die iewat flateus overkwamen in vele ogen). Vermoedelijk is iedereen er inmiddels aan gewend geraakt, maar destijds was de “wereld” te klein.
Toch sta ik achter die beslissing die genomen is.

Wil je invloed uitoefenen lees dan de daarvoor bestemde githubpagina eens door, maak een account voor github en probeer je wensen kenbaar te maken.

https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aopen

Kritiek geven is makkelijk, als je je inleest kun je misschien begrip opbrengen voor wat de “jongens” (cq “meiden”) bij carto doen

Petje af voor carto.