Dijken mappen in NL

Dies wurde erst vor 4 Wochen ins Wiki eingefügt und ich teile diese Meinung nicht.

Daarom zou dit ook beperkt moeten zijn tot talud. Die kun je overal voor gebruiken, inclusief insteek (neem aan dat je dat bedoelt met ‘cutting’…).
Je moet geen dijk als geheel willen opnemen, ook al omdat er ‘dijken’ zijn die maar aan 1 kant een talud hebben.

Maar man_made=dyke zegt: alleen een lijn bovenop trekken en taggen met man_made=dyke. Dat is precies wat we willen uitbreiden. Overigens zonder dit te ‘verbieden’: alle bestaande man_made=dyke blijven wat ze zijn, totdat iemand het meer gedetailleerd wil mappen, en dan nog zou je het kunnen laten staan, Net als embankment=yes op een way middenop de dijk, al of niet gekombineerd met een highway value. De nieuwe tags voor crest en toe kunnen daar gewoon bij om detail toe te voegen. Een simpele extra teenlijn kan ook bij man_made=dyke en embankment=yes worden toegepast om het dijkareaal aan te geven.

Dat kan voor een deel van een dijk, maar ook voor het geheel, als dat tenminste in 1 areaal te vangen is. Wat met zeedijken, rivierdijken en polderdijken zelden het geval zal zijn.

PS als we principieel gaan: we hadden al man_made=embankment. Een dijk is een soort embankment, dan zou die geen eigen man_made value moeten krijgen, maar zou je met embankment=dyke||road_support|railway_support|* nader moeten specificeren.
Nou ben ik niet zo principieel hoor. Meer praktisch. Daarom stel ik eigenlijk alleen de teenlijn als aparte feature voor.

Op een highway kan je embankment=yes hebben, er is ook cutting=yes hoe wordt dan de bovenzijde genoemd, als er man_made=embankment is, dan is er ook man_made=cutting, ook een kruin? Mogen we dat “crest” noemen?

In vergelijking bij een sloot, waar wij spreken over “insteek” is dat ook een crest, het is daar gegraven, dan is er dan sprake van een cutting. in het landschap.

Gedachte, zoekende.
Als ik kijk naar area:highway=emergency kan je met een direction tag de stand van de belijning van een verdrijvingsvlak aangeven, zoiets, zou je ook bij een slope kunnen doen.

En zo zal er nog wel voorbeelden binnen OSM zijn, wat op een vlak de richting aan geeft.
Ook bij een bocht, kijkend vaar viewpoints, geeft direction ook de mogelijkheid om van/tot aan te geven.
Het slope vak aangeven voor zowel een cutting, als een embankment, ook kijkend naar de sloottalud.

Wellicht is een meer algemenere k/v combinatie gewenst.
Dat zie je wel meer, voor de een maar ook gebruikt voor de ander, kijkend naar OSC cutting speelt hetzelfde, nu alleen embankment toe lijn, later zal iemand die cutting toe lijn willen hebben. De keuze van embankment in naam is dan lastig om de kruin /insteek aan te geven.

=yes, zegt niet precies waar het ligt, en dat is wat je beoogt aan te geven de exacte locatie, dan kan het niet met embankment=yes, omdat deze ook het niet goed liggende aan geeft. Pas bij nieuwe k/v combinatie kan je aangeven het ligt precies daar.

Ik geef aan dat man_made als key niet voor deze toepassing kan worden gebruikt.

Als iemand het vlak gaat aangeven, dan zal hij die lijn verwijderen met man_made=dyke.
Vlak geeft meer detail weer dan een lijn.

Cutting
embankment=yes op een highway geeft aan dat de weg op een verhoging ligt.
cutting=yes op een highway geeft aan dat de weg in een uitsnijding ligt.
Beide zeggen niets over de verhoging of uitsnijding zelf. Mijn voorstel doet hier niets mee.

