Update van Carto-OSM (standaardkaart) breekt heggen in NL

Een update van Carto-OSM breekt sinds een paar dagen de rendering van heggen die als area zijn ingetekend:

Dit waren ingekleurde gebiedjes, maar zijn nu dik omrande vlakken geworden door de update.

Het gaat dus om heggen die als gesloten vorm zijn ingetekend met deze tags:

barrier=hedge
area=yes

Dit is volgens de documentatie op de OSM wiki correct:

Nou worden er natuurlijk wel vaker dingen aangepast in de standaardkaartstijl, maar in dit geval zijn in één klap meer dan tienduizend heggen in Nederland verkeerd getekend. Dat het ons land zo zwaar treft heeft natuurlijk met de beschikbaarheid van de BGT-lagen van de overheid te maken: wij kunnen daarmee heel nauwkeurig features zoals heggen intekenen samen met eigen observaties en satellietbeelden.

De aanname bij het uitzetten van deze rendering is dat de meeste heggen die als area zijn ingtekend niet echt heggen zijn, maar de meeste heggen die ik in Nederland ingetekend zie zijn dat wel.

Zouden jullie eens willen kijken of deze update in je eigen mappinggebied ook dingen breekt? Voeg in dat geval eventueel hier je feedback toe.

Ja ik liep er ook meteen tegen aan… uiterst storend. Wat was de consenus over het mappen van gemeentelijk groen ook al weer? Ik gebruik zelf altijd deze hedge combinatie. Het zou mooi zijn om te kunnen zeggen dat deze verandering de tagging consensus van geheel OSM NL overhoop gooit, dat is een stuk zwaarwegender dan een enkele mapper die zich er aan stoort, lijkt mij.

Niks wat goed rendert. Goede landcover values zijn geopperd, maar Carto weigert nog steeds landcover te gaan renderen. Eerst zeiden ze dat het onvoldoende gebruikt werd, en toen het boven de genoemde grens kwam kreeg ik ineens te horen dat de absolute aantallen er niet toe deden. Ik hou het op een allergie uit het verleden, waar argumenten nooit tegenop gaan kunnen.

Ik zou zeggen: gewoon landcover=scrub toevoegen aan al die hedge area’s, dan staat de informatie er in ieder geval zodat het gerenderd kan worden door andere renderers en ook door OSM Carto als de redelijkheid indaalt.

Voor algemeen/gemengd/variabel/opvul-groen is landcover=greenery voorgesteld, maar alleen als er geen specifiekere value toegekend kan worden omdat het geheel gemengd is of bij elke onderhoudsronde zomaar anders kan zijn. Of het gemeentelijk is doet er daarbij niet toe, de mapper hoeft dat niet te (kunnen) zien. In ieder geval niet village_green gebruiken, een village green is een heel ander ding (in NL: een “brink” in een dorp). Het rendert wel groen op Carto, maar dat is dan echt taggen voor de renderer.

Behalve heggen in de bebouwde kom zijn er ook bv. maasheggen.
Zie bv. hier: https://www.openstreetmap.org/#map=17/51.61902/6.00882

Dit is geen village green, maar wordt traditioneel gebruikt als afscheiding tussen percelen.

Het is ook geen shrub.
Hier staat een mooie foto van hoe ze er uit zien: https://www.maasheggenunesco.com/

Er lopen wandelroutes waarbij de doorgang tussen de heggen van belang zijn voor de navigatie.

Geven jullie de feedback (eventueel met voorbeelden) ook terug in die pull-request-thread? Zo wordt duidelijk dat dit meer mensen stoort. Ik ben niet overtuigd van de argumenten die stellen dat barrier=hedge plus area=yes meestal fout is. Er zullen ongetwijfeld voorbeelden zijn waar dit wel zo is, maar dat zijn taggingfouten, niet renderfouten.

Wil je een heg als lijn tekenen op een gesloten vorm? Geen area=yes.

Wil je een grillige heg als vorm tekenen? Wel area=yes.

