@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:
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”
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 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?
Ik doe dat wel, om helder te krijgen hoe het water naar zee stroomt. Ik ga ter plekke kijken hoe alles op mekaar aangesloten zit en naar welke kant het stroomt.
Dat is inderdaad een schending van one feature, one element, maar bij rivieren doen we dat toch ook.
Dit lijkt me inderdaad een prima werkwijze voor stromend water, want daar verteld die lijn iets over een stroomrichting, vertakkingen en uieindelijk zelfs samenhangende stroombekkens en waterscheidingen. Zie deze prachtige kaart obv waterways=*:Flussgebiete Mitteleuropas
Ik zou het voor stromend water niet in mijn bolle hoofd halen om waterway=* te verwijderen (past ook niet in beeld van wiki, die ook let stromingsrichting en routeerbaar netwerk) , maar in de polder juist wel, want:
Een sloot in een veenweidepolder (als onderdeel van een boezem) waar het veen tot aan het grondwater is weggegraven in het verleden is op zoveel manieren een ander ding dan een stromende beek in hoger gelegen land (en zie cijfers clo in bovenstaand draadje: we hebben 50x zoveel km sloten als kleine beken) en verdienen een passende aanpak.
Ik nam aan -omdat mijn specifieke voorstel echt over poldersloten gaan- dat duidelijk was dat het hier niet over stromend water gaat, maar misschien had ik dat nog explicieter moeten maken. (en het gaat ook niet over het bijzondere soort sloten waar Allroads op wees, die eerst naar beneden gaan door natuurlijk verval icm hulpstukken en daarna pas omhoog, naar een boezem (oid): dat is een nuance die voor mij nieuw was, maar die in je mijn importgebied niet ziet voor zover ik weet.
Voor de polder is dat stroomverhaal (a) niet van toepassing en (b) niet goed te modelleren want soms weet je niet waar er wel/geen duiker zit (zelfs waterschappen met extreem goede leggers geven aan dat die data niet altijd compleet is en een sloot tussen twee “dijkjes”: zie biijv plaatje secundaire poldersloot op https://forum.openstreetmap.org/viewtopic.php?pid=687678#p687678 kan aantakken op de hoofdwatergang via een duiker in dijkje A, in dijkje duiker of via beide.
Maar via de vlakken is de vraag wel/geen verbinding onder de duiker (die voor ons normale gebruik in OSM net zo relevant is, is meer iets voor de eigenaar/het waterschap en die hebben hun eigen kaarten/kennis) niet relevant, want daar worden -met de werkwijze die ook in mijn voorstel zit- juist zijn alle watervlakken met elkaar in een logische relatie gebracht via de multipolygoon, inclusief een outer die de omtrek van de polder (de dijk) weergeeft.
Dus wat mij betreft:
-stromend water: vooral mappen als waterway, ook als daar een vlak bij is getekend (zowel lijn als vlak herbergen eigen informatie)
uitdrukking brengen)
-niet stromend water : voor “landcover” lijn kan, vlak is beter. Lijn in vlak is (alleen) zinvol indien het daadwerkelijk aanvullende informatie herbergt: een routeerbaar netwerk, informatie over toegankelijkheid, of van mijn part een betere drager voor de naamvlak
Voor mijn voorstel wil ik bij nader inzien de natural-water vlakken die de tag water=canal hebben eigenlijk allemaal voorzien van een waterway=canal (itt de ditches om uitgebried toegelichte redenen), want:
De tag canal op het watervlak is correct, want primaire polderwatergangen zijn -itt de secundaire- the largest waterways created for irrigation purposes
Tegelijk doet de duale definitie van canal ook een vermoeden van bevaarbaarheid opdoemen bij gebruikers. Voor motorboten zijn de primaire poldersloten echter -anders dan velen zullen verwachten- praktisch niet bevaarbaar, want een poldersloot is per definitie afgesloten van het omliggende watersysteem (ik ken zelf de uitzonderingen in mijn gebied waar de polder met een sluis wel bevaarbaar is, de situatie van iemand aan een poldersloot met een motorboot in de achtertuin wil ik niet maatgevend laten zijn, dat is een beetje als het garagepad: die heeft daar OSM niet voor nodig).
Voor canoe kan in eerste instantie leeg blijven en nader worden ingevuld na verder onderzoek (problemen zullen eerder praktisch zijn dan juridisch).
-algemene oproep- (niet vanwege bericht Kogacarlo, dat is nuttige constatering)
doe me alsjeblief een lol en ga niet zitten kijken of je misschien zo slim bent of je een kritiekpuntje kan bedenken op alles wat hierboven staat, want dat is er vast en dat kan ik zelf ook best. Vraag je vooral af: wordt de kaart met uitvoering van dit voorstel per saldo beter (ook als je het zelf misschien net een slagje anders zou doen). Bedenk je hoe de situatie nu is (zie importvoorstel), hoeveel moeite ik doe om dit te verbeteren en om al het commentaar goed te verwerken / beantwoorden (ook als het soms wel met -in het algemeen- kennis van zaken maar toch na slechts vluchtige blik op het voorstel geschreven lijkt). En mocht je een briljante ingeving hebben waardoor alles makkelijker en nog beter wordt, dan hoor het graag…
Ondertussen ben ik wel op het punt dat ik aan de slag wil gaan met het verbeteren van de kaart in plaats van oeverloos (eerst import van samplebestand uit importvoorstel, dan korte pauze om te kijken of daar nog echt belangrijke wijzigingen uit komen)
@multimodaal
Het lijkt me inderdaad zaak dat je aan de slag gaat met de uitvoering van die import, waartegen volgens mij geen belangwekkende bezwaren openstaan. Het verloop van die import zou verbeterde inzichten kunnen geven in de specifieke kwestie waar dit topic over gaat: mogelijke invoering van de tag water=sloot.
Stel dat die import erg soepel verloopt… dan wordt de noodzaak van een extra tag wellicht een stuk minder, omdat andere poldergebieden in Nederland ook goed en binnen redelijk afzienbare tijd aangepakt kunnen worden.
Ik heb geen reactie gelezen op mijn idee om het renderingsprobleem op te lossen en ben wel benieuwd wat daar de bezwaren tegen zouden zijn:
Ik wil eraan toevoegen: de polders die ik ken en waar een vriendelijke ziel alle water als vlakken gemapt heeft, tonen op alle kaarten en in alle zoomniveaus veel mooier dan de polders waar niets is of alleen een paar lijntjes. Wat mij betreft is importeren dus een grote aanwinst voor mijn omgeving (Nieuwerkerk aan de IJssel, een en al polder met daarin het diepste punt van Nederland). Hoe eerder het lukt hoe beter!
Of er dan ook nog waterwegen inzitten: waar het nodig is, prima.
Nabewerking, doe ik graag aan mee (moet ik even gebrieft worden).
Doe anders ff 1 polder waar nou niks is, dat kan geen kwaad en dan kunnen we het goed beoordelen. Weghalen als het niks is is dan niet heel veel werk toch?
Dank voor reactie en hulpaanbod, daar kom ik later graag op terug.
Dat was precies het idee van de sample-file die bij het importvoorstel is gevoegd (Meerpolder, daar is heel veel water, maar nog nauwelijks gemapt, zie ook de plaatjes bij het voorstel).
Rond aanstaande woensdag (2 weken na publicatie importvoorstel) zal ik die importen en dan een weekje wachten met vervolg (daarna kan ik met de nodige hulp de verdere data prepareren en aanpassen aan binnengekomen reacties mochten daar, ondanks alle informatie vooraf bij het voorstel, toch echt hele dringende zaken tussen zitten)
