proposal natural=shrubbery voor struikgewassen en barrier=hedge

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.

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=*