Erg frustrerend, maar hopelijk een kwestie van tijd. Wat ik zelf doe is dubbeltaggen met de voorgestelde landcoverwaarden. Zo toon je aan dat je die tags ondersteunt en dat je die eigenlijk bedoeld, maar dat het voor het instant houden van een goede kaart noodzakelijk is om de huidige waarden ook te gebruiken. Ook kun je op die manier de tags die je zelf geplaatst hebt automatisch opschonen wanneer landcover ooit wel gerenderd wordt.

Dus:

Grasvlakken:


landuse=grass
landcover=grass

Bosjes:


natural=scrub
landcover=scrub

Bosschages, bomen die niet los ingetekend zijn:


landuse=forest
landcover=trees

En heggen als area zoals bovenstaand.

Ervaring leert dat “imagico” niet voor rede vatbaar is. Hij wil hiermee zijn voorkeur voor tagging opdringen. Een renderer zou dat niet moeten doen. De renderer kan wijzen op tagging die onmogelijk te renderen is, maar dat is hier niet het geval. Er werd namelijk prima gerenderd, en nu ineens niet meer!
De gevallen die hij als probleem aanwijst zijn taggingfouten, niet volgens de wiki’s getagd.
Ik ben het wel met hem eens dat het eenduidiger of eenvoudiger zou kunnen, maar dan moet je wel een werkbaar en goed renderend alternatief hebben en een overgangsplan. Bijvoorbeeld bijtaggen met landcover=hedge of natural=hedge met de toezegging dat dat gerenderd wordt zoals nu barrier=hedge+area=yes, en dan een datum zeg 3 maanden verderop aankondigen waarop barrier=hedge+area=yes niet meer als area gerenderd wordt.

Hoe er dan precies als alternatief getagd gaat worden is aan de taggers, gewoon een paar ideeën voorleggen en dan turven waar de meeste steun voor is.

Zo moeilijk is het allemaal niet! Maar ja, ego’s he?

Ik heb de indruk dat deze render verandering blijft hangen.

In dat geval stel ik voor om met zn allen in Nederland het bekende ‘algemene/gemeentelijk groen’ (m.u.v. gras en bos natuurlijk) voortaan als landcover=greenery te taggen. Aangezien nu geen enkel van de opties correct wordt gerendert hebben we niet veel te verliezen. landuse=greenery is gedocumenteerd op de wiki, en ook al vaker voorgesteld hier op dit forum, maar nog maar weinig in gebruik, vermoedelijk ook sterk beïnvloed door het (nog?) niet renderen van de betreffende tag. landcover=greenery lost ook meteen het probleem van identificatie op, staan er nou boemen of heggeplantjes?

Wellicht lost dit het probleem voor eens en voor altijd op, mits het rigoreus wordt gedaan door ons. Als we dan tienduizend groenvlakjes verder zijn kunnen we misschien wel bij carto aankloppen.
Wat denken jullie?

Als het is bedoeld om struiken aan te duiden dan zou ik dat ook zo benoemen. (Er is een reden waarom die discussie niet verder komt.) En de discussie over hagen is nog niet afgerond wat mij betreft.

@Ninjoh
Dat lost het probleem van die heggen niet op. Je wil aangeven dat het een barrier is die een te grote of grillige oppervlakte heeft om als lijn aan te geven. Dus barrier=hedge moet blijven staan, maar landcover=greenery is dan niet juist, want greenery kan van alles zijn maar je wil in dit geval precies aangeven dat het in zijn geheel heg is.
Dus dan zou ik ervoor zijn om landcover=hedge te taggen, en wel als toevoeging op de barrier=hedge.
landcover=scrub is ook voorgesteld, maar daarbij zou je dan een dichtheid moeten aangeven want scrub geeft niet aan dat het zo dicht op elkaar staat zodat je er niet doorheen kan.

Overigens, ik kwam er wel heel veel tegen die erg klein zijn, waardoor je je af kan vragen of je die niet gewoon zo kan laten staan. In de OSM Carto rendering maakt het bij die heggen weinig uit.

Voor de rest ben ik zeker voor (bij)taggen van gemengd of variabel opvulgroen als landcover=greenery. Als later op die plek een meer vaste begroeiing ontstaan kan er een van de meer specifieke tags gebruikt worden. Mikromappers genoeg!

