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.
- 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.
