water=sloot

Dat is in algemene zin zeker een goed advies, maar ik geloof niet dat dat hier aan de orde is; heb bijgevoegde kaartje van heel Nederland juist bijgevoegd om aan te geven dat het probleem met zeer grote dichtheid aan sloten, waardoor mappen als lijnelement onzalig is, niet in heel NL (maar ook niet alleen in het westen en zelfs niet in alle polders, want daarin zijn ook duidelijk verschillen) speelt.

Willekeurige polder in veenweidegebied (zelfde als eerdere overpass-plaatje), BGT

BGT, zelfde schaal, rond Zevenaar (het deel van Waterschap Rijn en IJssel dat op hun legger de grootste dichtheid aan watergangen laat zien:

Het landelijke plaatje van het clo laat al zien dat “het oosten” zeker niet zo droog is als de Veluwe, maar zowel het landelijke plaatje als dit beeld uit BGT laten toch een hele andere intensiteit aan watergangen zien dan in veenweidegebied.

Mijn persoonlijke beeld (ik wandel/fiets/kano graag ook buiten het westen), is dat het buiten het veenweidegebied -generaliserend gezegd- bij de kleine -en meest voorkomende- elementen dit je op de BGT ziet dan vaak gaat om sloten zoals in het plaatje dat Kogacarlo op het Duitse forum postte:

iL4oDh3.jpg500×521 61.8 KB

Begrijp me ajb niet verkeerd: voor *een dergelijke watergang * (hoe we 'm ook noemen) heb ik niets tegen het mappen als (alleen) lijnelement met als waterway=ditch : de breedte in het veld is erg beperkt, waardoor het niet heel erg de moeite is om er een vlak van te maken (dat wordt vanaf een breedte van zeg 2 meter naar mijn idee wel interessant). En in samenhang daarmee: de dichtheid van deze elementen is hier ook niet zodanig dat je renderers -in algemene zin, dus niet alleen OSM standard- niet op voorhand met een onmogelijke opgave opzadelt voor behoorlijke rendering (wat ook weer voortkomt uit het niet-onerscheidende karakter van ditch qua breedte).

Ook past waterway=ditch (dus lijnelement) naar mijn idee in zo’n geval prima met de omschrijving in de wiki:

Maar in veenweidegebied is dat dus echt anders:
niet alleen de dichtheid is veel groter (dus renderingsproblemen in ratio land/water bij gebruik lijnen ipv vlakken) en de breedte is dusdanig (ook kleine poldersloten zijn doorgaans al 2 meter breed) dat het mappen als lijnelement eigenlijk altijd al een lapmiddel is, om de extra moeite van mappen als vlak te vermijden (extra lastig door de landvulling van 3Dshapes met grasgrenzen op de plek waar eigenlijk de sloot

Maar dat lapmiddel doet naar mijn idee meer kwaad dan goed: niet alleen voor de *rendering *(afhankelijk van zoomniveau -maar grotendeels onafhankelijk van de renderer- staat de halve polder onder water of is slechts 0,5% water), maar ook voor de database zelf en de mogelijkheden voor verdere bewerking / verbetering.

Zie bijvoorbeeld onderstaand voorbeeld (geselecteerde ways zijn waterways, soms op de landuse-scheiding, soms ernaast en daarnaast ook als outers van een flink aantal multipolys):

Zoals Andries al opmerkte is mappen als vlakken hier beter, maar inderdaad veel werk.
Zelf ga ik daar dus met mijn importvoorstel aan de slag en in “mijn gebied” zullen die onzalige waterways daarmee ook geleidelijk verdwijnen (want vervangen door vlakken). Daarbij zou het leuk zijn als ik in aanvulling op de natural=water nog een tag kan toevoegen die beter past dan water=ditch, maar zonder kan het ook.

Maar wat denk ik belangrijker is -Andries heeft gelijk dat het echt nog wel even zal duren voordat watergangen die je als vlak zou moeten mappen dat ook in heel NL zijn- is om tot die tijd een praktische manier te vinden om niet goed passende waterway-lijnelementen (die later vlakken moeten worden) geen hinder meer te laten veroorzaken op de kaart en in de database.

Wat mij betreft zouden dergelijke lijnelementen (dus in veenweidegebied, niet de sloot in bovenstaande foto van KogaCarlo) op zich helemaal verwijderd mogen worden voor zover ze geen routeerbare route representeren of naam van een kanaal dragen. Dat lost gelijk de ellende met editten op en ook de situatie dat een aangesloten waterpartij voor het ene deel als vlak en voor het andere deel als lijn is gerepresenteerd. Maar dat zal sommigen wellicht te ver gaan, en dan is -als er toch kritisch wordt gekeken naar drain vs ditch het ook een mogelijkheid om een andere tag te gebruiken, eentje die *niet * gerenderd wordt (en zo het renderingsprobleem oplost), maar die mappers vertelt “hier is een element dat nog een keer in een vlak moet worden omgezet”)

En of die tag nou “sloot” is of iets anders maakt me ook weinig uit, ik denk dat het een aardige optie is waarbij best een goede afbakening / toelichting bij te geven is, maar dan moet er wel een bredere steun en wil toe zijn om dat te helpen verbeteren. En dat laatste merk ik niet nog zo, zal in dit deel dan ook maar even geen moeite meer stoppen en me verder richten op het zo goed mogelijk weergeven van het water hier in vlakken, daar heb ik mijn handen al vol aan.

Een reactie op deze, op zich constructieve suggestie was nog blijven liggen:

De grap was juist dat ik een tag wil voorstellen die als waterway *niet * wordt gerenderd
(en daarnaast zit de aanleiding ook in de kwaliteit van de database en de bewerkbaarheid daarvan).

Zou natuurlijk mooi zij als dit wel enigzins acceptabel wordt gerenderd maar dan zouden we een heleboel renderers moeten gaan overtuigen om hun rendering aan te passen aan landschapskenmerken die heel specifiek zijn voor een deel van Nederland en mapgedrag dat eigenlijk vooral -goed voorstelbare- luiheid is. Zo koloniaal zou ik niet willen zijn. En bovendien: echt goed is dat zonder breedte-informatie ook niet mogelijk, om geen gedonder te hebben met ontbrekende breedte zou je dat weer compleet moeten hebben en dan kan je het toch beter als vlak mappen…)

Ook de simpelste oplossing (render ditch/drain iig in OSM standard Carto niet vanaf z13, maar vanaf bijvoorbeeld z=15 te renderen) is eerder al voorgesteld en afgeketst door diverse andere strijdige fenomenen, die wellicht in grotere gebieden spelen dan alleen ons veenweidegebied:
https://github.com/gravitystorm/openstreetmap-carto/issues/1101
(met dank aan Allroads voor het wijzen op zijn verzoek : https://github.com/gravitystorm/openstreetmap-carto/issues/2629 )

Mocht er iemand zijn met ervaring in het openstreetmap-carto-gremium die die de z=… discussie daar nog een keer wil aanzwengelen; ik zou je dankbaar zijn en voel je vrij om de hier (en in mijn importvoorstel getoonde plaatjes te recyclen als dat behulpzaam is.

En tot slot:
ik hoop heel erg dat mappers de verleiding kunnen weerstaan om in veenweidegebieden met heel veel sloten ze toch als waterways in te tekenen: beter meer moeite doen om 1 sloot als vlak in te tekenen dan 10 als waterway…

Nu begin ik de noodzaak een beetje te begrijpen.
(ik kom ook uit het oosten des lands, hier heb je inderdaad niet veel sloten waar je kunt canoën)

Als extra voorbeeld voor de discussie:
Hier is in het verleden heel hard gemapt, met als resultaat iets wat voor mij niet lekker gerenderd wordt:
https://www.openstreetmap.org/#map=13/51.9489/5.0299
Vergelijk voor de grap met 1 zoomniveau hoger:
https://www.openstreetmap.org/#map=12/51.9489/5.0299

Wat er ook uit dit overleg komt: maak de multi’s niet te groot; niet zo groot als bij de grote rivieren. Dank

Mooi voorbeeld, de verhouding water:land varieert hier tussen ca 1:2 bij z=13 tot ca 1:175 bij z=19
(met lineaal op monitor na vergroten in browser, er moet vast een betere manier zijn om pixels te tellen…)

Voel me bijna schuldig om me zo kritisch uit te laten over het mappen van sloten als waterway in zulk dichtbesloot gebied als je bedenkt hoeveel moeite hierin moet zijn gestopt…

Multimodaal,

Ik wil toch even nog een aantal kritiekpunten geven gezien op alles wat je schrijft:

• Ik proef toch wel heel sterk uit jouw bewoordingen, dat de overname van BGT en watervlakken daaruit, niet alleen wordt ingegeven door een op zich denk ik terechte wens om betere geometrie en aansluiting tussen landuses en waterways te krijgen, maar toch ook heel sterk uit een ongenoegen met de huidige rendering. Dat riekt een beetje (hoewel zijdelings) naar “digitaliseren-voor-de-renderer”. Dat is wel geen “tagging-voor-de-renderer”, want je voert geen foute data in, maar ik wil maar illustreren dat een argument als “het ziet er niet zo mooi uit”, of “de weergave laat veel teveel / te weinig water zien” een nogal zwakke is in de context van OpenStreetMap. Dat zou zeer zeker geen reden hoeven of moeten zijn, om wellicht nuttige waterway informatie te verwijderen.

• Op dat laatste punt doorgaand: Ik had nog niet goed begrepen dat je van plan was om alle waterway=x lijnelementen te verwijderen. Ik heb hier om verschillende redenen mijn bedenkingen bij:

• Hoewel procentueel waarschijnlijk maar weinig, is er toch een redelijk aantal van deze waterway=x lijnelementen die een naam draagt. Indien je niet zorgvuldig bent, en geen equivalent waterway=x polygoon aanmaakt en daarbij de naam overneemt, gaat er dus nuttige informatie verloren die door cartografen of renderers gebruikt kan worden.
• Zelfs als je rekening houd met het eerste punt, is de totale verwijdering van de lijnelementen, een potentiele achteruitgang. Je lijkt vooral te denken vanuit “het plaatje”, maar er zijn meer toepassingen denkbaar van** waterway=x lijnelementen**. Wat als iemand b.v. een router voor vaarwegen zou willen ontwikkelen? Zo gek is dat niet, er zijn plekken in NL waar je aardig kan verdwalen op de slotenbrei. Met alleen polygonen kom je er dan niet.
• Ook weet ik vanuit de waterwereld, dat er wel degelijk ook met waterway=x lijnelementen wordt gewerkt, b.v. voor modelleringen over doorstroming en zo. Eens te meer, verwijder je de lijnelementen rücksichtslos, dan is een dergelijke toepassing niet meer mogelijk.

Persoonlijk zou ik er meer voor voelen, om de bestaande lijnelementen als hartlijnen van de nu in te voeren vlakken op te nemen en netjes uit te lijnen, en daarmee te behouden.

Om het nog iets anders te stellen: Stel dat we straks alle wegvlakken uit de BGT opnemen als area:highway=x, vind je het dan ook logisch om de bestaande highway=x lijnelementen te verwijderen, en er vervolgens achter te komen dat je auto-routeplanner de route van je huis naar je werk niet meer weet te berekenen?

Zolang we voetpaden als lijnelement opnemen en trottoirs niet apart intekenen, vind ik dat boerenslootjes geen enkel nut hebben om als area getagd te worden.
Een richtwaarde van de breedte waarboven een area overwogen zou kunnen worden lijkt mij 1,5-2 m.

Importeren doen we niet omdat het kan (OSM is immers ook geen schaduwdatabase van door de overheid bijgehouden data) maar als het nuttig is of efficiënter. Daar waar reeds boerenslootjes ingetekend zijn (Midden Delfland bijvoorbeeld) zie ik vervangen door een (area)input niet als zinvol maar eerder als het (ongevraagd?) vernietigen van andermans edits.

Multimodaal, mijn grote waardering voor het werk dat je verzet, ondermeer in dit uitgebreide overleg en het reageren op vragen en opmerkingen!

Je schreef eerder:

Dus als ik je voorstel nu goed begrijp dan zouden we (als Nederlanders) bijv. waterway=sloot gaan gebruiken om poldersloten NIET op de kaart te laten weergeven, om hiermee de ongewenste renderingseffecten op hogere zoomniveaus weg te nemen en tegelijkertijd te stimuleren om poldersloten als vlakken te tekenen.

Aanpassing van de rendering van waterway=ditch is dus o.a. door Allroads al voorgesteld op GitHub en ik lees er opmerkingen van MBoeringa reeds in 2014, in lijn met wat ik schreef over geschaalde rendering. De bezwaren zijn me na vluchtig doorlezen van de topics op GitHub niet echt duidelijk of gewoon niet overtuigend. Het lijkt dan toch… alsof degenen die het zouden kunnen realiseren er geen prioriteit aan geven.
Wie gelooft er dat dit daadwerkelijk een onmogelijke taak voor renderers is?

Dat zijn naar mijn idee positieve neveneffecten van een tag die bovenal meer informatie geeft over wat voor soort watergang het is dan de huidige tag die alles vanaf de 25cm brede , geïsoleerde, greppel tot voor in veel gevallen ook primaire polderwatergangen van 10m breed die de hoofdafwatering is van een poldersysteem van vele km’s sloten + kanalen (die laatste zou ik zelf overigens als canal taggen, maar anderen mappen dat dat als ditch).

Dat beeld heb ik ook: de vroege rendering van ditches zou het zou een incentive zijn om te *voorkomen * dat kleine streams in berggebieden als ditches worden getagd omdat minder vroeg/dik rendert…
Tegelijk denk ik dat de situatie met enorme dichtheid aan sloten in veenweidegebieden zo specifiek is voor een beperkt deel van een klein land dat je daarvoor niet snel een aanpassing van de wereldwijde rendering moet verwachten, en bovendie: OSM Carto is maar een van de vele renderers…

Misschien dat andere mensen er een heel ander licht op kunnen laten schijnen, maar mijn beeld is dat een lijn zonder informatie in breedte alleen maar bij toeval op het juiste schaalniveau (land vs water) kan worden gerenderd als de feitelijke breedte van de elementen dat het tag representeert onderling met een factor 20 tot 40 in (zie bovenstaande 25cm vs 10m) kunnen verschillen.

Zie als illustratie resulaten van de globale lineaalmeting nav het voorbeeld van Nilodo:
de ratio water vs land varieert van **1:2 **bij z=13 tot ca 1:175 bij z=19

Dat terwijl de werkelijk ratio in dergelijke gebieden eerder in de ordegrootte van 1:10 zit (slootje van ca 2 meter, ca 20 meter land).
Maar ook dat varieert naar gelang de bodemsamenstelling, bodemdiepte, periode van ontginning (in grote nieuwe droogmakerijen zijn de afstanden veel groter).

Je kan van alles tweaken, maar zonder infomatie over feitelijke breedte kan je het met een lijnelement alleen bij toeval (en doorgaans ook alleen bij 1 zoomniveau) goed hebben.

En het mooie van een vlak is: daar kan je heel makkelijk een hartlijn uit destilleren en een gemiddelde breedte uit berekenen,
terwijl dat omgekeerd uit een lijn (zonder dat je daar weer kunstmatig een breedte aan gaat hangen) weer niet gaat, laat staan dat je finesses in de vorm kan weergeven.

ps. dank voor de aardige woorden het is absoluut wederzijds (-: !

Wil me aansluiten bij de opmerking dat het goed is dat Multimodaal in overleg treedt via het forum en het importvoorstel.

Of we overeenstemming over alles gaan krijgen, blijft altijd de vraag met zoiets. Ik hoop wel dat de laatste door mij genoemde punten in de voorgaande post (https://forum.openstreetmap.org/viewtopic.php?pid=687961#p687961), nog goed worden doorgelezen.

Over het tweede punt hierboven geciteerd en waarin je waarschijnlijk naar deze Github thread verwijst (waarin ik inderdaad actief ben geweest): https://github.com/gravitystorm/openstreetmap-carto/issues/967

• Het kan wel degelijk zijn dat de door mij daar geopperde schaling, niet zomaar in de door de Standaard stijl toegepaste tools te realiseren is. Het is maar net wat daarin ondersteund wordt. Het kan heel terecht zijn, dat men het nog niet 1-2-3 kan oplossen op die manier.
• Het is verder inderdaad zo, dat je in de Github geen “wensen-op-bestelling” kunt doen. Vergeet niet dat ook daar mensen hun tijd vrijwillig beschikbaar stellen! Het kan heel goed zijn, dat men liever de tijd in een ander probleem steekt. Dan kun je wel klagen, maar het is niet een betaalde service die je afneemt… beter is het om dan evt. zelf de handen uit de mouwen te steken (en dan nog erop voorbereidt te zijn dat niet altijd alles geaccepteerd wordt). Het blijft een community en consensus project…

De vraag “Wie gelooft er dat…?” helpt ons dus niet echt verder.

Voor mijn begrip:

• Je moet niet taggen voor het renderen, maar je tagging moet wel renderbaar zijn
• De voorkeur is sloten als areas in te voeren, zodat de renderaars de verhouding land/water in alle zoomniveaus bruikbaar kunnen weergeven
• Sloten intekenen als lijn is een snelle oplossing totdat ze omgezet zijn naar areas wat erg veel werk is
• Overal ditches van maken geeft het probleem dat je niet kan selekteren wat nog omgezet moet worden en wat echt een ditch moet blijven
• Taggen als sloot is vrijwel alleen in Nederland begrijpelijk en zinvol, wat nog wel uit te leggen is, maar het is niet de uiteindelijk gewenste oplossing
• Tijdelijk taggen als sloot kan wel, het wordt dan niet gerenderd en dient alleen om aan te geven dat het nog omgezet moet worden. Je moet die omzetting dan wel plannen (het is een grote maar eindige klus)

Als ik dit goed heb, dan bied ik mezelf alvast aan als deelnemer voor het omkatten van tijdelijke slootways naar definitieve slootareas. (In niet al te ingewikkelde polders, want ik ben nog steeds beginner).

Ik wil me niet in de diskussie mengen, maar als ik kan helpen in de uitvoering dan hoor ik het graag.

Een lijnelement is per definitie een schematische weergave van een element.
Water (enkel) als lijnelement betekent dan: minder belangrijke/smalle waterweg, of belangrijke/bredere waterweg die nog niet nader is gemapt.
De renderingsbreedte zou afgestemd moeten zijn op smalle waterweg.

Zo’n poldergebieden is inderdaad wel een vrij extreme situatie. Toch zou een extra smalle/minimale rendering op zoomniveau 13 wel het grote verschil kunnen maken.

Ander idee: je zou zo’n compleet poldergebied als polder moeten kunnen aangeven, vergelijkbaar met het bestaande natural=wetland. Daarbij zou het dan zo moeten werken: uitgezoomd zie je de kleur en het patroon dat de polder aangeeft, ingezoomd zie je de losse poldersloten.

Zuidelijk van Lexmond zijn allemaal drains. De drains worden gerenderd op zoomniveau 13 t/m 19 en altijd op dezelfde dikte.
Dat is dus een ding van de renderer. Misschien moet de discussie dáár gevoerd worden.

@mboeringa
Bedankt voor je nuancering wat betreft GitHub. Ik heb ‘ze’ in een eerder topic zelf verdedigd en toen het punt gemaakt dat het aan jezelf is om stug en constructief door te lobby’en wanneer je iets gedaan wilt krijgen. Ja, als technische buitenstaander heb je geen overzicht in alle mogelijkheden en struikelblokken.
Ik bedoelde met o.a. die (retorische) vraag slechts blijk te geven van mijn inschatting dat het meer om een gebrek aan prioriteit gaat dan technische onmogelijkheid.

Ik ben met je eens dat het verwijderen van alle waterway-lijnelementen geen goed idee is. Buiten poldergebieden zijn ze toch al minder dominant aanwezig als ze al zijn gemapt, omdat ze meer verspreid liggen. Het naast elkaar bestaan van sloten als vlakken en sloten als lijnen zie ik niet als ongewenst. Verschil in detaillering zal er altijd wel bestaan binnen OSM.
Ik had overigens niet de indruk dat verwijdering onderdeel van het plan was van Multimodaal maar gewoon een extra ingebracht idee met duidelijk de verwachting weinig bijval te krijgen.

Sloten niet smaller tekenen als ze in werkelijkheid zijn, en daarbij een standaardbreedte van bv 1m aannemen is iets wat de renderer kan oplossen. Onderscheid maken tussen een 2 m brede hoofdwatergang en de 2 m brede poldersloten waar multimodaal het over heeft niet.
Dan zul je toch echt een (functionele) classificatie moeten verzinnen. Bijvoorbeeld met 3 niveaus:

local:
ontvang alleen water vanuit het direct ernaast gelegen land staat droog als het een tijd niet geregend heeft tenzij de sloot in directe verbinding staat met hoger geclassificeerde sloten (of meren bergvijver en dergelijke) en er geen sprake is van verval (gebuffered) meestal onderhoud door de landeigenaar naar eigeninzicht.

collector:
tussenvorm verzamelt water uit verschillende sloten, maar ook nog redelijk wat uit de directe omgeving. Redelijk systematisch onderhoud, water uit meerdere percelen mond uit in waterway=stream of main-ditch

main:
hoofdafvoer, grote afstanden onderhoud door een overheid of strek gereglementeerd omdat er een groot aantal landeigenaren van afhankelijk is. betrokken is, komt alleen voor ter ontlasting van een bestaande beek of in droogleggingsgebieden mond uit in een waterway=river of waterway=canal, eventueel via een gemaal (een andere main-ditch mag natuurlijk ook)

of dit met ditch=local ditch=collector etc. of waterway=local-ditch zou moeten weet ik niet. Een vergelijkbare classificatie zou je dan ook voor de kleine beken (waterway=stream grote beken kun je niet meer overheen springen) moeten gebruiken een beetje consistentie kan geen kwaad zeker in vergelijking net als met de overgang stream/river ditch/canal is het ene nu springen en de andere (mogelijk illegale) bevaarbaarheid met een kano?

rabbattenbos is overigens een nog extremer voorbeeld van een hoge dichtheid met alleen lokaal relevante slootjes niet mappen om de renderer is ook zo wat, je kunt beter op de een of andere manier aangeven dat het alleen lokaal relevant is.

voor de karakterisering van de expliciet gemapte poldersloten is misschien water=buffered-ditch een ideetje, als sloot al een betekenis heeft in het engels is dat eerder een sloot zoals je ze in zuidafrika ziet dan een nederlandse poldersloot.

Naar mijn idee goed samengevat, maar ik geloof dat er ook veel mensen anders over denken.
Dank voor hulp bij uitvoering. Lijkt me goed voor het moment dat procedure mbt bgt-data iets mer is uitgekristalliseerd
(zal binnenkort aankondigen dat ik eerste proefpolder doe, daarna even wachten op reacties en dan -hopelijk- verder).

Wat misschien interessant is:
het Bentwoud (directe ten noorden van wandelnetwerk Zuidplas) is nu nog quick-and-dirty aangepast aan de herinrichting van wie-/akkerland naar park / natuurgebied. Op het eerste gezicht ziet het er aardig uit in OSM standard-carto omdat park zorgt voor zo’n handig groen transparant dekentje, maar eigenlijk moet er nog veel gebeuren.

Was daar met goede moed aan begonnen, maar -zoals veel mensen die met landuse aan de gang zijn gegaan- vastgelopen in de eindeloze hoeveelheid onwerkbare data uit eerdere import plus wat daar later overheen is gekomen.

Nu ligt dit gebied in een veel grotere polder (Polder Noordplas), waarvan ik eigenlijk nu al vrij zeker ben dat die te groot is (ook icm aantal niet-grass-landusevlakken- voor mijn “een multipolygoon-per-polder-aanpak”. Opslitsen in 2 of meer middelgrote -wel hanteerbare- multi’s gaat helaas niet omdat de watergangenb dan de outers van de deelpolys kruisen en dat mag niet.

Hier is dus een andere aanpak nodig en daar begint wel een beeld op te borrelen van een methode die denk ik voor jou ook aardig kan zijn in een gebied dat wellicht ook nog in je “aandachtszone” ligt.

En over dat “niet taggen voor de renderer”:
dat wordt naar mijn idee vaak te makkelijk en kort door de bocht gezegd.
We taggen namelijk juist WEL voor de renderer: het maken van kaarten is het eerste en naar mijn idee nog steeds belangrijkste doel van de database die we met z’n allen bij houden; het project heet niet voor niets openstreetMAP en niet openstreetDATABASE.
Maar het is natuurlijk wel zo dat
(a) er ook andere belangrijke toepassingen zijn zoals routeren en data-analyse
(b) hoewel de OSM standard carto wel de voornaamste kaart is, maken we uit deze database niet één kaart, maar vele
(c) het een decentraal project is met vele betrokkenen en eindproducten

Dat maakt de ruimte voor al te opportunistisch gebruik om een specifiek doel te bereiken een stuk kleiner dan als je zelf alleen verantwoordelijk bent voor een enkel product.
Wat je in ieder geval zeker niet moet doen is incorrecte data invoeren omdat dat zo leuk rendert.
(tijd terug een Amerikaan die -als ik het goed herinner- het strand van een van onze waddeneilanden had omgezet naar een andere landuse omdat hij daar een bruine kleur op de kaar nodig had…- )

Maar het is zeker goed om rekening te houden of datagebruikers wel chocola kunnen maken van hetgeen je ze voorschotelt, en als je een wijziging maakt die op zich correct is, maar wel de complete rendering van het meest gebruikte OSM-product ernstig in de war schopt, dan is het wel de moeite waard om te bedenken of er een alternatief is dat ook correct is (misschien wat ongebruikerlijker) en dat niet die schade veroorzaakt.

Een tijdje terug maakte ik een naar mijn conclusie inhoudelijk goede en technisch geldige mulitpolygoon aan waardoor het merendeel van de Kagerplassen droog kwam te staan. Vanwege de schade in de meest gebruikte renderer heb ik dat toch maar teruggedraaid en een alternatief gezocht dat ook correct was en niet die schade veroorzaakte. Duidelijk geval van tagging for the renderer (van het goede soort wat mij betreft) leek me beter dan hopen dat iemand een technische oplossing ging verzinnen oor het probleem dat ik de renderer heb aangedaan.

Ik vind dit eigenlijk giswerk van het verkeerde soort en ook niet echt een argument, maar omdat een importvoorstel toch wel een bepaalde verplichting oproept tot serieuze reacties en ik je posts normaal toch wel erg waardeer, ga ik er toch maar op in:

Het gaat mij er niet om dat de kleur blauw van het water in de standard carto me niet aanstaat, dat bepaalde items op zich te vroeg laat worden gerenderd oid, maar -zoals verwoord in mijn importvoorstel- dat de hele verdeling land/water in polders OSM nu verre van correct is. En dan is die rendering van lijntjes vs vlakken nog maar een heel klein deel (waar nu steeds de focus op ligt), voor het grootste deel is er gewoon echt nauwelijks polderwater gemapt, ook niet met lijntjes. En daarnaast een enorme landuse-opeenhoping waardoor vele mensen net als ik zijn vastgelopen in pogingen tot verbetering.

En ik weet niet of ik echt moet gaan uitleggen waarom ik denk dat mappen van water in Nederland relevant is, of dat dat het onderscheid land of water toch best een essentieel onderscheid is voordat je überhaupt over landuse etc gaat beginnen.

Maar als je me vraagt of ik er naast al die abstracte punten blij van wordt als dat resulteert in een mooie kaart, dan kan ik niet anders antwoorden dan JA: mooi omdat ie de werkelijkheid zo goed mogelijk benadert binnen de context van de abstractie die een kaart is en ook nog eens hapklaar esthetisch aansprekend gepresenteerd, dankzij de goede mensen die hard werken aan de standard carto. Wil je me dat nou echt voor de voeten werpen, of is dat niet gewoon een van de dingen die ons als mappers mede motiveert om zoveel tijd te besteden aan het eindeloos klikken en slepen van puntjes op een beeldscherm?

Volgens mij is hier nog steeds een misverstand, in mijn importvoorstel staat -vanaf het begin al- zeker niet dat ik alle watergangen verwijder:

https://wiki.openstreetmap.org/wiki/Basisregistratie_Grootschalige_Topografie/Rijnland_polder_water_import#Data_Reduction_.26_Simplification

Het *vervangen * van een lijn (die verder niets anders dan alleen het water representeert) door een vlak in plaats van het laten bestaan van die lijn als duplicaat-element in OSM naast (in…) het vlak voor dezelfde feature volgt uit toepassing van het good practice principle van “One feature, one OSM element”

https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

En als je naar mijn eerdere werk kijkt, dan kan je juist zien dat ik bijzonder veel namen aan watergangen (en nieuwe waterway=* elementen binnen polygonen) heb toegevoegd aan OSM ipv verwijderd, puttend uit vele bronnen, juist vanwege het nut van de kenbaarheid van deze namen dat ik onderschrijf en nastreef.

Weer die aanname over hoe ik lijk te denken
Het is zeker niet gek om een router router voor vaarwegen te willen maken, niet geheel toevallig ben ik daar onder andere mee bezig en heeft het op orde krijgen van waterdata daarom ook mijn bijzondere aandacht.

Mocht je dat niet voetstoots willen aannemen, kijk dan voor de grap eens waar en door wie in Nederland (nieuwe waterway-LIJNEN met) canoe=* is toegevoegd (hoeveel mensen hebben canoe=portage getagd voor specifieke overdragen tussen boezem en polder…?): http://overpass-turbo.eu/s/wJQ

(in deze query geen aaneensluitend netwerk, want ik heb daarin boat=yes buiten beschouwing gelaten, en dan hoeft canoe niet: is needless want valt onder *de definitie van * boat )

Overigens werd me onalangs hier juist het tegenovergestelde verweten: dat ik (met het oog op routeerbaarheid een waterway=canal had gelegd in een meer, terwijl dat geen kanaal zou zijn - het is niet snel goed…)

En de naam van deze Mapillary-account speciaal voor vaarwegen is ook geen toeval
https://www.mapillary.com/app/?lat=52.15333333333331&lng=4.394741666666732&z=17&pKey=2F42Mu1bQ5BniquunJvKiw&focus=photo

En hoewel ik natuurlijk niet kan verwachten dat je mijn werk kent, was ook die de aandacht voor bevaarbaarheid gewoon te lezen in het importvoorstel:

En ik kan hier wel een hele verhandeling houden om te onderbouwen dat uit zowel mijn ruime veldexpertise met varen in de kleinste poldersloten (mensen vragen vaak bezorgd “hoeveel overdragingen zitten er in de tocht” als ik een kanotocht organiseer) als uitgebreide analyse van leggerdata volgt dat primaire polderwatergangen (waterway/water=canal) met wat goede wil nog wel te kanoën is en op secundaire (waterway/water=ditch) niet, zeer hoge uitzonderingen daargelaten.

Die ditches hebben echt geen praktische functie voor vaarmogelijkheden. Mischien wil je dat van me aannemen, maar leuker is als je zondag langs wil en kan komen bij de Kaag, dan kan je het zelf ervaren.

Nu ga ik stoppen, op de overige punten zal ik nog wel reageren (vooral de laatste vraag vond ik interessant)

Mooie aanzet.
Ik heb er zelf na deze discussie hier even de puf niet meer voor, als je merkt hoeveel kritiek (en weinig verbetervoorstellen) een voorstel voor een simpele tussenvariant oproept, maar denk wellicht later graag met je mee.

Na uitvoerige vergelijking van OSM (waar polderwaterdata doorgaans niet, en zo wel dan grof en soms als vlak en soms als lijn is gerepresenteerd, zou ik gebruik van OSM-data voor dat specifieke gebruik ten stelligste afraden. Het zou eventueel -hoewel toch best ver buiten het reguliere toepassingsbereik van OSM- nog wel kunnen na realisatie van de door mij voorgestelde import. Dan is het water *wel *compleet en consistent gemapt en kan je -zo ik begreep van een GIS-prof die me heeft geholpen- uit de vlakken makkelijk een hartlijn genereren. Maar nog steeds is mijn beeld: voor dat specifieke gebruik kan je veel beter een primaire bron (legger / bgt) gebruiken.

Dat lijkt me een grote schending van het one-element one feature principe (want die lijnen representeren niets anders dan het watervlak, een beetje hetzelfde als voor elke landuse area ook nog een node toevoegen met dezelfde info.

Zoals gezegd zijn bestaande lijnen in polders zijn nagenoeg nooit een bevaarbare primaire watergang (dat zijn regelmatig al wel vlakken, evt met een lijn erin, die kan dan wel blijven), maar ditches die -op sommige plekken- als lapmiddel als lijn zijn aangetakt po het bestaande vlak omdat iemand geen zin had om de landuse ellende echt op te ruimen.

(ik heb ook voor dat dilemma gestaan: erg makkelijk om lijntje te trekken over grens landuse vlakken, maar werd me hier (terecht) afgeraden omdat de boel nog onbewerkbaarder maakt). Beeld zou bovendien erg inconsistent worden: verzameling lijntjes in klein deel van sloten als herinnering dat er ooit een lapmiddel is gebruikt (de meeste sloten zijn nu immers helemaal niet gemapt, ook niet met een lijntje).

Als je echt graag hartlijnen uit OSM wil voor niet bevaarbare watervlakken zonder naam, dan kan je die zelf destilleren en lokaal gebruiken.

Leuke vraag, maar denk dat je het antwoord ondertussen wel kan raden:
NEE, want ik stel alleen voor om lijnen te verwijderen die *geen * praktisch routeerbaar netwerk vormen (en ik leg de grens echt heel laag: kanoër die het niet erg vind om vaak in de boot te duiken of over te dragen voor lage brug).

Mag ik een omgekeerde vraag stellen:
ben jij ervoor om binnen elk bestaand watervlak (ook als het niet bevaarbaar is en geen naam heeft) ook nog eens een waterway=ditch-lijn extra in te gaan tekenen?

Greppel is intermittent ditch, want een greppel staat meestal droog.