landcover=scrub heeft naar mijn indruk een wat meer wilde associatie, van bosschages en dergelijke die niet wood of forest waardig zijn, zoals de bijbehorende afbeelding op de wiki pagina illustreert

Het probleem van echte heggen taggen blijft inderdaad, en landcover=hedge lijkt me een aardige oplossing.

Zulks overig of onidentificeerbaae opvulgroen tag ik voortaan maar als landcover=greenery

Dat is precies het onderscheid dat ik ook altijd maak. Kinderen zullen er niet gaan spelen.

message

Hij maakt ze alleen dikker doordat de buitenlijn nu een dikte heeft. :frowning:

Ik heb deze draad wat gevolgd maar ik begrijp het niet: we zouden toch niet taggen voor de renderer? Fietspaden staan er ook niet zo prominent op als ik zou willen, maar ja. Er is altijd nog openstreetmap.de of een andere variant. Of je legt een eigen laagje met correctie over de kaart. Maar allerlei alternatieve tags gebruiken omdat je een groen vlak wil lijkt mij nou net niet in de geest van OSM?

https://en.wikipedia.org/wiki/Shrubbery

let op met sh

categoriseren, de hiërarchie, tot in detail.
De heg is een verschijningsvorm, meerdere vormen mogelijk. Zo is ook de vormgeving onderhoud te beschrijven.

Door vast te houden aan zeer vroeg in gebruik zijnde tags, welke nu hogere aantallen hebben en daar naar toe te verwijzen.

Haal je weef fouten niet uit OSM, blijft de discussie steeds maar door gaan.

OSM en kwaliteit, door het beter te benoemen stijgt de kwaliteit van de data in OSM.

Mijn inzien wenselijk, anders blijft de discussie.

Carto, gezichtsbepalend, mensen willen het daar graag zien en nemen aan wat gevisualiseerd is, is goed.
Als Carto zich houdt aan oude principes staan ze de kwalitatieve beweging van OSM enigszins in de weg.

area:barrier=* lijkt mij een goede aanvulling, is voor alle barrier welke een vlak zijn te gebruiken. Zelfs de combinatie met area:highway=*

area=yes is dan gelijk verweven in 1 tag. Waar hoort de area=yes bij?
Stel je hebt een volledig omheind vlak, barrier=fence kan er op, dit kan de fence lijn visualisatie geven. Het vlak area:barrier=hedge, vlak ingekleurd, grond met icoon.
Je hebt zo meer speelruimte om met tags te werken. Zodat het de juiste visualisatie kan geven.

landcover is ook mogelijk.

Er was barrier=hedge+area=yes, gedokumenteerd en gerenderd. Nu rendert het ineens niet meer goed. De renderer claimt dat de tagging principieel fout is en renderproblemen geeft. Dan is het logisch om te kijken naar alternatieven. Niet alternatieven die het gewenste kleurtje geven, maar alternatieven die de “principiële fout” niet bevatten en beter renderbaar zijn.

Overigens ben ik het er niet mee eens dat het principieel fout is en het kan wel degelijk goed gerenderd worden, wat Carto tot voor kort ook deed. Ik ben het al helemaal niet met met de manier waarop dit aangepakt is, namelijk de renderer forceert andere tagging ipv het probleem te melden en de taggers/mappers om een breed gedeelde oplossing te vragen.

Overigens is dit volgensmij echte scrub https://en.m.wikipedia.org/wiki/Shrubland

Sorry, ik kan het niet laten… the knights who say “Ni!” :wink:

Dan heeft het verwacht ik ook geen zin om ook de specificaties als hoogte, breedte of soort van een heg aan te geven, denk ?
Dat wordt dan waarschijnlijk ook niet gebruikt bij de rendering of is dat dan handig in de database voor als er een intelligente renderer of Carto komt ?

Door sommige 3D-renderers (in elk geval F4Map) wordt al gebruik gemaakt van de hoogte van heggen.

edit:
Voorbeeld: F4Map (Vereist WebGL) Mijn hagen staan er nog steeds netjes bij.

Ik verwacht niet dat mensen gaan zoeken op heggen maar aan de hoogte kun je bijvoorbeeld zien of het gebied erachter zichtbaar is (denk aan verkeer).