Complexe "waterway" relaties

Kort gezegd: ik stel voor om tributary segmenten uit waterway relaties te halen.

Ter introductie en achtergrond: rivieren, kanalen en beken worden doorgaans gemapt als een relatie met type=waterway. De segmenten met loop van de waterwegen (waterway=river/stream/canal) krijgen hierbij de rol main_stream of side_stream (hoofdstroom en zijstroom).

Dat klinkt naar mijn idee helder, maar sommige mappers voegen aan deze relaties ook alle andere stromen toe die uitmonden in deze waterwegen. Niet de segmenten, maar de volledige waterway relaties. Dit zijn de zgn. tributary rivieren. Hiermee worden de waterway relaties in feite super-relaties. Met name @Tilia_J is hier zeer bedreven in.

Mijn voornaamste struikelpunt is dat tributary segmenten compleet andere waterwegen zijn, die als losse objecten gemapt horen te worden. De simpele relatie voor een enkele waterweg wordt ineens “waterweg met alles wat erin uitmondt.” Naar mijn idee past dit niet in het doel van de waterway relatie. Dit lijkt me meer iets voor een (super-)relatie die slaat op stroomgebieden, maar dit zou een aparte relatie moeten zijn en niet de waterway relatie die slaat op de segmenten van een enkele waterweg.

Daarom stel ik voor om de waterway relaties alleen te gebruiken voor hoofd- en zijstromen van waterwegen, en dat we zijrivieren en andere waterwegen die uitmonden in een bepaalde waterweg compleet los mappen met niet meer dan een destination=* tag.

3 Likes

Klinkt prima, dit sluit volgens mij goed aan op wat er op de wiki en bijbehorende talk-pagina staat.

Hier word ik toch echt een beetje “pissig” van

Toen ik begon met het mappen van de structuur van waterwegen en hiervoor de door mij aangelegde relaties beter wilde benutten stond “tributary” gewoon als “role” in de relation:waterway beschreven met als opmerking “De-facto, has advantages and disadvantages”.

Dat was nog in de tijd voordat ik kennis had van het bestaan van Overpass QL maar het leek mij, die thans werkzaam is in de software-industrie (QA Engineer, geen programmeur) volstrekt logisch dat een dergelijke query-language zou moeten bestaan en dat het gebruik van tributaries mij in de toekomst zou helpen om met behulp van een query hele stroomgebieden op te halen.

Nu lees ik net deze discussie op het wiki dat het toevoegen van de tributary role het werk is van een eenling zónder een daar voorafgaand review- of approvalproces.

Inmiddels heb ik met vallen en opstaan mij wat overpass-QL eigen weten te maken (weet nog steeds niet hoe ik een “SQL inner join” voor twee overlappende gebieden voor elkaar krijg) en wat bruikbare queries bij elkaar heb gehackt voor de waterways.

Als zodanig heb ik die tributaries dus niet nodig en als iemand zich geroepen voelt om deze weg te halen: Have Fun!

Rest de vraag: Waarom dit bericht terwijl “tributary” nog steeds op de wiki bestaat?

[RANT] Ik ben dus een voorstander van zuiver, conform specificatie werken. Dat iedereen een nieuwe tag aan het wiki kan toevoegen is nog tot daar aan toe, maar dit is de zoveelste keer dat ik door het wiki op het verkeerde been gezet ben over meer structurele zaken. Ik vind het werkelijk waar onbegrijpelijk dat er niet een GitHub-achtig proces hiervoor bestaat met verplichte review door een minimum aantal approvers op basis van een goed beschreven wijzigingsverzoek met daarin een analyse welke wiki-pagina’s door de wijziging geraakt worden en óf / hoe de betreffende feature door bepaalde data-afnemers gebruikt wordt. Het OSM-wiki hoort als een specificatie gelezen te kunnen worden maar dat is het dus niet [/RANT]

