Ik ben het eens met de redeneringen van MBoeringa. De omschrijving van ‘drain’ maakt dat het in Nederland weinig toepasbaar is. Bij de term ‘greppel’ denk ik aan een vrij smalle en ondiepe rechte uitgraving die meestal droog staat. De term ‘sloot’ wordt in Nederland letterlijk breed gebruikt: van een halve meter tot enkele meters en van bijna droog en schijnbaar functieloos tot altijd flink gevuld met duidelijke lokale afwateringsfunctie.
Als je in Nederland tegen iemand zegt: “ik ben gisteren een sloot in gefietst”, dan kan dat hele diverse beelden oproepen en waarschijnlijk vragen als: stond er (veel) water in? Was het een diepe sloot? (waarmee waterdiepte en mogelijk ook breedte wordt bedoeld).
Groter dan een sloot is een kanaal of vaart, waarbij voor mij kanaal breder klinkt en recenter aangelegd dan vaart. Wateren die eeuwen geleden zijn gegraven heten in mijn beleving veel vaker ‘vaart’ en wateren die in modernere geschiedenis zijn gegraven ‘kanaal’.
Ik heb niet het idee dat er in het Nederlands een term mist ten opzichte van het Engels. Als er een term mist dan komt door de Nederlanders zelf, namelijk door de populariteit van het woord ‘sloot’.
Het gaat bij OSM niet alleen om termen maar ook, en soms juist, om classificatie.
Nederland waterland… is de rol van water hier zo anders dat er een extra waterway value nodig is?
Ik vrees dat het toevoegen van bijv. ‘sloot’ een ander probleem creëert, namelijk onduidelijkheid bij mappers wanneer ‘ditch’ en wanneer ‘sloot’ te gebruiken.
Toevoeging van breedte kan ook lastig zijn, want die zal je vaak moeten schatten… maar bij beslissen tussen ‘ditch’ en ‘sloot’ zou je ook de breedte in overweging moeten nemen.
De hoofdreden om een extra waterway value voor te stellen komt toch voort uit de rendering. Om die nieuwe value te laten renderen zul je via GitHub moeten lobbyen. Je kan als alternatief, of in combinatie, een voorstel indienen voor geschaalde rendering van het lijnelement ‘ditch’, waarbij optioneel width=* een rol speelt.
En ja, om het zelf in de hand te houden kun je het beste water zoveel mogelijk als vlakken mappen. Dat is echter geen oplossing om binnen redelijke termijn heel Nederland op orde te krijgen.
Ondanks vele verschil in beeld (waar de grenzen liggen, welke voorbeelden binnen welke Nederlandse term passen en hoe dat dan weer past binnen bepaalde osm-tags) is het denk ik wel goed om te constateren de globale indeling die de dikke van Dale schetst wel gedeeld wordt:
(waarbij Andries natuurlijk helemaal gelijk heeft met de constatering dat sloot in het dagelijks taalgebruik wel breed / wisselend wordt gehanteerd. Maar nogmaals: als iemand een betere term heeft : graag!
Maar ook voor elk alternatief zal gelden: er zijn altijd rafelrandjes/uitzonderingen (anders krijg je oneindig veel values/keys), het is soms wat proppen/schuiven, maat daar valt ook altijd wel weer een weg in te vinden door (a) je definitie enger of breder af te bakenen of (b) een goede toelichting (en niet voor niets staat er in de OSM wiki’s vaak “typically…” / “mostly…”
Helemaal eens, naar mijn idee is het net omgekeerd, in het engels (ook buiten OSM) wordt greppel en sloot al snel op een hoop gegooid onder “ditch”. (vergelijk het met talen in de poolstreek die veel meer onderscheidende woorden voor sneeuw kennen dan wij)
Naar mijn idee is het net omgekeerd: daar waar sloot en greppel in het NL-woordenboek van van Dale als twee “uitsluitende categoriën” worden gepresenteerd (bijna dan, er is idd overlap…), zet dezelfde woordenboekmaker deze naast elkaar bij het Engelse ditch
En hoewel ik eigenlijk een beetje uit dit taalspel wil raken (een betere term kan altijd nog…), zit hier volgens mij wel een relatie met de situatie in het Nederlandse polderveld* en vervolgens de OSM-praktijk.
*meer specifiek: de veenweidepolders, want Allroads wijst er terecht op dat polders er ook weer in verschillende soorten zijn).
Dat punt zal ik in mijn volgende post illustreren.
(even aan de hand van quotes, dat geeft wel een handige ordening, maar het raakt tegelijk bredere vragen dan de betreffende quotes zelf)
Ik denk het wel:
dat lijkt me -ook los van de NL-situatie- nuttig, want 1 categorie voor alle lijnelementen tussen de ca 25cm en 5m (factor 20 verschil) is toch wel heel weinig, ook als je -even los van alle mooie waterschapsoverwegingen- alleen al bedenkt wat het betekent als je zo’n ding onderweg te voet tegenkomt:
-over greppels tot -zeg- de 75cm *waterbreedte * (taludbreedte kan groter zijn) die Marco noemt krijg ik mijn partner ook nog wel heen met een forse stap: je kan samen je weg vervolgen (en met de fiets til ik ze er allebei overheen )
-bij greppels/sloten (bij gebrek aan gekozen/arbitraire grenswaarde) tot zeg 1,5m *waterbreedte *wordt het toch eerder iets van een sprongetje, in mijn praktijk (samen zijn we denk ik redelijk representatief) : partner aan de ene kant met ongelukkige blik, ik aan de andere kant met een ongeduldige…
-bij sloten vanaf -zeg- 1,5 meter tot 5 meter: wordt het toch echt (soms heel ver) omlopen, tenzij je aan het fierljeppen bent of Carl Lewis heet
Laat ik vooropstellen: het lijkt me mooi als, zoals Marco voorstelt, als er een helder onderscheid komt tussen de eerste en tweede categorie (afhankelijk van de breedte van je schep 1 tot 3 spades breed) -die je altijd wel overkomt en de tweede, die veel vaker een barriere vormt. Dat zou denk ik wel een heel brede analyse van ditches vergen over de hele wereld.
Mijn beeld is dat sloten tussen de 1,5 en 5 meter zeker niet uniek zijn in de wereld, maar dat het zeer hoge aantal, aandeel en dichtheid daarvan in veenweidepolders wel uitzonderlijk is. Er lijken me -naast breedte namelijk ook rol in watersysteem- genoeg aangrijpingspunten om daarvoor een specifieke tag te introduceren die dan ook alleen in polders wordt gebruikt, en dat die *als lijnelement *niet zal worden gerenderd wordt, zie ik juist als een voordeel: geen kaartvervuiling meer en zet aan tot het als vlakken mappen ipv blijven toevoegen van sloten als lijnelementen. Het zijn immers vlakken en geen lijnen en het is geen fout van specifiek OSM standard carto dat ze hier niet goed mee omgaan, maar geen enkele renderer zal deze lijnelementen -zeer dicht op elkaar- in een goede land/waterverhouding kunnen mappen op verschillende zoomniveau’s. Zie de voorbeeldplaatjes in mijn importvoorstel
Oppervlakte / lengte verschillende soorten wateren:
(roept wel de vraag op of je de obv de opgegeven lengte vs oppervlakte kan concluderen dat grote rivieren gemiddeld bijna een halve kilometer breed zouden zijn (650/330) - lijkt onwaarschijnlijk- , of kan je dat zo niet naast elkaar zetten ? )
Aandeel sloten (doorgaans stilstaand) in landoppervlak :
Hoewel ik niet exact weet waar precies de grens is getrokken (lijkt onwaarschijnlijk dat hierin de allerkleinste “greppels” zijn meegenomen, omdat die lang niet altijd in beeld zijn gebracht) is het globale beeld hieruit:
-We hebben ca 2x meer lengte aan sloten dan aan wegen (en hoewel OSM natuurlijk primair op streets is gericht, is het enorme verschil met het aantal values voor highway= toch opvallend)
-500x meer sloten dan rivieren ; 50x meer sloten dan beken en ook 50x meer dan kanalen
Als je dichtheid en grondoppervlakte vergelijkt met bijvoorbeeld de drainage_channels op de foto’s van Marco (ik herken ze ook vanuit veengebieden zoals Dartmoor/Exmoor), dan valt op dat die channels en stuk verder uit elkaar liggen en een nog veel kleiner deel van de gebiedsoppervlakte uitmaken dan onze sloten.
Zo’n verschil in dichtheid zie je ook als je de dichtheid van sloten vergelijkt met de dichtheid van de kleinste stromende wateren (streams, hier inclusief rivers) in een gebied met de hoogste gemapte intensiteit op https://www.kompf.de/gps/rivermap.html. Zelfde schaal, gebiedsgrootte :
Focus niet teveel op alleen het westen.
Mensen hebben vaak het verkeerde beeld dat het oosten des lands droog is, maar dat is het niet. Grootste deel van het oosten is van oorsprong nat tot zeer nat. Het wemelt hier van de greppels, slootjes, watergangen, etc.
Kijk ook maar eens hoeveel wegnamen hier in het oosten op dijk eindigen en hoeveel er flier, mars, goor, leeg of laag in de naam hebben en kijk ook eens naar het aantal haren in wegnamen. Een haar is een zandopduiking in een nat gebied.
Een van de oudste polders van Nederland is nog steeds de polder Mastenbroek, waar je bewondering kunt kijken wat Middeleeuwse landmeters al konden.
En een ander waterbouwkundig staaltje uit de Middeleeuwen zijn de gebieden langs de IJssel zowel oost als west, waar men de afwatering van west naaroost resp. oost naarwest heeft omgebouwd naar zuid naar noord. Na het bedijken van de IJssel waterde het land niet meer af en gemalen kende men nog niet. Men heeft toen met gebruik maken van bestaande veenriviertjes de weteringen gegraven van zuid naar noord.
Andere indicatie voor nat gebied zijn de plaatsnamen met veen of veld erin. Zutphen betekent niets anders dan Zuidveen.
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:
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…)
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…
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…
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 (-: !
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.
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.
)
