Ik heb hier veertien kilometer dijk gemapt van twee embankments. Dus het kan wel 
1 Like
Volgens mij zijn we het best op hoofdlijnen met elkaar eens, maar gebruiken we de termen anders 
Als ik je goed begrijp dan bedoel je hier met “een” (1 ) dijk het geheel aan weerszijden van het water toch? (dus het water ligt in een verhoogde bak) .
Ik snap dat het zo overkomt, en een beeld op de hoogtekaart kan ook zo’n beeld geven, maar zo ontstaat denk ik wel spraakverwarring.
De gebruikelijke omvang van die term dijk zoals gebruikt door het waterschap (en hier ook door Stefan en mij) is het werk aan één kant van het water, zoals in het aangehaalde schematische plaatje.
Om een concreet voorbeeld te geven: de aanblik van zo’n verhoogde bak in het landschap met in die bak een “greppel” met daarin water heb je ook bij de ringvaart van de Haarlemmermeerpolder. Zie AHN:
Als je op de daar geldende legger klikt dan zie je ook dat de werken (dijken) aan weerszijde een andere naam hebben, die samenhangt met de polder die ze omringen (en bij de lange ringdijk van de Haarlemmermeer ook deelnamen).
In dit voorbeeld links van het water: naam = Rooversbroekpolder, rechts van het water: Lisserdijk.
Die dijk van de Rooversbroekpolder (of wat daar eerder voor door moest gaan, erosie was nogal een probleem toen) is er ook al langer dan de dijk van de Haarlemmermeerpolder, aan de oostkant van die dijk lag -simpel gezegd- eerst een enorm plas water.
Rond 1850 hebben ze daarin een groot eiland gemaakt dat we nu de Haarlemmermeerpolder noemen.
(voorbeeld topotijdreis ,even verderop bij Hillegom is het duidelijker te zien)
De dijk van die Haarlemmermeerpolder ligt vlak tegenover de dijk van de Rooversbroekpolder (2 dijken dus) en nu lijkt die vaart -het restant van het Haarlemmermeer- inderdaad in een verhoogde bak te liggen. Maar feitelijk is het het land in de beide polders (de door ontwatering ingeklonken Roovershoekpolder links en de bodem van het Haarlemmermeer rechts) dat lager ligt, elk op hun eigen -onafhankelijke- niveau.
En verder eens hoor, het binnentalud map ik zelf normaal gesproken ook maar zelden, alleen als er echt duidelijk herkenbaar landschapskenmerk is; een knik in het landschap en een flinke helling.
Bij het voorbeeld van @Cartographer10 van eerder werk van mij wist ik dan ook wel vrijwel zeker gelijk om welke dijk het ging. Maar als iemand werk wil maken van het mappen van duidelijk herkenbare taluds van slootkanten, dan vind ik dat dat ook moet kunnen binnen de daarvoor beschreven tags en werkwijzen.
Vandaag ook een fors talud tegengekomen tijdens het wandelen, ook een interessant geval, de afbakening van het talud was herkenbaarder dan die van de kruin
1 Like
Ha ja, het eeuwenoude probleem van de kartografie: hoe meer je uit zoomt, hoe meer je moet generaliseren…
Wegen zouden dus eigenlijk twee geometrieen moeten hebben: 1 vlak om aan te geven waar de werkelijke grens van de verharding ligt, en 1 lijn voor gebruik in netwerkanalyses (routes) en weergave op kleinere schaalnivo’s (vergelijkbaar met de LoD’s van de 3D- en BIM-gegevensmodellen). Maar er zijn niet veel (kaart-)applicaties die daar goed mee om kunnen gaan.
Daarom lijkt mij het beste als de situatie ter plekke als leidraad genomen word: is de onderkant van het talud ook al aangegeven (min of meer) door iets anders (zoals een weg of zo), dan laat je 'm weg, is er niks dat de onderkant aangeeft in de buurt, dan teken je 'm. Want er zijn echt wel plekken waar het toegevoegde waarde heeft, naar mijn mening.
1 Like
Eens met @Stefan_Jager ; OSM is een geografische database voor meerdere doeleinden; het kunnen maken van kaarten op de meest uiteenlopende schalen (de naamgever van het project), maar zeker ook routeren en data-analyse.
En bij het mappen is het wel goed om rekening te houden met fundamentele / niet goed oplosbare renderingsproblemen waar we kaartenmakers mee opzadelen (zo is bijvoorbeeld width=* op lijnelement voor een (water)weg geen alternatief voor een vlak: dat kan bijvoorbeeld immers niet het verloop van de breedte en bochten goed aangeven) . Maar tegelijkertijd moeten we ons ook niet blindstaren op de huidige werkwijze van specifieke renderers, zoals OSM Standard Carto.
Die renderer geeft bijvoorbeeld een ingestemde tag als highway=busway niet weer.
Nu is dat wel een herinnering om heel bewust om te gaan met het vervangen van bestaande waarden door nieuwe waarden (en zeker om niet samenhangende data, zoals access=* te verwijderen vanuit de veronderstelling dat alle datagebruikers wel weten wat er allemaal wordt bedoeld met die nieuwe tag), maar de weigering van carto om busway te renderen is op zichzelf geen veto op het gebruik daarvan.
En wat de taluds betreft: als iemand serieus taluds wil gaan mappen, dan hoef je ook niet te laten omdat er ook een weg loopt, als je wilt weten in de data waar taluds liggen, dan wil je daarop kunnen zoeken, en niet naar al dan niet samenhangende andere data zoals wegen. Als de herkenbaarheid het talud op deel deel beperkt is, dan is dat iets om in de talud-data op te lossen. Bij highways hebben we bijvoorbeeld ook visibility=*
1 Like
Ik merk dat ik niet alleen aan water denk maar ook aan spoordijken, dijken die alleen maar dienen om een weg te verhogen, de geluidwal-dijk waar ik eerder mee kwam, kortom een dijk is dan niet alleen een eenzijdige waterkering maar een tweezijdig ding dat iets draagt. Dijken (zonder vaart of spoor erop) tussen polders, zie ik ook niet als tweezijdig. Maar als je dijk als waterkering ziet, en vanuit het waterschap zie je dat natuurlijk zo, dan zijn er geregeld twee tegen elkaar aan, waar ik er dan één groot dijklichaam zie met wat strukturen ingebed. Maar dat hoeft de pret verder niet te drukken! Stel dat mijn ringvaart dieper lag, zeg drie meter of zo, dan zie ik als eenvoudige mapper ook aan beide zijden een kruin en twee taluds. Als er een getijdenrivier is met aan beide zijden laaggelegen polders, dan hoor je mij niet zeggen dat de rivier in één dijk ligt!
Misschien moeten we ook niet zozeer in termen van een dijk denken, maar in termen van een talud?
Een dijk heeft er dan meestal 2, maar niet altijd, afhankelijk van de situatie.
De streetview die ik eerder deelde (van De Haukes), daar is het aan de kant van de jachthaven duidelijk een dijk met aan twee kanten een talud, maar omdat het land achter de dijk omhoog loopt, is dat aan de kant vanwaar ik de streetview deelde geen dijk meer, maar een talud vanaf het maaiveld. Is goed te zien op AHN:
Eens. Ik heb wel wat moeite met het gebruik van embankment als lijn voor de voetlijn van het talud.
Aan de voorgestelde renderingen en de formulering in de wiki kan je aflezen dat het bedoeld is om aan te geven waar de boel naar beneden gaat lopen. Rechts van de lijn is de helling omlaag, links is het min of meer vlakke bovendeel. Dat vind ik toch echt wat anders dan rechts vlak en links omhoog of andersom. Volgens de wiki is rechts het lage deel, dus onderaan is dat het vlakke deel onder het talud. In principe staat die lijn los, want er ligt nergens een verband vast met een kruinkantlijn. Dan zou je toch moeten konkluderen dat er bij die lijn een (nieuwe) helling omlaag begint?
Ik denk dat je daarom toch een andere tag nodig hebt voor de onderlijn van het dijktalud, als je die wil taggen.
Eens, er zou eigenlijk een tag voor onderkant talud moeten zijn, die je ook aan wegen, water, paden enzovoorts kan toevoegen. Dat zou de meeste situaties wel kunnen oplossen, denk ik.
Hoe dan?
Het is toch duidelijk dat man_made=embankment de bovenkant aangeeft net zoals
Voor de onderkant hebben we geen tag. Nog niet.
We zouden gewoon embankment_toe kunnen gebruiken. Embankment toe schijnt de Engelse term daarvoor te zijn. Als er een duidelijke toe is dan is dat altijd kunstmatig, dus man_made=embankment_toe is mijn voorstel.
Als we een paar mooie voorbeeldsituaties hebben waarin we dat taggen, kan iemand misschien een voorbeeldrendering maken die we aan data users kunnen voorleggen. O ja, misschien ergens een RFC inschieten. Wil ik wel doen, maar niet zonder voorbeelden,anders krijg je duizend mensen die het niet begrijpen (niet iedereen kent onze polders) en daarom tegen zijn.
1 Like
Wat ga je doen met man_made=reinforced_slope? Hoe past dat in het plaatje.
Het is vaak een onderdeel van een dijk, terwijl man_made een basis key is en dus geen onderdeel “van” kan zijn.
Als vlak slope=* yes, talud zou een schaduwwerking kunnen geven, embankment aan de bovenkant.
Is dan ook te gebruiken bij het talud van een water, zonder embankment. slope=ditch als onderdeel van de sloot, insteek tot waterdragend deel.
Als de reinforced slope de hele embankment is, zou ik alleen dat taggen. Meestal is de kruin hoger, denk ik, dan zou je beide kunnen aangeven. Onderkant net zo: als de reinforced slope tot aan de toe reikt, geen aparte toe-lijn, en anders kan je het wel aangeven (indien nodig en mogelijk; meestal heb je dan een waterlijn of een wetland, denk ik).
Dat zou een vlak moeten zijn wat meerdere landuses/naturals kan omvatten. Je zou dan ook altijd allebei moeten weten, bovenlijn én onderlijn, terwijl ik denk dat je vaak maar 1 van de twee hebt. Het is ook te algemeen, denk ik. Ik denk dat je dan een heel erg versnipperd gebruik krijgt, voor allerlei heuvelachtige dingen, met eeuwige diskussies over de onderkant en de bovenkant. En je zit de hillshade/hoogtelijn-toevoegingen in de weg.
Ik zou liever puur het Nederlandse dijkengeval oplossen met eenvoudige dijkgerelateerde elementen. De bovenkant is geregeld met man_made=embankment. De onderkant nog niet, dus dat kan toegevoegd worden. Overal waar embankments een duidelijke onderkant hebben, is het ook bruikbaar. Zoals bij het wiki-plaatje van een embankment die tegen een berghelling ligt om de weg te dragen, daar zou je dus ook de onderkant kunnen aangeven. Bij de Via Tremola zou dat een heel aardig effect geven, in een stijl die de weg niet zo overbenadrukt dan. Slope werkt daar niet, omdat alles slope is.
De embankment zoals die nu wordt gerenderd is een vectorbestand, een .svg, met de naam embankment.svg. Op alle zoomniveaus waar dat bestand te zien is wordt dezelfde svg neergezet zonder hem te schalen.
Voor een eigen kaartje ben ik even aan het experimenteren, ik heb daartoe alleen de .svg een beetje aangepast en dat ziet nu zo uit op zoomniveau 17. Een teen (onderkant talud) heb ik nog niet.
Fort Hazepoot met teen op de svg. Meteen is te zien dat het niet klopt want op deze manier is de horizontale afstand kruin-teen vast en in de werkelijkheid is dat niet zo.
Dat is niet OSM Carto toch? BIj bij ziet een embankment (twee, en niks ertussen want losse dijk die niks draagt) er zo uit:
Zo ziet hij er in JOSM uit, daar klopt die svg wel mee:
De ene teen (het schaduw-talud) is goed te zien en ligt enkele meters naast de Maatveldse weg. De andere (het lichte talud) is wat meer wisselend van breedte en op delen wat minder goed af te grenzen
Met een niet schalende svg voor alleen de kruinlijn ga je die teen niet goed kunnen weergeven voor allerlei situaties. Je zal toch echt een aparte teen-lijn daarvoor moeten mappen en renderen.
Ik zat te denken, in principe zou je hier een multipolygon met meerdere verschillende outer lijnstukken kunnen gebruiken. Je hebt een bovenlijn, een onderlijn, een dalende lijn en een stijgende lijn (rollen?), en die samen vormen de polygon die het talud beschrijft. Dan kun je er ook nog een landuse of een natural aan hangen, en je kan zelfs bv een stuk water, bos of reinforced slope binnen het talud geven als inner. En je kan er een naam aan geven.
De bovenlijn kan dan ook een weg-segment zijn, want in een multipolygon mag de outer samengesteld zijn uit (segmenten van) verschillende ways.
Een vlak (bv water) als begrenzing kan niet, of wacht… ja, als je het watervlak zelf ook als multipolygoon met een samengestelde outer uitvoert.
Jawel maar thuis gerenderd. Om eens wat te proberen.
Klopt, ik kan mijn eigen OSM renderen van mijn eigen JOSM-bestanden, of in dit geval Limburg dat ik heb gedownload van Geofabrik.
Ik meen dat ik deze handleiding heb gevolgd.
Op die manier kan ik experimenteren met de style zoals in dit geval wat gehannes met de embankment.
Maar ik kan er ook allemaal Petertjes van maken. Kijk, in Arcen kennen ze je ook al
Gelukkig sta ik met mijn voeten naar beneden.
Niemand hier een gedachte over?
Je mapt dan het komplete talud als vlak, je kunt het vlak eigenschappen geven, je kunt de afzonderlijke randen eigenschappen geven (en ook bestaande lijnen gebruiken als rand), en je kunt dingen in of op het talud uitsparen als inner.
Een renderer zou wat kunnen met de afzonderlijke lijnen, maar ook met het taludvlak. Een verlopende kleur of grijstint over het hele vlak is misschien wat veel gevraagd, maar een schaduwwerking gebonden aan de lijnen zou moeten kunnen denk ik?
Nog even wat cijfers opgezocht: er is bijna 18.000 kilometer waterkerende dijk in Nederland. Daar zijn dan wel de vrijliggende dijken (slapers, dromers, en tussenpolderdijken meegeteld). Voor spoordijken en dergelijke heb ik geen aantal gevonden, maar een paar duizend Km zal het zeker zijn. Als je in Kilometers taluds rekent kom je nog hoger.
Dijken zijn in grote delen van het land wel enorm beeldbepalend in het landschap, dat mag ook best op kaarten zichtbaar worden.
1 Like