Dijken mappen in NL

Polygon, die had ik al gegeven. Een vlak, een tag, welke? slope=dike?

Ik zat te denken aan een relatie bestaande uit twee lijnen die min of meer parallel aan mekaar lopen. De kruin krijgt de rol high en de teen krijgt de rol low.
Maar ik heb geen idee hoe dat geïmplementeerd zou kunnen worden in een style voor een rendering.
En dat is wel nodig om er mee te kunnen experimenteren.

1 Like

gewoon man_made=embankment misschien?
embankment is namelijk het woord voor het talud. Bij OSM geven ze dat aan met alleen de bovenlijn, en voor bv embankments die een bergweg ondersteunen is dat ook wel prima, die zijn heel steil.

Wat zou je precies willen renderen? De lijnen, of de ruimte ertussen? Als je de lijnen al hebt getrokken, wat voegt de relatie daaraan toe voor de rendering?

1 Like

Ik ben het eens dat de aangehaalde voorbeelden laten zien dat we aanvullende tagging nodig hebben en misschen ook wel relaties om de verschillende elementen van dijken / wallen en hun onderlinge verhoudingen goed weer te geven.

Ik weet ook nog niet precies hoe, maar ben begonnen om met eens te kijken naar hoe de wiki’s van OSM zich verhouden tot de daarin aangehaalde bronnen. En hoe die wiki’s zijn veranderd over de loop van de tijd en hoe de tags in werkelijkheid worden gebruikt.

Heb oa een stukje toegevoegd over de verschillende elementen in een embankment, om duidelijkheid te hebben over de termen
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment#Elements_of_an_embankment

en een stukje over de ontwikelling van de wiki over de tijd en verschillende interpretaties:
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment#Actual_usage,_ambiguity_and_controversy

Dat zou je misschien denken als je de plaatjes in de OSM-wiki ziet -met een focus op het talud-, maar de aangehaalde bronnen laten zien dat embankment de term is voor het geheel van talud(s) & de kruin (slope/face & crest/crown).

Zie naast het diagram van een embankment is in de eerste link bijvoorbeeld ook deze die al in de wiki was aangehaald :

https://en.wikipedia.org/wiki/Embankment_(earthworks)
A road […] is normally raised onto an embankment

https://en.wikipedia.org/wiki/Levee
A levee, dike (American English), dyke (Commonwealth English), embankment, floodbank, or stop bank is a structure […]

image

Inderdaad. Maar OSM heeft dat beperkt tot het aangeven van 1 talud mbv alleen de kruinlijn. Ik denk dat de beperking tot 1 talud verstandig is, anders wordt het een erg ingewikkelde struktuur om te mappen. Maar de beperking tot 1 bovenlijn is niet genoeg voor bijvoorbeeld een redelijke weergave.

Ik heb een invoertestje gedaan met een MP die de elementen (lijnstukken) van één talud kan bevatten, met een surface van gras en een “eilandje” van scrub erin. Het is een echt stukje van Nieuwerkerk, allen de scrub is een beetje overdreven voor slecht gemaaid gras.

Hier is de mapping:

En zo ziet het eruit:
image

In dit geval is er maar 1 zijlijn, want het gaat om een driehoekig talud aan 1 hoek van een aquaduct.
De kruinlijn wordt goed gerenderd en het stukje scrub. Het vlak (de MP) kan denk ik ook gerenderd worden als ik het een hoofdtag geef. De teenlijn heb ik getagd met embankment=toe en de zijlijn met embankment=descent (gerekend in de richting van de way). Merk op dat ik geen speciale rollen heb gebruikt, de lijnen die samen de outer vormen, worden als zichzelf gerenderd. Als er een rendering voor embankment=toe was, zou je die zien, zelfs zonder de MP.

Het effect is best realistisch, door het stukje scrub erin, dus daaraan zie je een beetje wat de rendering van het vlak kan doen. Zonder scrub maar met een teenlijn die mbv wat schaduweffect een knik in het land suggereert, zou je ook een redelijke indruk krijgen denk ik. Zelfs als de gebruikte svg niet schaalt.

Toevoeging:
Het scrub-eilandje weggedaan, nu de hele MP natural=scrub gemaakt en een naam gegeven.
De onderlijn ook man_made=embankment gemaakt, maar dan verkeerd om, zodat de lijntjes het talud op wijzen, om een indruk te geven.

En hier een hele dijk, gemapt als twee MP-vlakken.
JOSM:

