De diskussie in de algemen tagging kategorie is wel zo’n beetje uitgewoed. Ik heb een aardig idee gekregen hoe de hazen lopen, en misschien wil ik wel een voorstel doen.
Maar eerst nog een vraag: we hebben als te mappen onderdelen van dijken nu de kruin, het talud/de taluds, en de teen. Dat is niet heel uitgebreid. De doorsneden laten veel meer onderdelen en namen zien. Mijn vraag: als je supervolledig gaat micromappen, welke onderdelen van dijken zou je dan nog apart willen kunnen mappen?
Als eerste het vlak van de dijk.
Wat is de gehele dijk?
Beschermingszone met kenmerkende profiellijnen, waar meerdere binnenteen-, buitenteenlijnen benoemd zijn.
Deels teenlijnen op de image, het benoemen kan een eigen keuze zijn.
Vlakken:
Schijnbaar zit onder het groen tussen weg en fietspad, asfalt.
grasvlakken intekeningslijnen.
Andere plaatsen:
Verspringing van de dijk, tevens akkerbouw op de dijk.
Bij aansluitingen en activiteiten binnen- buitendijks:
Wat behoort er tot de dijk.
Bij buitendijkse bebouwing:
OGC open data met images, gebruikt in bovenstaande voorbeelden.
Onderdelen op en rond de dijk.
Op kantoor van een Waterschap, een specialist:
De dijk, van buitenste buitenteenlijn, vlakke bodem in het water, waar de verkanting enigszins begint, tot midden kwelsloot aan de andere kant.
Tot zo ver, wat ik al eerder had bekeken, zoektocht naar ligging en wat men gebruikt.
En zou je al deze dingen apart willen kunnen taggen? Zo nee, wat zijn de belangrijkste, voor bv een algemene kaart waarop de dijken tot uiting komen?
Over het totale dijkvlak: als je de kruin en de taluds en de teen/tenen aangeeft, dek je dan het hele dijkvlak, of nog niet? Zou je zoiets willen als landuse=embankment, vgl landuse=railway?
Wb de buitenzijde, wat er onder de OSM-waterlijn ligt zou ik zelf nooit apart intekenen. Ik breng het zichtbare landschap in kaart. Maar misschien is het bij wisselende waterstanden juist wel goed om te kunnen zien waar de buitenteen is als het water laag staat.
Wb bedekking/landcover/versterking/landuse bv weiland voor schapen, daar zijn allemaal al tags en objecten voor, dat hoeft MI niet apart voor dijken nog een keer apart gemapt te worden.
Een plateau op/aan de kruin of op/aan het binnen- of buitentalud, dat kan allemaal met eigen landuse en kruin/teen/talud-mapping ingepast worden. Vaktermen hoef je MI daar niet voor te gebruiken; als je wil vastleggen dat bv een landuse=industrial in feite op de dijk ligt, dan zou je het kunnen bijtaggen met embankment=yes. Net als bij een weg over de dijk. Of je trekt de kruinlijn eromheen, meestal zal er wel wat afstand zitten tussen de bedrijfsgebouwen en de rand.
Deze dingen gaan allemaal veel te ver, denk ik. Zichtbare taluds aan kunnen geven is voldoende. Een dijk als geheel lijkt me veel te ver gaan. Bovendien zijn er plekken waar een dijk aan de ene kant verdwijnt, maar het talud aan de andere kant is er nog.
Naar mijn mening zou het voldoende zijn als we een talud kunnen vastleggen door middel van een bovenkant en onderkant (datamodeltechnisch zou dat een vlak kunnen zijn - zou ook met twee lijnen kunnen, maar dan zou je idealiter wel een relatie tussen die twee lijnen willen vastleggen). En als dat daarna ook nog op een mooie manier word opgepakt door renderers (het kartografische probleem), dan zou dat helemaal mooi zijn (bijvoorbeeld door de lijntjes zoals in de aloude vertrouwde GBKN…).
Maar alle gegevens die een waterschap over een dijk wil weten, moet je mijns insziens niet in Openstreetmap zetten. De funderingen en pylonen en dergelijke van viaducten worden toch ook niet gemapped?
Ok het is nu een tijdje stil, ik neem aan dat voor nu alles gezegd is. Ik ga een voorstel maken dat naar ik hoop recht doet aan de diskussie hier en in het engelstalige onderwerp.
Alles overziende denk ik dat ik het zo eenvouig mogelijk ga houden. Hoewel ik dijken heel belangrijk vind snap ik ook dat men internationaal er veel minder gevoel voor heeft. Velen kunnen het zich toch niet goed voorstellen, maar voor een approval moet ik ze toch meekrijgen.
Het voorstel richt zich op alle embankments, dus niet alleen zeedijken, rivierdijken en polderdijken, maar ook spoordijken, wegondersteuningen tegen berghellingen, verhogingen onder wegen, geluidswallen, en zelfs de “dijkjes” op het marinecomplex in Den Helder. Oftewel, alles waar nu man_made=embankment voor gebruikt wordt, zodat er volledige backward compatibility is. Wie niks verandert in de data, ziet ook niks veranderen in de rendering, en renderers die niks doen lopen niet vast of zo.
Wie wil profiteren van de uitgebreidere mapping zal wel iets moeten doen, maar ik denk dat dat wel de moeite waard zal zijn. Iets voor een challenge?
Zelf vind ik het onderwerp niet zo groot dat ik er een heel subsysteem voor zou taggen. Zoals bv power=*
En ook geen nieuwe hoofdtag, want dat zou leiden tot dubbeltagging en deprecation van een best veel gebruikte tag. Voor het mappen van allerlei bizondere delen van grote dijken wil ik daarom alleen ruimte in de naamgeving van de values bieden, maar zelf geen voorstellen doen.
Ik wil wel gelijk de mogelijkheid meenemen om het dijklichaam als een area te mappen, zodat je eigenschappen kan meegeven die normaal gesproken bij een area horen. MI is het momenteel praktisch niet werkbaar om uit twee ways die samen geen area zijn, in de code een area af te leiden. Daarvoor is het nodig om expliciet een area te mappen.
Dus (spoiler!) mijn voorstel wordt:
man_made=embankment:crest - De bovenrand van het talud.
Staat gelijk aan het meeste man_made=embankment-gebruik nu, en wordt aangenomen als synoniem voor de bulk van de installed base. Mag een closed way zijn, bij een losstaande wal (bv geluidswal).
man_made=embankment:toe - De onderrand van het talud.
Mag een closed way zijn (bv bij losstaande geluidswal)
man_made=embankment:slope - Het talud als oppervlak.
Moet een multipolygon zijn, omdat minimaal de embankment:crest lijn er als gedeeltelijke outline inzit, naast optioneel de embankment:toe en de lijn(en) om de outline te sluiten.
Er worden geen aannames gedaan over wat precies onder embankment verstaan moet worden of wat het officieel is. Het kan gebruikt worden voor een komplete dijk, of voor een deel van een dijk, wal of wegondersteuning. Net als bv bij water kan de mapper bepalen hoeveel zhij tegelijk mapt , komplete taluds of liever een paar kleinere delen die tegen elkaar aanliggen.
De ruimte voor eventuele speciale onderdelen zit in de naamgevingsruimte embankment:*
Tot nu toe heeft niemand onderdelen genoemd die zhij afzonderlijk gemapt zou willen zien.
PS embankment=yes|dyke|… blijft ook gewoon behouden, voor eenvoudige gevallen waarin je alleen wil aangeven: deze weg of lijn ligt op een dijk/wal/verhoging. Het voordeel daarvan is vooral dat de weg bij uitzoemen niet over de kroonlijn heen gaat vallen.
sorry, dass ich heute auf die Schnelle nur auf Deutsch antworte.
Du hast meine volle Unterstützung!
Nur eine Frage: in welchem Sinn soll man_made=embankment weiterhin verwendet werden?
Beziehungsweise: wenn jetzt schon man_made=embankment in den meisten Fällen die obere Böschungskante (crest) abbildet, soll dann an der gleichen Linie zusätzlich man_made=embankment:crest ergänzt werden?
PS:
Ich fürchte, der Doppelpunkt im value passt nicht wirklich in das OSM-Datenmodell. Vielleicht ist es besser:
man_made=embankment_crest
man_made=embankment_toe
man_made=embankment_slope
Danke für die Unterstützung!
In diesem Fall muss man nichts tun, man kann aber das neue Tag anstelle des alten verwenden.
Ich glaube nicht, dass das Datenmodell etwas darüber aussagt. Der Doppelpunkt ist in Namensräumen üblich als Trennzeichen. Aber es macht mir wenig aus; ein Value ist sowieso nur ein String.
Ich kenne aber bislang Namensräume nur beim key, nicht beim value.
Auf die Gefahr hin, dass der eine oder andere Renderer erst einmal gar kein embankment mehr rendert …
Was denkst Du: Haben wir ein Ergebnis, bis ich im Sommer Amsterdam und Edam besuchen komme? Dann könnte ich gleich etwas mappen …
Unbekannt macht unbeliebt? Warten wir auf den RFC!
Ich denke, die Mapper warten darauf, dass der Renderer das neue Tag rendert.
Das wäre schön, und willkommen!
Als je al een vlak man_made=dyke hebt, kan je voor de slopes niet weer man_made= …“embankment” gebruiken, er is maar 1 element , de dijk. En geen andere met man_made.
Het tegenovergestelde is cutting_crest.
Waarom kan de value geen *=crest *=toe *=slope *=berm zijn?
dyke=crest?
op andere plaatsen embankment=crest.
Is het dan ook voor cutting te gebruiken?
Zo denk ik ook aan de insteek van een slootkant.
If the primary function of an artificially raised ridge is protection from flooding you should use man_made=dyke to indicate that.
Dus met andere woorden is het een dijk benoem het als een dijk. Benoem het dan niet als een andere man_made, man_made is een basis key.
Als wat jij wilt, dan hoort de tag ook in dit lijstje te staan. Wat verkeerd is. Je gaat geen onderdelen van een geheel in dit lijstje zetten, dat gebeurd ook niet bij andere in dit lijstje.
Het gebruiken van man_made is voor dit doel niet geschikt.
Dat wordt ook hier aangegeven
Some of the ambiguities with man_made=embankment include:
- the word used in the OSM-value for man_made=embankment typically refers to the embankment as a whole (sloping parts and the crest),
embankment , dyke, cutting als key kan wel worden gebruikt.
Vandaar beter een value dat elders ook toepasbaar is.
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.
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
wfs DTB vlakken met omschrijving
wms DTB visualisatrie lijnen over luchtfoto
wms DTB vlakken over Openstreetmap
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.
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)
