proposal natural=shrubbery voor struikgewassen en barrier=hedge

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.

Nee zeker niet de bedoeling. Ik noem Matthijs enkel omdat hij vanuit de hoedanigheid als Carto-maintainer kan spreken (in het Nederlands). Ik vat samen wat in die GitHub-issues benoemd is, maar ik ben wat Carto betreft slechts een contributor die af en toe drive-by-commits aandraagt.

Tja, ik niet. Ik snap nog altijd niet waarom scholen wel visueel herkenbaar moeten zijn en parkeerplaatsen niet. Naar scholen ga je niet dagelijks op zoek, naar parkeerplaatsen vaker.

Ik heb het ook opgegeven met die cartojongens. Die hebben hun mening en een buitenstaander komt daar niet tussen. Goed, dan doe je maar je ding, maar het idee dat iedereen die niets zegt het er mee eens is wil ik even heel erg krachtig ontkennen.

Een probleem is dat de taggingpeople het niet over renderen mogen hebben en de renderpeople zich niet met taggen mogen bemoeien, terwijl het heel vaak belangrijk is om goed te overleggen en af te stemmen. Als de renderer een serieus probleem heeft met bepaalde manieren van taggen, dan moet er gewoon overlegd worden hoe dat opgelost kan worden. Dan zet je dat uit in diverse forums en gremia, je kiest een bepaalde oplossingsrichting, maakt een invoeringsplan en kiest een datum waarop het in zal gaan. Zo zou het moeten.
Nu kan je iets met veel moeite door het approval proces heenslepen waar anderhalve man en een paardenkop hun stokpaardjes berijden, vervolgens moet je bij alle afzonderlijke renderers en datausers smeken om het ooit een keer door te voeren, en dan maar afwachten of het ooit gebeurt, en ondertussen komt er overal waar ze er plotseling achterkomen dat er iets veranderd is een trage storm van achterafprotest en stug verzet op gang. Ja, ik overdrijf een beetje, maar ik weet zeker dat het herkenbaar is! En de renderer legt zijn probleem niet voor aan de tagging list, want dat is not done, maar overvalt de rest met een wijziging waar ze zelf maar achter moeten komen, en staat niet meer open voor andere oplossingen. En iedereen heeft gelijk, natuurlijk. Daar gaat het ook niet om, of zou het niet om moeten gaan.

1 Like

Toen ik nog voor Mapillary fietste was het moeilijk een parkeerplaats voor de auto te vinden op het gewenste zoom niveau.
Nu ik enkel defibrillators fotografeer die geregeld aan scholen hangen is het geel wel handig. Maar dit is inderdaad maar 1 keer.

Vroeger was het beter.

De blauwe P is duidelijk, maar de vlakkleur is nu inderdaad erg grijs en valt snel weg. Dit maakt de samenhang wat vaag bij grotere en vreemdgevormde parkeerterreinen. De gele kleur zal niet snel terugkomen, maar een blauwe tint lijkt wel wat kans te hebben. Ik heb in mijn pull-request voor het anders renderen van parking=street_side daar ook mee geëxperimenteerd (zie de laatste twee afbeeldingen van mijn inleiding daar). Geef het zeker door daar als je dat een verbetering vindt ten opzichte van het grijs van nu.

Ik denk dat er zeker eens gesproken moet worden over hoe Carto zijn aanzienlijke invloed aanwent, en dat ze wellicht sneller de gemeenschap moeten betrekken. Nu wordt je inderdaad overvallen door veranderingen. Dat is prima als er een nieuwe feature bijkomt, maar bij wijzigingen met een grote impact mag er echt wel wat meer overleg zijn, bijvoorbeeld via de Tagging-ML. Het is voor de meeste mappers ondoenlijk om de GitHub-repo van Carto bij te houden op wijzigingen die er aankomen.

De dichtheid kan toch niet bepalend zijn of iets als een barrier funktioneert? Er zijn barriers, de mapper geeft aan of het een barrier is, en die zijn soms lineair en soms een vlak.
Om dat aan te geven met een natural plus een density en daaruit de konkusie laten trekken door de datauser dat het een barrier moet zijn, vind ik heel, heel gek. De rondgesloten hedge opvullen met iets wat er precies zo uitziet (natural=hedge?) lijkt mij dan nog logischer. Al zou ik bij een hele dikke muur ook niet weten welke opvulling je dan moet geven. (Carto gebruikte o.m. problemen met dikke muren als reden om de heg ineens anders weer te geven - terwijl dat juist de taggingfouten waren…).

Niet in alle gevallen inderdaad. Maar er zijn ook genoeg gevallen waar verschillende mappers (zeker bij vlakken) wel of geen barrier functie aan een vlak koppelen. Onderstaand voorbeeld. Twee mappers zullen het er over eens zijn dat de dichtheid zo hoog is dat je er niet doorheen kunt navigeren. Persoonlijk vind ik dit echter niet een barrier=hedge maar shrubbery maar een andere mapper zal het hier mee oneens zijn.

Maar dat is iets wat bij het uitwerken van de tag maar eens bekeken moet worden. Misschien is er een goede tussenoplossing met bijvoorbeeld het gebruik van shrubbery=* en shrubbery:density=*

De kleur van de P+R in de plaatjes is #EEEEEE en #EDEDEF. Dat is niet zichtbaar als een andere kleur, alleen als je ze naast elkaar legt en goed bekijkt.
In de kaart valt dat niet op.

Het valt niet op, maar het werkt toch, de vlakken springen er beter uit.

Hallo allemaal,