Voor de cutting zelf is dacht ik geen mapping bedacht. Als mappers het een soort embankment zouden vinden zouden ze de voorgestelde embankment mapping kunnen gebruiken. Als mappers het een aparte feature vnden die eigen mapping moet hebben, zouden ze dat van embankment kunnen overnemen, maar dan met cutting ipv embankment. Hetzelfde geldt voor andere feautures waar een bovenrand, een helling en een onderrand aan zit.
Voor een muur is het minder handig, want die heeft tussen bovenrand en onderrand te weinig horizontaal oppervlak.

Een algemene feature “onderrand” voor alles wat een onderrand heeft, zou kunnen maar ik denk dat het beter is het per grote constructie te doen, zodat het duidelijk blijft wat er gemapt wordt.

man_made=dyke

Ik neem aan dat dat gaat gebeuren. Maar dat is aan de mappers. Er zijn meerdere mogelijkheden om een dijk te mappen, van marginaal tot best uitgebreid, en het is logisch om 1 methode te kiezen, waarbij de minder precieze weggehaald wordt. Maar ze bijten elkaar niet, in mijn voorstel. Je kunt dus ook kiezen om man_made=dyke of embankment=* te laten staan en alleen een teenlijn toe te voegen. als die verifieerbaar is. embankment=* op een highway heeft het voordeel dat de renderer hem kan weergeven als een verhoogd lopende weg, op alle zoomlevels. Een aparte embankmentlijn dicht bij een weg wordt bij uitzoomen overdekt door de weg, omdat die niet evenredig schaalt.

Direction op een vlak
Omdat het om gebogen 3d-vlakken met wisselende hellingshoeken gaat, die ook nog rondingen kunnen hebben, lijkt het mij heel lastig om met direction te werken. Bij bv verdrijvingsvlakken met strepen erin kan je vrij gemakkelijk de richting van de strepen aangeven. Bij de taluds denk ik dat je niet ontkomt aan de bovenstreep en de onderstreep als referenties voor de richting. Direction is misschien een mooie toevoeging in de toekomst, maar ik hou het er voor nu op dat de lijnen essentieel zijn. De bovenrand geeft meestal al aan waar de diepte zit; voor de teenlijn zou ik vergelijkbaar een weergave willen die subtiel aangeeft waar de helling zit. Dus de richting waarin de teenlijn getrokken wordt bepaalt waar de helling weergegeven wordt. Als dat lastig is, is een simpel lijntje zoals bij een muurtje ook al genoeg.

man_made?
man_made=embankment wordt gebruikt om precies de kruinrand aan te geven. In het geval van embankments is een kruinrand een kunstmatige, man_made constructie. Dat geldt precies zo voor een teenlijn van een embankment. Dat is een kunstmatige lijn in het landschap. Het is geen amenity, het is geen natural, geen landuse, geen leisure, … het is dus man_made.


BGT talud bestand van PeeWee32

Ik keek nog even naar het RWS bestand DTB. Public domain data.
Hoe men het daar benoemd en de ligging.
Zelfde locatie als eerder post van mij. locatie
afbeelding
wfs DTB vlakken met omschrijving


wfs visualisatie DTB vlakken en lijnen met omschrijving.

wms DTB visualisatrie lijnen over luchtfoto


wms DTB lijnen over Openstreetmap.

wms DTB vlakken over Openstreetmap


wms DTB vlakken over luchtfoto

Kijkend naar de verschillen in bedekking weergave door het Waterschap en Rijkswaterstaat.
Eerder gemaakte opmerking.

Wat ik zelf ook constateer, dat er langs de dijk rijdend tussen de stenen/stortstenen, allerlei begroeiing staat, van gras, kruidachtige, riet, bossage.
Dan kom je uit bij, hoe aangeven, wat is surface en wat is landcover.
Waar dit topic over gaat.