Hier kan je het resultaat op OSM Carto zien. Niet subtiel, maar je ziet de potentie.

Terwijl ik zo bezig was bedacht ik dat je met een andere rendering misschien helemaal geen onderscheid tussen de omtrekdelen van het taludvlak hoeft te maken. Als je de man_made=embankment nou eens rendert als een scheve kam? Dus Kogacarlo’s .svg’tje maar dan 45 graden scheef, dus tov van de rechterzijde 45% scheef naar beneden. Als je dan de embankmentlijn domweg rond het embankment trekt, de goede richting op, dan staan alle scheve lijntjes naar de binnenkant van het vlak en geven dank een soort schaduwwerking die misschien wel goeed werkt.

Zou jij dat 's kunnen proberen, @Kogacarlo ?

Nee, dat is niet het geval, zoals je zelf al eerder terecht al constateerde in #7 :

En je ziet ook in de praktijk dat man_made=embankment ook op die laatste manier (voor het omschrijven van de onderkant van het talud ) wordt gebruikt.

Die laatste geometrische afbakening van man_made=embankment past ook beter bij de omvang van de gehele feature in de buitenwereld dan het beperken van de OSM-geometrie tot de kruinlijn.

Anders is het alsof je van een gebouw met een binnenplaats erin alleen de omtrek van die binnenplaats als geometrie in OSM zou zetten met de algemene term van een building=* , en datagebruikers zelf moeten raden aan de hand van andere data waar dat gebouw ophoudt.

Ben het eens dat de hele tagging beter moet worden uitgewerkt en gedocumenteerd om dijken goed weer te geven, maar om echt vooruit te komen is dat er eerst een goed gedocumenteerd en gedeeld beeld is van de te mappen elementen en termen daarvoor.

Door nu gelijk op de rendering te richten is er een grote kans dat er alsnog een inconsistent datamodel komt waarmee je later vast loopt (werkt een methode bijvoorbeeld ook voor een ringdijk?)

Zo zie ik in het recente voorbeeld -dat ik er op zich wel mooi uit vind zien :wink: - knippen in zowel de lijn aan de onderkant van het talud als in de lijn aan de bovenkant van het talud die er in werkelijkheid (altijd) niet zullen zijn. Dat lijkt me geen goed uitgangspunt voor modellering.

De definitie zegt: rechts is de onderzijde. Hoe weet de data user dan of het een onderkant of een bovenkant is? De renderer, bijvoorbeeld, geeft de lijn met daalaanduiding rechts (bv de driehoekjes of puntjes of lijntjes). Dan krijg je dus twee dalingen naast elkaar ipv een daling en het einde van de daling. UIt het gehele wiki-verhaal blijkt dat men alleen de bovenlijn voor ogen had, niet het talud of de teen.

Erger nog, alleen de voorgevel! Ja, ik denk dat het inderdaad zo bedacht is. Nou is een onderlijn van een dijk wel iets voorspelbaarder dan een omtrek van een gebouw, maar inderdaad, dat is het probleem.

Ik richt juist op het model, namelijk: een dijk modelleer je met twee talud-vlakken, die elk een bovenlijn en een teenlijn hebben, gekoppeld met een stijgende lijn en een dalende lijn, waarbij het vlak een landuse/landcover/natural kan zijn die daarbinnen weer stukjes afwijkende landuse/natural/landcover kan hebben. Elk taludvlak kan bovendien een naam hebben (dat kwam ook ter sprake ergens, dat dijken van de ene kunt zus en van de andere kant zo kunnen heten).

Ik kwam tot dit mapping-model vanuit de eisen die gesteld werden, in dit draadje.

De rendering gebruik ik om het mapping-model te testen. Als het model niet de juiste info bevat voor het beoogde gebruik, dan moet het aangepast worden.

Ik ben er niet op uit om persee alle onderdelen van dijken (waterbouwkundig correct) te mappen, alleen de delen die voor gebruikers van OSM relevant genoeg zijn én in een haalbare benadering.

Het model maakt knippen mogelijk, maar het kan ook aansluitend. In dit geval ligt er een informeel paadje de dijk op, en net als met een track op landuse, kan je dan listig de landuse aan weerszijden apart mappen. Of je legt het paadje over de doorlopende of gekoppelde landuse heen, en dat had in dit geval ook gekund. Dus het model maakt dat mogelijk maar vereist het niet.

Probeer, multipolygoon vlakken te voorkomen, met meerdere outer lijnen. Dat is lastig.