Ik ben het niet eens met je zienswijze Jeroen, dat weet je van mijn reacties op de Tagging-ML. De “foutieve” rendering in Carto heeft niet enkele gevolgen gehad voor heggen, maar ook voor andere barriers, met als belangrijkste wanden en muren. Ook die worden nergens nog als vlak gerendered. Een nieuwe tag=shrubbery gaat dat zeker niet oplossen. De oplossing in CArto is gekozen omdat veel percelen die omheind zijn, met wat dan ook een muur, een heg etc… niet afzonderlijk zijn ingetekend. We hebben dus door de jaren heen veel scholen, huizen ed. gekregen waar zowel de barrier=* tag aanwezig is als de area=* tag, zonder dat daarmee door de gebruiker bedoeld werd dat het om de heg gaat die als area moest gezien worden. Carto heeft het zich dan gemakkelijk gemaakt en gezegd van OK, alle heggen en wanden worden dan maar lijnen. Dit terwijl ze makkelijk het onderscheid kunnen maken, als ze de moeite nemen om te testen of de barrier=* tag enkel gebruikt is in combinatie met area=yes, dus als primaire tag, en niet gecombineerd met een andere area tag zoals bv. amenity=* of landuse=. In die gevallen, die ze eenvoudig kunnen testen dienden ze de heggen en muren blijven renderen als vlakken. Ik ben het niet eens dat we carto niet op andere gedachten kunnen brengen. Met genoeg protest en overtuiging dat dit een grandiose blunder is zullen ze wel moeten, teninste als ze de referentie willen blijven.
De andere argumenten ken je, ik was vanaf het begin een tegenstander om een nieuwe top tag in het leven te roepen. Scrub is absoluut niet een term voor enkel “onderhouden” bosjes en struiken. In de definitie staat ongelukkeiger wijze “uncultivated land”, wat letterlijk betekent “niet op een akker”. Neem je dat weg uit de definitie dan kun je het hele probleem terug brengen dat alle bosjes en struiken, of ze nu onderhouden zijn of niet, perfect onder scrub passen. En geloof me, wereldwijd gaat het om tienduizenden gevallen waar dat ook zo is toegepast.
Scrub omvat alle bosjes, struiken en “in groei gestuite” boompjes. Wat je met shrubbery nu gaat creeeren is een nieuwe tag die expliciet zegt dat scrub foutief is gebruikt in duizenden gevallen, het wil gaan “misbruiken” om een heg rendering probleem op te lossen, waar velen dan zullen komen met het identieke probleem voor muren en wanden, en bovendien een term wil gebruiken die niet begrijpelijk of vertaalbaar is, zelfs in het nederlands.
Mijn inziens had je moeten blijven bij het oorspronkelijk voorstel, natural=scrub en scrub=
waar je dan kan aangeven of het om shrubbery of enkel shrub of bushes of stunted trees gaat of welke variant dan ook. We geven toch ook geen individule nieuwe top tag voor alle aangeplante bossen ? Dat is en blijft gewoon bos. Of dat nu op een akker groeit of niet, het is en blijft bos, het is en blijft bosjes of struikgewas. Maar hod aub de heggen uit de dicussie, dat is een totaal andere problematiek.
We zullen zien wat de uitkomst wordt van de stemming, maar ik vrees ervoor. Het helpt ook niet om en mass de “Nederlanse” visie erdoor te pushen. Je ziet de anderen al komen. Het is de kunst om een compromis te vinden, dat niet te veel breekt, en zeker niet een rendering issue als mogelijke oplossing bied. Vele heggen zijn niet onderhouden, dus hoe ga je dat klaar spelen om al die area=yes tags te vervangen door natural=shrubbery of natural=scrub.
Aanvaard dat scrub niet betekent “wild”, net zoals forest niet betekent een “wild” bos, of grassland niet betekend een “wild” grasland.

Op deze, we proberen niet de Nederlandse visie er doorheen te duwen. Het klopt, we hebben veel toepassingen voor natural=shrubbery in Nederland maar we zijn zeker niet het enige land. Ik heb bijv. met veel Amerikanen en Britten gesproken die er ook voor gebruikstoepassingen voor zien. In Amerika heb je bijvoorbeeld grote parkeerplaatsen met struikgewassen er tussen [1][2]. Daarnaast, hebben zei juist erg de voorkeur voor een aparte tag uitgesproken. Veel Engels sprekende mensen associëren natural=scrub juist zoals bedoeld met de wilde scrublands en shrubbery meer met de decoratieve en onderhouden struikgewassen. Daarnaast, kijk maar eens op overpass [4]. Op verschillende plekken steunen mensen het al.

En wat van deze [3]? Dat is geen scrubland maar ook geen barrier=hedge. Dit is momenteel getagd als natural=shrubbery.

[1] https://www.openstreetmap.org/way/914194442
[2] https://www.google.nl/maps/@41.6883329,-71.4996368,3a,75y,23.15h,68.05t/data=!3m7!1e1!3m5!1ssptWEBmP6P0eTWjbBttxlA!2e0!6shttps://streetviewpixels-pa.googleapis.com/v1/thumbnail?panoid=sptWEBmP6P0eTWjbBttxlA&cb_client=maps_sv.tactile.gps&w=203&h=100&yaw=53.26008&pitch=0&thumbfov=100!7i16384!8i8192
[3] https://www.google.nl/maps/@52.243813,5.3640007,3a,75y,324.32h,79.62t/data=!3m6!1e1!3m4!1s7zjxtEdUKzS75Osi3aMf8A!2e0!7i13312!8i6656
[4] https://overpass-turbo.eu/s/150l