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.
1 Like
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
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)
2 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:
en
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
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?
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