Zonder me met de inhoud te willen bemoeien… misschien biedt de BGT nog wel wat inspiratie. Ik heb daar de vlakken die op een talud liggen en de kruinlijnen uitgehaald en in een geopackage gestopt. (te gebruiken met bv Qgis) Hopelijk voegt het iets toe.

1 Like

“paadje” weggehaald. Je kan nu zien hoe dit overkomt als je niet bi deze diskussie was: een hele lange put met een langgerekt eiland in het midden.

image

Je wil een oplossing die ook voor anderen op een dijk lijkt.

Gaan we dan ook vestingwallen in detail mappen?

Als een lange dunne wal met een gracht er omheen :ok_hand:

Zo iets? Zoomlevel 18:
Scheef talud 01

Geen idee, ik bepaal (net als de andere mensen hier) niet welke mapper welk geografisch object in welk detailniveau mapt. Als iemand binnen de kaders van OSM een werkbare manier vindt om vestingwerken in een hoog detailniveau te doen, dan wens ik de mapper veel mapplezier.

Zelf zal ik dat niet snel zo doen, ik vind het al mooi als er een werkbare en goed gedocumenteerde manier komt om de afbakening van een buitentalud, kruin en binnentalud van een dijk vast te leggen conform de situatie in het veld, waarmee dataverwerkers desgewenst kunnen werken.

Heb zelf een binnentalud op het oog met een oppervlakte van ca 500.000m2 (oftewel de footprint van ca 10.000 eensgezinswoningen). Dat lijkt me eerder macro-mapping dan micro-mapping :wink:

1 Like

Dank voor de test. Het oogt voor mij ietsjes beter, de streepjes laten zien dat de ene kant van de dijk 1 talud is en niet 2 taluds naast elkaar. Maar het nog steeds alleen maar duidelijk als je de situatie al kent, want ipv een talud zou het ook een kuil kunnen zijn.

Al met al denk ik dat het niet zonder aparte teenlijn kan. Aan de andere kant kan je dat ook niet verplicht stellen, want ik ken tig plekken waar je die gewoon niet goed kan onderscheiden. Of waar het overkill is om de teen apart aan te geven.

Bijvoorbeeld 15 Km bijna rechte spoordijk met links en rechts vrijwel aansluitende sloten, lijkt me zat (en ook nuttig) om daar de kruinlijn aan te geven. Embankment=yes op de spoorweg zelf kan dan ook. (geldend voor de rechterkant naast de spoorbaan), het is niet geografisch precies maar kan dan misschien wel mooi schalend gerenderd worden zonder dat de weg het overdekt.

Nog een voorbeeld:
image
Hier heb ik wat echte spoordijk kruinlijnen getagd bij Gouda. Op de BGT omtrekgericht staan ze als haaietandlijnen, ik vermoed dat dat dan een versterkte kruinlijn betekent. Het stuk tussen de twee spoordijken in is ook echt een kuil, de spoorlijnen liggen ieder op een eigen dijk op het maaiveld van de polder.
Als je man_made=embankment ook als ondelijn gebruikt, zou het zomaar kunnen zijn dat de ene spoorlijn halverweg het talud van de andere spoorlijn ligt.

Ik heb een hengeltje uitgegooid op de algemene tagging categorie. Om het niet gelijk te ingewikkeld te maken noem ik alleen het aangeven van de teenlijn. Volgens mij is dat in elk schema voor mappen van dijken nodig, dus een mooi startpunt om te kijken hoe hier internationaal over gedacht wordt.

1 Like

Mooie weergave. Kunt u een voorbeeld testen met aparte lijnen voor de bovenrand (man_made=embankment) en voor de teen_lijn (een willekeurige andere lijn)? Liefst met verschillende afstanden?

Het is duidelijk dat de kleine fijne lijntjes (die loodrecht op de weg staan) elkaar kunnen kruisen als de afstand klein is en elkaar niet raken als de afstand groot is. Ik zou het graag weergegeven zien op een voorbeeld.

Bedankt als het mogelijk is.

Vertaald met DeepL Translate: The world's most accurate translator (gratis versie)

Nice rendering. Can you test an example with separate lines for the top edge (man_made=embankment) and for the toe_line (any other line)? Preferably with different distances?

It is clear that the small fine strokes (which are rendered perpendicular to the way) can cross each other when the distance is small and not touch each other when the distance is large. I would like to see it rendered on an example.

Thank you if it is possible.

Translated with DeepL Translate: The world's most accurate translator (free version)