@Tilia_J Vat het vooral niet persoonlijk op. Ik ben heel dankbaar voor je werk binnen OSM. Ook ben ik het met je eens dat de Wiki documentatie hier niet aan een consensus voldoet.

Is het jou al gelukt om een Overpass query te schrijven voor stroomgebieden? Daar heb ik namelijk wel interesse in.

Vooral omdat ik de Wiki ook niet als eenling zonder consensus wil aanpassen. Als we het in dit topic eens kunnen worden dat de tributary role niet past in een waterway relatie, dan kan ik dat op de Talk pagina van de Wiki plaatsen en dan hebben we een breder draagvlak om dit uit de Wiki te verwijderen of tenminste als “controversieel” te markeren. Ik wacht nu vooral op meer instemming om dergelijke woorden kracht bij te zetten. Elke mening lees ik graag.

Ah ja, de Tagging Working Group. Deze is zelfs bij de SotM genoemd, maar vooralsnog houdt een groot deel van de community, waaronder ikzelf, vast aan het Any tags you like principe. Ooit wordt OSM volwassen genoeg om hier afstand van te doen, maar vandaag is niet die dag.

Zonder me in de discussie over waterway-relaties te mengen wil ik kwijt dat ik ook wel eens moeite heb met sommige wiki’s: vaak geschreven door een persoon die deze wiki dan in discussies aanhaalt als de referentie, gelijk hebbend of niet doet er dan niet toe, maar het krijgt wel een hoog wij-van-wc-eendgehalte.

1 Like

Ik vat het ook niet persoonlijk op. Ik word hier alleen wel (doordat mijn naam getagged is) in een discussie meegesleurd alsof mijn handelen een onderdeel is van het probleem terwijl ik het als een gevolg van zie.

Immers streef ik er als OSM-mapper netjes werk af te leveren en ik wil als eindgebruiker, op basis van fatsoenlijke regels en documentatie gewoon mijn werk kunnen doen. De realiteit is dat, om fatsoenlijk mee te kunnen draaien je een halve ICT-er moet zijn. Voor mij geen probleem, maar eigenlijk vind ik deze situatie niet fatsoenlijk uit te leggen aan mensen die zich hobbymatig met cartografie bezig willen houden.

Wat ik dus niet zuiver aan deze discussie vind, is dat op basis van een dit voorjaar half gevoerde discussie op het wiki, er nu voor consensus “geshopt” wordt op het Nederlandse deel van Discourse omdat “toevallig” een Nederlander (ik) blijkbaar een groot aandeel heb in die 23.000 tributary roles.

Steeds als ik op internationale pagina’s over mapping praktijken begin wordt er geklaagd dat ik eerst steun bij lokale gemeenschappen moet zoeken. Nou doe ik dat een keer en dan is het ook niet goed. Mijn plan was sowieso al om deze discussie ook internationaal te gaan voeren.

Ik heb jou hier vooral bij betrokken omdat ons mapping gebied overlapt en omdat ik jouw aandeel hierin waarschijnlijk aan ga passen als er een groter draagvlak is voor het weghalen van de tributary role op de kaart en in de documentatie. Laat het ook vooral weten als je het hiermee oneens bent, want daarvoor heb ik dit topic immers aangemaakt.

1 Like

Behalve dat dit wat vreemd geformuleerd overkomt ben ik van mening dat de oplossing ligt bij het éérst adresseren van het wiki. De rest volgt vanzelf. De huidige koers is een kip-ei redenering.

Zie:

Dat is precies mijn plan: ik wil de Wiki documentatie zo aanpassen dat het mappen van tributary wordt ontmoedigd. Dat doe ik liever niet zonder enige instemming. Vandaar dat ik dus dit topic heb aangemaakt.

:+1:

Ik denk dat ik ook een internationaal topic aan ga maken voor een bredere discussie over dit onderwerp.

