Importvoorstel BGT- polderwater Rijnland

Zoals aangekondigd onder andere in dit draadje heb ik een BGT-import voorstel gemaakt specifiek voor polderwater in Rijnland.

Het gaat nadrukkelijk alleen om water *binnen * polders: de kleine poldersloten waar je normaal niet met je boot kan komen, maar die wel een belangrijk deel van het landschap in Rijnland vormen (dat nu doorgaans zeer beperkt is gemapt en met heel veel landuse-overlap, waardoor verbetering zonder hanteren van multipolygonen praktisch nauwelijks mogelijk is, zie https://forum.openstreetmap.org/viewtopic.php?pid=616814#p616814)).

Het gaat dus niet om het -doorgaans behoorlijk goed gemapte- *boezemwater *(de meren, doorgaande vaarten buiten de polderdijken die met elkaar in verbinding staan)

Het voorstel is, conform de import-richtlijen te vinden op deze aparte WIKIPAGINA en ook opgenomen in de importcatalogus.

De reden dat ik door deze hele molen ga is dat de te importeren data al snel over de genoemde grens voor “Large scale import” van “more than a few hundred nodes” gaat zoals benoemd in de importcatalogus.

Tegelijkertijd hoop ik erg dat de verhouding discussie / verbeteren van de kaart nog wel in het redelijke blijft (en het vooral geen discussie *om de discussie * wordt, aangezien zowel het gebruik van de bron als de gebruikte methode van data-integratie (multipolygoon per polder als oplossing voor overlappende landuse-ellende) al wordt gebruikt en hier is besproken.

Maar goede opbouwende tips die het proces kunnen verbeteren zijn natuurlijk van harte welkom, dank alvast daarvoor!


edit: inhoudelijke toelichting uitgebreid

Goed dat je er werk van maakt. Ik heb het doorgelezen en het lijkt me een prima uitgewerkt plan!

Ik applaudisseer voor het feit dat je een echt importvoorstel doet. Dit is natuurlijk altijd een struikelblok, omdat mensen nu eenmaal niet van administratie houden, maar liefst meteen aan de gang gaan…

Een paar zaakjes die mij opvielen:

  • Klopt het, dat je het inderdaad bij de genoemde tags gaat houden? Je hebt het goed beperkt dan, dus dan OK. :slight_smile:
  • Ik heb wel enige twijfels bij het feit dat je hoogstwaarschijnlijk zeer grote MPs gaat genereren. Weet je zeker dat dit te managen is, en je ook niet over de node limieten voor individuele ways heengaat met die BGT en het dissolven? Ik kan mij heel goed voorstellen dat het toch handig kan zijn om verschillende stukken te hebben in sommige situaties, maar misschien dat dat ook wel op een natuurlijke manier ontstaat door de situatie? Kan het zo even niet overzien…
  • Gerelateerd aan het bovenstaande, schrijf je ook dat je het aantal nodes/vertices reduceert. Misschien moet je toch iets beter aangeven hoe je dit doet? Watvoor generalisatie gebruik je, met welke toleranties? En generalisatie is niet altijd makkelijk, je moet uitkijken dat je geen nieuwe topologische fouten genereert. Hoe garandeer je de kwaliteit?

Mvg,

Marco

Dank voor jullie reacties.
Ik zal eea toevoegen aan de wiki en daarna hier verder inhoudelijk reageren.

@Marco
mocht je dit in de tussentijd lezen:
ik ben benieuwd of je toen je de twijfels uitte ook het voorbeeldbestand al had gezien waarnaar in de Wiki wordt verwezen onder OSM Data Files: http://www.openkaart.net/Meerpolder_DISSOLVED.osm

Het is namelijk zeer terecht dat je dit onderwerp ter sprake brengt, en ik ben daar ook al flink mee aan het stoeien geweest, precies om de redenen die je noemt. Zelf denk ik dat we een goede balans hebben gevonden in de werkwijze zoals geïllustreerd in het voorbeeldbestand.

Om een mogelijk misverstand uit de wereld te helpen: het voorstel is niet om alle aangrenzende water-areas samen te voegen (“dissolve”, maar om steeds de primaire watergangen (zeg maar de stam waar alle doodlopende takjes op aansluiten) apart te houden van de secundaire watergangen (de doodlopende takjes).

Alles samenvoegen tot één waterarea geeft inderdaad problemen.
En ook te grote polders zullen met deze methode niet werken (Haarlemmermeer is zeker te groot, ook door veel andere landuses dan grass, een paar andere grote lukken misschien ook niet, wil gaande het proces kijken wat nog wel/niet haalbaar is)

Deze manier van gedeeltelijke resolve beperkt zowel de complexiteit en grootte van de losse water elementen (gaat bij lange na niet over de node-grens heen) als het aantal elementen/leden in de multipolygoon (een factor 3 kleiner dan zonder dissolve, en nu met complete dekking van water per saldo (water+grass) dan in de huidige situatie met allemaal losse grass areas ipv water, waarbij -in de voorbeeldpolder- 90% van de sloten ontbreekt.

Ondanks toevoegen van al het missende water is -icm de gekozen vermindereing van vertices, kom ik zo op terug- de totale dataomvang een factor 1,5 lager dan de huidige OSM-data met alle missende sloten en het al bestaande water is vele malen preciezer ingetekend dan in de huidige OSM-data, ondanks vermindering van vertices tov BGT (die wel heel veel nodes gebruikt, zowel op rechte stukken als in bochten).

Maar op dit punt kan je denk ik wel gerust zijn: de reden dat ik al deze moeite neem is dat ik graag mooie waterdata in OSM zie, zal generaliseren zeker niet zover laten gaan dat het geweld doet aan de situatie, zoals de mespunten in Top50 die je ziet aan het einde van sloten (eindigt aan de kopse kant op 1 node ipv meerdere).

Wel probeer ik een balans te vinden gelet het brede toepassingsbereik van OSM om de data niet topzwaar te maken met een detailniveau dat niet echt bij het doel van OSM past (daar hebben we ook de BGT en de Legger voor).


edit: correctie / toevoeging grote areas / polders

Dit lijkt me een prima idee - maar wel veel werk!

Op dit moment is bijna al het grasland in NL getagd als landuse=grass (door de 3dShapes-import)
Vanuit de Wiki zou landuse=grass eigenlijk gelden voor kleinere oppervlakten gras zonder echte functie, die zo nu en dan gemaaid worden: wegbermen etc.

Misschien is het een idee de weilanden in de polders van Rijnland (en later de rest van NL??) gelijk om te taggen naar landuse=meadow??
Vrijwel al het gras tussen de sloten in (nog…) in agrarisch gebruik als weiland en/of hooiland
Waar agrarisch land omgevormd is tot natuur is natural=grassland waarschijnlijk weer beter.

Het talud van een dijk, en wegbermen zouden wel op landuse=grass kunnen blijven staan.

Succes

Inderdaad.
Heb net overgens de [name=] verwijderd uit de wiki, die doen we -als die er al is, in de polder alleen bij een beperkt aantal primaire vaarten- doorgaans toch op een waterway in de water-area

Wil in plaats daarvan eigenlijk nog wel een [water=] toevoegen en denk eraan een aparte value voor te stellen, want de bestaande keys voldoen naar mijn smaak niet echt voor wat wij poldersloten noemen, is als netwerk toch van een andere orde dan een alleenstaande en vaak droogstaande ditch naast een weg zoals je die in de wiki ziet, maar dat is iets voor een aparte discussie

Heb er tijdje over getwijfeld, de brondata bevat erg veel info die ik persoonlijk wel interessant vindt (voorgeschreven diepte, taluds, id), maar ik wil van OSM ook geen schaduw-legger maken. Die data is al goed ontsloten via BGT/legger en past minder bij het primaire doel van OSM.

Ik wil erg graag de land/waterdata op een mooi niveau op orde krijgen (toch een van de meest essentiële kenmerken voordat je aan de rest begint: is het land of water…), maar wil ook voorkomen dat ik daarmee de database en afgeleide producten overmatig belast met mijn liefhebberij

Zoals net omschreven is het geen complete dissolve, maar blijven de primaire en secundaire vaarten van elkaar gescheiden.
Door de manier waarop de primaire vaarten door de polders lopen werkt het dan goed.

Heb een plaatje aan de wiki toegevoegd om dit te illustreren.
Voor meer voorbeelden, zie de donkerblauwe vaarten binnen de polders op http://rijnland.webgispublisher.nl/?map=Legger-watergangen
(lastig is dat de boezemwateren ook donkerblauw zijn, die moet je negeren voor dit doel, daar gaat deze import niet over)

Ook hiervan heb ik een plaatje met toelichting bijgevoegd in de wiki.
Ik heb GIS-hulp hierbij (ben zelf een erge beginner op dit vlak) en eerlijk gezegd weet ik niet meer exact welke instelling is gebruikt (sample file is tijdje geleden gemaakt). Belangrijkste voor nu lijkt me het niveau van generalisatie dat die file weergeeft, is naar mijn mening goed compromis tussen detail en hoeveelheid/bewerkbaarheid data.

De instelling voor de uiteindelijke versimpeling zal ik als we groen licht hebben documenteren in de wiki (het is som een beetje kip-ei), checken adhv resulaten (kan per polder verschillen) en indien nodig aanpassen.

Hoe dan ook zal het met een separaat GIS-programma gebeuren, de optie “weg vereenvoudigen” in JOSM geeft hier veel te grove resulaten, zoals de genoemde mespunten aan het eind van een sloot.


edit: key->value

Dank (-:

Het is inderdaad veel werk -zeker dat maken van die Wiki, worstel nogal met de interface- maar het vooruitzicht om niet eindeloos meer te hoeven overtekenen is ook wat waard.

Ben het met je eens dat ons huidige gebruik van landuse=grass eigenlijk niet optimaal is en het meeste grasland in de polders in rijnland als weide voor grazen/hooiproductie wordt gebruikt.

Ik ben alleen bang dat als ik mij dit onderscheid ook nog eens op de hals ga halen in dit project, dat ik dan -spreekwoordelijk- verzuip in dit polderslotenproject.

Het beste dat naar mijn idee op dit moment haalbaar is, is om het water compleet en goed te krijgen, de huidige landuses daar correct op aan te sluiten, aan te vullen voor zover zaken nu ten onrechte gras worden (residential/farmyard). Dat wordt al een hele klus.

Tegelijk denk ik dat als dat af is, dat er dan een veel betere basis ligt om daarna (en eventueel door anderen) verdere verfijning in de landuse door te voeren.

Persoonlijk zou ik met zo’n verfijning te opzichte van de huidge taggingpraktrijk veel liever wachten tot het landcover-voorstel (waar ik een groot voorstander van ben) is geaccepteerd en wordt verwerkt in eindproducten.

Want de reden dat we hier landuse=grass gebruiken op een manier die schuurt met de Wiki is naar mijn idee dat we eigenlijk nog bezig zijn in OSM om te beschrijven *wat er op de grond ligt * (landcover) in plaats van daar ook nog eens bij te beschrijven hoe het wordt gebruikt, alleen loopt dat in de breed geaccepteerde OSM-tags nogal door elkaar.

Voor nu zie ik nog volop werk om de basale vraag van wat eigenlijk “landcover” is goed in beeld te krijgen, wat frictie met de wiki-definitie neem ik voor nu maar voor lief. Nadat we daarmee klaar zijn, ga ik voor de verfijning mbt eigenlijke *landuse * nog graag de discussie aan of die polderdijk waar niet overal wordt gemaaid, maar wel gegraasd nou wel of geen meadow is :smiley:

Vele waterschappen zijn bezig om natuurlijke oevers te maken, je krijgt dan zo’n strook van 3-8 meter wetland.
Waar vaak dan weer riet op staat. Relevant als je er met de kano langs vaart en weet waar je aan land kan gaan.
natural=wetland
wetland=reedbed

Mooi uitgewerkt voorstel, duidelijk dat je er veel moeite in hebt gestoken en goed over na hebt gedacht!

Ik zie alleen niet in waarom de tag water=drain niet geschikt zou zijn?

Thanks (-:

De reden dat ik water=drain niet zou willen gebruiken ligt erin dat de drain (die nu alleen is gedocumenteerd als waterway) een vaste stroomrichting en een verharde bodembedekking suggereert - en praktisch vooral industriële afvalkanalen zoals geïllustreerd in de Wiki

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddrain

Zoals hierboven beschreven past ditch voor de echte polderslotemn ook niet lekker. De meeste primaire poldersloten (de hoofdvaarten richting het gemaal, doorgaans meer dan 5m breed tot wel 20m) past canal best goed bij bovenstaande beschrijving, maar dat geldt dan weer niet voor de secundaire poldersloten (soms maar 1,5m breed, maar regelmatig ook weer richting de 5m) :confused:

Ik denk er nog even over na en zal er tzt wel een apart discussiedraadje voor maken. Alternatief voor een nieuwe water= *value * (die wil je ook niet onbeperkt toevoegen naar eigen smaak) is een aparte key voor bijvoorbeeld water_system=.
Hoewel je over canal/ditch etc lang kan discussiëren, is wel helder dat het polderwater is, en dat dat qua landschapsinrichting een daadwerkelijk verschil is met boezemwater. Ik voeg die maar vast toe aan de import tags (zit in de brondata als “type”) om te voorkomen dat later wordt verweten dat ik meer tags importeer dan toegezegd.

In die zin is overigens het voorbeeld van de Meerpolder wel weer atypisch: de meeste polders worden omsloten door boezemwater, maar voor de Meerpolder geldt dat alleen aan de noordzijde, aan de andere kanten grenst het aan een “tussenboezem” die is gemaakt voor meerdere polders in het huidige Zoetermeer. Dit was drassig land dat al was al ingepolderd, maar het gebied binnen deze polders kwamen na intensieve turfwinning echt onder water te staan (vergelijk het met de Reeuwijkse Plassen vandaag de dag).

Daardoor was de situatie rond 1745 precies omgekeerd met de situatie tot anderhalve eeuw daarvoor: rond 1600 was de Meerpolder een …meer… en lag daaromheen land, waarna de Meerpolder de eerste droogmakerij was in het gebied.

Zie voor een overzicht van de huidige polders:
http://qgiscloud.com/openkanokaart/rijnland/?bl=mapnik&st=&e=489821%3B6808749%3B511495%3B6819735&t=rijnland&l=Boezemgebied%2CBoezemwater%20%3E50cm%2CPoldergebied%2CPolderwater-naam%2CPolderwater%20primair%20%3E60cm

Zoetermeerse meer als water, daaromheen droog land (jaartal op kaart 1644 - hoewel 1614 geldt als datum afronding droogmaken Meerpolder, kaart opnieuw uitgegeven 1724, toch iets andere doorlooptijden dan nu :wink:
https://www.rijnland.net/@@archieven-proxy?mivast=319&mizig=42&miadt=319&miaet=14&micode=30&minr=1056961&milang=nl&misort=last_mod%7Casc&miej=1650&mif2=412464&miview=viewer

En de situatie rond 1745:
https://www.rijnland.net/@@archieven-proxy?mivast=319&mizig=42&miadt=319&miaet=14&micode=30&minr=1055605&milang=nl&misort=last_mod%7Casc&mif2=412464&mif3=538573&miview=viewer

fragment (ander exemplaar, iets meer vervaagd):


edit:
andere rendering gewijzigd in ander exemplaar, hoewel er daadwerkelijk andere inkleuringen / wateroverlays van deze kaart bestaan lijkt het hier om twee verschillende exemplaren van dezelfde kaart te gaan

Oh? Ik gebruik drain voor sloten. Van verharde bodenbedekking heb ik nog nooit gehoord.

Dan moet je helaas nog nooit een blik op de Wikipagina van waterway=drain (https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddrain) hebben geworpen :frowning: , die is in mijn ogen namelijk glashelder en gaat over een feature die wij in Nederland, met ons vlakke land, eigenlijk niet echt kennen, namelijk voornamelijk stormwater afvoeren met een harde betonnen bodem, waarschijnlijk om grootschalige erosie van zandige gronden in heuvelachtige gebieden met piekafvoeren, te voorkomen.

Een dergelijke constructie komt in Nederland niet bijster veel voor. Wij graven gewoon lekker in sleuf in veen of klei in het vlakke polderland…

Gezien de Wiki omschrijving, moet waterway=drain in NL zelden of nooit gebruikt worden, en zeker niet voor simpele sloten.

Wat vinden jullie -bij gebrek aan passende beschikbare tags voor essentiële landschapskenmerken van een voorstel voor de tags [water=sloot] en [waterway=sloot] ?

Is minder gek dan het misschien op het eerste gezicht klinkt:

https://en.oxforddictionaries.com/definition/sloot

(hoewel poldersloot natuurlijk nog mooier is, al is het maar om voor te stellen hoe Engelse en Duitse medemappers dat proberen uit te spreken :smiley: )

Discussie over tag voor water (sloot?) toch maar afgesplitst naar
https://forum.openstreetmap.org/viewtopic.php?id=61514

om te scheiden van discussie van de import zelf

Zoals hier aangekondigd heb ik het sample-bestand voor de Meerpolder dat bij het importvoorstel was geplaatst nu opgenomen en ingepast in de OSM-database.

Zie https://www.openstreetmap.org/?mlat=52.0813&mlon=4.4758#map=15/52.0813/4.4758

Afbeeldingen van de oude situatie (zowel Carto-rendering als blik in data via JOSM) zijn ter vergelijking te vinden in de kantlijn van het importvoorstel:
https://wiki.openstreetmap.org/wiki/Basisregistratie_Grootschalige_Topografie/Rijnland_polder_water_import

Nav de discussie in bovengenoemd draadje:

Alles wat potentieel bevaarbaar is voor kano’s (in de praktijk: de primaire watergangen) heeft een waterway-lijnelement meegekregen, met daarbij de breedte en diepte uit de legger. (en bij de primaire watergangen is dat ook wat je in de praktijk kan verwachten).

Alle overige vlakken (die niet bevaarbaar zijn) hebben een aanvullende tag water=ditch meegekregen, dus iedereen die om wat voor reden dan ook nog eens ditch-lijnen zou willen genereren ipv de veel informatie-rijkere vlakken kan dat aan de hand daarvan doen.

Als het mee zit komen er ook nog ingemeten brughoogtes beschikbaar; daarmee komen we weer een stap verder richting een beeld van praktische bevaarbaarheid: 100 bruggen van 75cm hoog is geen probleem, terwijl veel kanoërs na 10 bruggen van 50cm hoog er al tabak van hebben :wink:

Over ca 2 weken wil ik verder gaan met prepareren van data en invoeren van de volgende polder, daarbij rekening houdend met overwegende argumenten die eventueel hier nog naar voren komen.

Kijk, dat zoomt een stuk mooier in en uit!
Het verschil met de naastgelegen polder is duidelijk.

Enkele observaties:

  • de precisie t.o.v. de BGT-belijning heeft die van mijn handmatig werk in Kollum (gelukkig :P) nog niet overtroffen
  • de nauwkeurigheid is zeker voldoende; ik ben wel benieuwd wat de kleine afwijkingen veroorzaakt… het lijkt niet alleen door beperking van aantal nodes te komen
  • uitlijning op de ‘binnenste’ blauwe BGT-lijnen, dus op de werkelijke watergrens, en niet op de buitenste waarbij het talud wordt meegenomen; dit heeft ook mijn voorkeur en heb ik zelf zo toegepast
  • de losliggende bruggetjes tussen de landerijen: los laten liggen in de gevallen waar er fysiek niet echt een weg/pad/track is of toch op een of andere manier verbinden?
  • op deze locatie is een stukje bos gekomen, terwijl er volgens de BGT-belijning ook water is… een scherpe luchtfoto laat een eilandje in water zien.

Dan ben je een bijzonder precieze tekenaar, maar dat laat een blik op Kollum ook al zien (-;
Toen ik het nog handmatig overtekende haalde ik ook dit detailniveau niet (met ook de hoeveelheid sloten in “mijn” werkgebied in het achterhoofd).

Naast het reduceren van nodes zou ook de conversie tussen coördinaatsystemen/kaartdatum icm afronding nog voor een kleine afwijking kunnen zorgen. Voor het vervolg zal ik het aantal nodes iets minder reduceren: ondanks dat de hoeveelheid water enorm is toegenomen (vooral in aantal sloten, daarnaast ook in detail van de al aanwezige sloten) is de totale hoeveelheid data van water+gras met ca 1/3 afgenomen. Al die eerder aanwezige aangrenzende grasvlakken maakten niet alleen het bewerken bijna onmogelijk, maar kostten ook veel data.

Inderdaad, een bewuste keuze aangezien het talud ook gras is en het waterniveau erg stabiel.

Dat was een beetje een gewetensvraag:
daar waar ik begon was wel een duidelijk spoor te zien was op de foto (genoeg om later een nieuwe track op de kaart te zetten) en kwam daarna bij twijfelgevallen. Had nu geen tijd om voor elk spoor een afweging te maken (voor je het weet zit je alle paden op een boerenerf te tekenen ;)) en heb het met tracks over het water gedaan. Als iemand het wil verfijnen met een aanvullende [man_made=bridge] dan is dat prima, dat zou *als vervanging *kunnen als er in het verlengde echt geen track van te maken is.

Betrapt :open_mouth: Scherpe blik. Dit is inderdaad een bebost eilandje in een vijvertje.
Waterpartij was gesneuveld in een edit, JOSM-validatie mopperde ivm multipoly in multipoly en heb daar vanwege gering belang van het vijvertje (en trage voortgang, moest ook alle farmyards/residentials aanvullen) snelle keuze gemaakt om dit kleine beetje water weg te laten. Verderop in het proces -bij BGT-items die ik niet weg wilde laten- goedwerkende oplossing gevonden voor dit soort situaties waar de JOSM-validatie ook blij mee is en nu ook het vijvertje weer teruggezet :slight_smile:

edit:typo’s (oa. gas->gras :wink: / aanvullingen

Even snel twee slippy kaartjes onder elkaar gezet waarbij je het verschil in dekking van water tussen oud en nieuw te zien is (oud obv openstreetmap.nl, werkt voor dit doel zolang kaartbeeld nog niet is geactualiseerd aan edits van vandaag)

http://www.openkaart.net/meerpolder.html

Energierekening niet betaald of een stuk zuiniger gaan leven? :P:D

Deze eerste testcase lijkt qua output in elk geval goed geslaagd!

Een vlak met man_made=bridge zou inderdaad een goede optie zijn als van een track geen sprake is: een verschuiving van routeobject naar omtrekobject.

Goed dat het vijvertje met eiland al is gecorrigeerd en het werkproces reeds verbeterd. Prima bezig!

Hoe staat het er inmiddels voor, na de geslaagde test?