Dat riet staat dan nog gedeeltelijk, op het talud tussen de bekleding, tussen de stortstenen boven ongerveer RWS oeverlijnen verder tussen de stortstenen in het water en dan nog op de bodem meer.
Riet staand op de bodem van een meer, is dat wetland? of ook tussen de stortstenen.
We kennen wetland=reedbed.
Zou men dan zo’n key/value verkeerd gebruiken.
Is landcover de oplossing.

Entschuldigung, dass ich auf deutsch antworte.

@Allroads: soweit Ich Dich verstehe (und mein Übersetzer es halbwegs richtig wiedergegeben hat) finde ich Deine Überlegungen alle viel zu kompliziert gedacht. Es geht nicht nur um Deiche. Es geht nicht darum, alle möglichen Details des Aufbaus eines Deiches oder Dammes zu mappen.
Es geht, ganz simpel, nur um diejenigen Teile, die sichtbar sind und die von jedem Mapper erkannt und gedeutet werden können. Das sind die obere Kante der Böschung (schon heute vielfach gemappt mit man_made=embankment), die untere Kante der Böschung (in den Niederlanden nennt Ihr dies teenlijn, wir nennen es Deichfuß) und vielleicht die geneigte Fläche dazwischen, die Böschung. So einfach wie möglich!