Ik heb onder de streep toch moeite met de manier waarop Friendly Ghost de zaken voorspiegelt en meent te moeten aanpakken. Daarnaast heb ik mij in de materie verdiept.

Friendly Ghost is al bijna twee jaar op de hoogte van het feit dat ik de tributaries conform de wiki gebruik (zoals deze toentertijd was beschreven) en heeft op basis van voornoemd forumbericht tributaries blijkbaar zélf toegepast

Veranderen van inzicht mág, echter had ik het wel zo attent van Friendly Ghost gevonden om in plaats van mijn gebruikersnaam op de wikidiscussiepagina te droppen mij persoonlijk op de hoogte te stellen dat het gebruik van tributaries controversieel is. Om dan negen maanden later hierboven te gaan schrijven (ik parafraseer) dat ondanks een heldere wik-omschrijving gebruikers hiervan afwijken, met name dus ondergetekende.

Dit terwijl mijn aandeel in de tributaries maar drie procent is. Dat Friendly Ghost mij vervolgens óók nog om mijn Overpass-queries gaat vragen roept bij mij het beeld op dat hij onvoldoende inzicht heeft in de ins-en-outs rond tributaries en dat ík hier tegen mijn zin in word betrokken omdat hij simpelweg geen andere voorbeelden van tributary-gebruik wereldwijd heeft.

Tributaries zijn al sinds 2010 op OSM aanwezig, bediscussierd, in proposals geformuleerd maar uiteindelijk nooit als definitieve proposal door het approvalproces gegaan. In 2016 waren er rond de 4.500 tributary-rollen in gebruik en anno 2022 23.000, oftewel 2,43% van alle waterwegrelatierollen.

In die zin is er dus gewoon sprake van “de facto” gebruik.

Inmiddels ben ik ook van mening dat het gebruik van tributaries om meedere redenen niet wenselijk is.

Aan de andere kant: Tributaries zijn wel een onderdeel van mijn workflow geworden en zorgen ervoor dat ik razendsnel kan werken.

Ik ben actief voor de Veluwse Bekenstichting en mijn aanvankelijke doel om hun bekenatlas (met toestemming) in OSM op te nemen resulteerde in een enorm aantal bevindingen over zaken die niet kloppen en als zodanig intern, bij de Provincie en met het waterschap worden besproken. Inmiddels is de scope verder uitgebreid naar de hele Geldersche Vallei en blijken er hele interessante (cultuurhistorische) verbanden te zijn die uitnodigen tot verder onderzoek.

En vervolgens komt Friendly Ghost interveniëren, die getuge zijn edithistorie een track record heeft opgebouwd van changesets ter grootte van hele landen met als doel een al dan niet vermeende taggingmisstanden op te lossen en daarbij de nodige kritiek oproept, in één geval resulterend in DWG-interventie en een gebruikersblokkade.

Nooit heeft hij interesse voor mijn werk getoond, feedback gegeven of hieraan substantieel bijgedragen. Ik mag aannemen dat hij geen kennis heeft van mijn to-dolijst en dus een massaal verwijderen van alle tributaries niet zal aangrijpen om de kaart daadwerkelijk te verbeteren of de mij bekende fouten zal herstellen.

Mijn uitspraak “have fun” was dan ook meer bedoeld als uiting van mijn irritatie dan een volmondig instemmen.

In dit licht wordt Friendly Ghost’s interventie en wijze van communiceren dan ook niet bepaald op prijs gesteld.

Ik heb, gezien de ouderdom, omvang en wereldwijde reikweidte van deze kwestie dan ook de suggestie aan Friendly Ghost om het formele proces te doorlopen om deze role op status “deprecated” te krijgen.

Dan zal ik er zorg voor dragen dat de door mij aangemaate tributaries verwijderd worden naar gelang mijn hele klus voltooiing nadert.

3 Likes
Ik heb het antwoord van Friendly_Ghost verwijderd:
  1. Speelt op de man

  2. Gebruikt neerbuigende taal

Ik vind het prima als je dit in het café bezigt, maar niet hier.

3 Likes

Ik heb er zoals dat heet nog een nachtje goed over geslapen, en ik blijf bij mijn antwoord dat ik begin deze week had getypt, zonder persoonlijk commentaar uiteraard.

Dit klopt, maar zoals je al hebt opgemerkt ben ik van inzicht veranderd.

Ik had er inderdaad voor kunnen kiezen om je eerst persoonlijk te benaderen en dan de discussie hier te brengen, maar ik heb ervoor gekozen om direct een groepsdiscussie aan te gaan en jou hier expliciet bij te betrekken.

3 procent waarvan een deel in mijn lokale omgeving vind ik significant genoeg om jou persoonlijk in de discussie te betrekken. Ik had je naam ook niet kunnen noemen. Dan had ik misschien de discussie met anderen gevoerd en dan had je het topic wellicht over het hoofd gezien.

Misschien, maar dat neemt niet weg dat er nog controverse is en die breng ik in dit topic ter sprake.

Daar kunnen we wat mee. Als we het met meer mensen hierover eens kunnen worden wil ik zoals gezegd ook internationaal voorstellen om het gebruik ervan te ontmoedigen.

Ik vroeg en vraag nog steeds om Overpass queries zodat we hier een alternatief voor kunnen vinden, zodat een verandering op de kaart niet ten koste hoeft te gaan van jouw workflow.

Ik woon in Bennekom, dus als je nog wat lokale kennis zoekt uit die omgeving wil ik best een keer op de fiets stappen om wat uit te zoeken.

Ik heb helemaal nog geen interventie uitgevoerd. Ik heb alleen een discussie opgestart. Ook heb ik zelf in het verleden een substantieel aantal waterway relaties van grotere rivieren en kanalen gemapt, maar niet van de beken, want daarin heb ik mij niet gespecialiseerd.

Goede suggestie, daar kan ik wat mee. Met zo’n proces moet ik ergens beginnen en ik heb de keuze gemaakt om lokaal te beginnen. In een later stadium kan ik misschien nog wat hulp gebruiken.

Ik ben blij dat we ondanks meningsverschillen toch samen kunnen werken.

Zoals reeds toegezegd zal ik zelf zorg dragen voor het geleidelijk verwijderen van de door mij aangemaakte tributaries.

Dit betekent dat Friendly Ghost zich kan concentreren op die 97% buiten Nederland.

Ik heb voor de rest geen behoefte meer om mij in deze discussie te mengen.

Ondanks het feit dat ik weinig kennis heb over super-relaties en tributaries (in het draadje waarnaar verwezen wordt dacht ik dat het iets met routeerbaarheid te maken had) , kan ik de neiging niet onderdrukken te reageren. Ik waardeer zowel het werk van Friendly_Ghost als Tilia_J, al zijn ze in werkwijze en werkgebied verschillend.

Wellicht ietwat buiten de orde en zonder verwijt: elke bijdrager heeft zijn/haar eigen drijfveer om actief te zijn voor ons project, een eigen werkproces en eigen doelstellingen. Reden waarvoor ik bij de virtuele treffens nogal eens wil vragen naar recente projecten van aanwezigen. Onwetendheid over elkaars werkwijze (of onuitgesproken verbazing) wil nogal eens voor verloren energie zorgen. Wat TiliaJ schrijft over interesse tonen voor andermans werk, geven van feedback of stellen van vragen in het algemeen geldt denk ik voor ons allen. Ik denk dat ons project in dat opzicht meer ‘intermenselijkheid’ nodig heeft. Het is goed om het gesprek daarover gaande te houden (of simpelweg vaker naar elkanders bijdragen om te kijken).

Dat gezegd hebbende: veel plezier allemaal en tot op de kaart!

5 Likes