“embankment” als Wort kann mehrere Bedeutungen haben, und Übersetzungen in andere Sprachen machen es manchmal noch verwirrender. embankment zum Beispiel ins Deutsche übersetzt kann “Aufschüttung” heißen (eine Aufschüttung kann ein Deich, ein Verkehrsdamm oder auch ein erhöhtes befestigtes Ufer sein) oder auch “Böschung” heißen (was im Deutschen die geneigte Fäche zwischen Oberkante und Unterkante meint. Böschungen gibt es bei Deichen/Dämmen, aber auch die natürliche Uferböschung an einem Fluss oder bei Einschnitten (cutting) oder offenen Tagebauen.

Das einfache Grundprinzip ist bei allen Arten gleich: es gibt (meistens gut sichtbar und erkennbar) eine Oberkante, eine Unterkante und dazwischen eine geneigte Fläche. Deshalb kann der Vorschlag von Peter sehr universell angewendet werden: an Eisenbahn und Straßendämmen, an Deichen, an Einschnitten, an Gruben und Tagebauen, an Verteidigungswällen etc. Der Vorschlag soll Renderern helfen, solche Böschungen besser zu visualisieren, denn jetzt gibt es nur eine Möglichkeit, die weit überwiegend für die Oberkante verwendet wird (die seit Mitte Januar im Wiki stehende Ergänzung von Multimodaal halte ich nicht für richtig, weil viel zu detaillert, kompliziert und mehr Verwirrung stiftend. Die wenigen abweichenden Fälle, wo man_made=embankment nicht für die obere Kante verwendet wird, sind entweder Mappingfehler oder bewusstes Mapping für den Renderer. Und gerade das letzte Problem kann mit dem Vorschlag von Peter behoben werden.

Und macht es bitte nicht am Namen des value fest, der das Wort “embankment” enthält. Im OSM-Universum sind Fußwege ja auch Highways, ohne dass es bislang jemanden wirklich stört …
Gern sind aber auch bessere Vorschläge willkommen, aber bitte nur für Oberkante, Unterkante und eventuell die Fläche!

Ach so: landcover ist keine Lösung! Das ist ganz was anderes und kann je nach Böschung verschieden sein. Und wenn auf einer Seite Wasser ist, braucht man keine Unterkante mappen - die unterste sichtbare (!) Linie ist die Wasserkante - und die ist meistens schon detailliert gemappt.

Translation:

Neem me niet kwalijk dat ik in het Duits antwoord.

@Allroads: voor zover ik je begrijp (en mijn vertaler heeft het half goed weergegeven), vind ik je overwegingen allemaal veel te ingewikkeld. Het gaat niet alleen om dijken. Het gaat niet om het in kaart brengen van alle mogelijke details van de aanleg van een dijk of dam.
Het gaat, heel eenvoudig, alleen om die delen die zichtbaar zijn en die door elke kaartlegger herkend en geïnterpreteerd kunnen worden. Dit zijn de bovenrand van de dijk (vlak?) (al vele malen in kaart gebracht met man_made=embankment), de onderrand van de dijk (vlak?) (in Nederland noem je dit teenlijn, wij noemen het dijkvoet) en misschien het glooiende oppervlak daartussen, de dijk (vlak?). Zo eenvoudig mogelijk!

“embankment” als woord kan verschillende betekenissen hebben, en vertalingen in andere talen maken het soms nog verwarrender. embankment kan bijvoorbeeld in het Duits vertaald “Aufschüttung” betekenen (een dijk kan een dijk zijn, een verkeersdijk of zelfs een verhoogde versterkte oever) of het kan ook “Böschung” betekenen (wat in het Duits het glooiende oppervlak tussen de bovenrand en de onderrand betekent. Hellingen komen voor in dijken/dammen, maar ook in de natuurlijke oever van een rivier of in afgravingen of open groeves.

Het eenvoudige basisprincipe is voor alle types hetzelfde: er is (meestal duidelijk zichtbaar en herkenbaar) een bovenrand, een onderrand en een hellend vlak daartussen. Het voorstel van Peter kan daarom zeer universeel worden toegepast: op spoor- en wegbermen, op dijken, op uitgravingen, op kuilen en open groeves, op verdedigingswallen enz. Het voorstel moet renderers helpen om zulke dijken beter te visualiseren, want nu is er maar één mogelijkheid, die veel overwegend wordt gebruikt voor de bovenrand (de toevoeging van Multimodaal, die sinds half januari in de wiki staat, vind ik niet juist, omdat het veel te gedetailleerd en ingewikkeld is en meer verwarring veroorzaakt. De enkele afwijkende gevallen waarin man_made=embankment niet wordt gebruikt voor de bovenrand zijn ofwel mappingfouten of bewuste mapping voor de renderer. En juist het laatste probleem kan worden opgelost met de suggestie van Peter.

En maak het alsjeblieft niet om de naam van de waarde die het woord “embankment” bevat. In het OSM-universum zijn voetpaden (footway) ook snelwegen (highways) zonder dat iemand daar echt last van heeft …
Betere suggesties zijn ook welkom, maar alsjeblieft alleen voor de bovenrand, onderrand en eventueel het oppervlak!

Ach ja: landcover is geen oplossing! Dat is iets heel anders en kan variëren afhankelijk van de helling. En als er aan één kant water is, hoef je de onderrand niet in kaart te brengen - de laagst zichtbare (!) lijn is de waterrand - en die is meestal al gedetailleerd in kaart gebracht.

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

3 Likes

Dank, @Allroads, voor de uitgebreide toelichting. Ik las het met in gedachten: hoever kom ik met de voorgestelde mapping van bovenrand, onderrand en talud. Ik denk: heel ver, waar het gaat om het aangeven van ligging en vorm van de dijk in het landschap.

Wat betreft de vlakbedekking: alleen de landcover van het talud is voorzien, dmv een vlak van bovenlijn, onderlijn en verbindende lijn(en). Dat is dan een multipolygon met alleen outers. Al kan er natuurlijk ook een inner in, als het talud nog een andere feature bevat die uitgesneden moet zijn. Bijvoorbeeld, het talud is een schapenwei, maar er liggen volkstuintjes in, of bosjes, die je ook wil mappen. Dan wordt de multipolygon man_made=embankment:slope & landuse=meadow, en als inner heeft hij een landuse=allotments of natural=scrub.

Dat kan ook als een deel van het talud versterkt is: man_made=reinforced_slope. Voor de rest, landuses en naturals kunnen gewoon gemapt worden waar ze liggen, ook overlappend. Ook residential, farmyard, leisure, industrial.

Een coupure in de dijk: map embankments aan weerszijden van de coupure.

en dan afsluiten met een barrier=retaining_wall? Zo heb ik het nu aangepakt, voorbeelden:

image
en
image

Maar ja, dan kom je dit betonnen ding tegen, en dat is duidelijk geen retaining_wall, dus hoe je dit nou weer netjes karteert…

reinforced_slope dan? barrier=floodgate?

PS coupure wordt dacht ik ook in het Engels gebruikt.

taginfo:
barrier=floodgate 2x
barrier=flood_gate 43x

barrier=coupure
taginfo

De eerste twee wel ja, maar die derde is het probleem…

coupure word inderdaad ook in ‘t Engels gebruikt, maar da’s een node op de way, zie Allroads’ post. barrier=flood_gate is misschien nog wel een interessante. Die ga ik eens opzoeken.

Hm… the English word is floodgate, I think?

Oude forum

1 Like

Ik heb alles wat ik uit de NL en internationale diskussies opgestoken en bedacht heb in een osm dagboekartikel gezet. Ik hoop dat ik ieders inbreng recht heb gedaan, en als ik een andere keuze heb gemaakt dat ook voldoende onderbouwd heb. Het is een verhalende samenvatting in het Engels.

De volgende stap wordt een echt voorstel, veel zakelijker, natuurlijk wel met verwijzing naar de diskussies en naar dit dagboekartikel. Na deze voorbereiding hoop ik de RFC / CFV vlot te kunnen afwerken, al zal er vanuit de tagging lijst nog wel eea komen van mensen die hier niet op het forum zitten.

1 Like

Het is er helaas nog niet van gekomen. Maar op dit moment ben ik bezig met een stuk kust met zee- en rivierdijken. Ik kom er veel tegen waar het gehele dijklichaam met een lijn omsloten is, getagd als man_made=dyke plus natural=meadow. Dat rendert als een groen vlak zonder relief. Van sommige is dyke veranderd in embankment, wat tot gevolg heeft dat het ofwel als een kuil weergegeven wordt, ofwel als een hééél grote kruin.
Meestal ligt er een weg of pad op de kruin, wat dus ook groen wordt. Qua tagging kom ik allerlei varianten tegen: dyke=yes, embankment=yes, embankment=dyke. Er liggen ook reinforced slopes, en de ways zitten geregeld vast aan de randen van de area polygons.

Wat ik wil doen

  1. De kruinlijnen met de juiste richting toevoegen als man_made=embankment, aan beide zijden dus, en niet met elkaar verbonden.

  2. De dijkhellingen/grastaluds apart mappen, inklusief eventuele belangrijke objecten die op de hellingen liggen.

Ik zou de omsluitende man_made=dyke lijnen kunnen omzetten in embankment_toe, alleen de lijndelen die dwars over de dijken gaan slaan dan nergens op. Meestal zijn de teenlijnen ook al de randen van aansluitende vlakken, bv een sloot, een weiland, een wetland, een reinforced slope of de kustlijn. Komt erop neer dat de man_made=dyke polygon alleen dient om er een groene kleur op te kunnen zetten dmv een landuse of een natural.
Dus ofwel ik hak hem in tweeën door de weg te omtrekken, dan polygoncutout te doen en dan de wegomtrek weer weg te gooien, ofwel ik gooi de dijkomtrek-polygon weg en map beide taluds opnieuw as aparte polygons, waarbij ik alleen gewenste landuse/natural-verbindingen plak.

Ga ik nog een proposal doen? Ooit misschien. Eerst een paar goede voorbeelden, dat helpt misschien nog meer dan een formeel proposal.

Even om te illustreren wat ik bedoel:
Hier een ‘gewoon’ stuk dijk, met beide taluds geselecteerd:


Het gras loopt tot aan de rand van de weg, en de kruinlijnen liggen naast de weg in het gras. De teenlijnen zijn de onderrand van het grastalud, aansluitend op het omliggende gebied.

En hier een illustrate van een speciaal stukje, met de oude omsluitende man_made=embankment er nog op, geselecteerd:


Met de taludgerichte methode kan je dit veel beter modelleren, nadeel is dat het veel meer detail vraagt, dus meer werk en preciezer werk, kost veel meer tijd.

PS bovenste plaatje: waterzijdig kan je zien dat de teenlijn van het bovenste talud eigenlijk nog iets hoger ligt, je ziet een witte streep met daaronder een iets donkerder bandje. Zoals het nu getekend is, krijg je bij de rendering een ietsjes te lage nepteenlijn te zien. dus als ik nog preciezer wil zijn, kan ik de echte teenlijn er nog aan toevoegen. Maar op veel plekken heb je die precisie gewoon niet, het is maar zelden dat je het op de beelden echt precies kan zien.

Sorry, mijn Nederlands is gewoon een automatische vertaling van deepl.

Grappig, ik zat er net aan te denken om te vragen of er iets veranderd is aan dit onderwerp.

Dit is half correct, maar het wordt niet weergegeven.
Waarom half juist? Ik geef de voorkeur aan man_made=dyke als lijn, niet als oppervlak. Tenzij de dijk een gesloten ring vormt, maar dan met area=no.

Ik denk dat dat verkeerd is. Tagging is voor lineaire elementen, niet voor oppervlakken.

Ik ben het met beide eens.

Voor mij zou het belangrijk zijn:

  • man_made=oever mag niet direct verbonden zijn met een pad of weg. De bovenkant van het talud of het pad hebben een bepaalde breedte. man_made=embankment moet de rand markeren waar het horizontale oppervlak van de bovenkant van het talud overgaat in het hellende oppervlak van de helling.
  • Bijgevolg hoeft man_made=embankment niet altijd aan de rand van de weg of aan de rand van het grasland (landuse=meadow) te liggen. Soms is er geen pad op de top van de dijk, soms is de top van de dijk breder dan het pad/weg erop.

Ik zou polygonen (of zelfs multipolygonen) en de dijkranden aan de boven- en onderkant strikt van elkaar gescheiden laten. Het kan vaak gebeuren dat de teenlijnen op de randen van andere oppervlakken liggen, maar vaak ook niet. Het komt zelfs voor dat bijvoorbeeld landgebruik=weide zich uitstrekt over de dijk, de teenlijn en het aangrenzende oppervlak.

Nog een reden die tegen een (multi-)polygoon spreekt: in tegenstelling tot de dijkkruin en de teenlijn zijn de laterale grenzen van een dijk (bijvoorbeeld waar een dijk overgaat in natuurlijk terrein) vaak niet zo duidelijk herkenbaar.

Als u een dijk in zijn oppervlakte wilt vastleggen, moet u ofwel een preciezere definitie van man_made=dyke (samen met area=yes) of een relatie overwegen. Voor de positie van de kruin van de dijk zou man_made=embankment en voor de teenlijn een andere tag voldoende moeten zijn. De omvang direct aan een kustlijn of aan een natuurlijk=water zou sowieso moeilijk te bepalen moeten zijn, omdat het vaak niet mogelijk is om te bepalen waar de teenlijn (onder water) zich precies bevindt. Als een dijk direct aan een watergebied grenst, zou ik de teenlijn liever niet vastleggen.

Maar in principe, zoals je al weet, heb je mijn volledige steun. Ik heb nog veel dijken in mijn favoriete vakantiegebied aan de Oostzee (weliswaar op de voet gevolgd door Edam na mijn laatste vakantie) die ik graag gedetailleerder in kaart zou willen brengen.

Maar het belangrijkste zou zijn om een renderer te overtuigen om de teenlijn te renderen!