[Tagging] Additional detail of Levee mapping via embankments

Joseph Eisenberg joseph.eisenberg at gmail.com
Wed Nov 13 07:48:13 UTC 2019

> I think there is a need for a basic relation, ... to simply associate the two lines ... When mapped, they are not joined

The easiest way to do this is to make an area which represents the
area of the cliff, embankment, dyke (levee) or whatnot.

Have it use the same nodes as the upper and lower ways in the case of
a cliff or one-sided embankment.

For a levee it can just go around the whole levee, in which case it
may not be necessary to map the edges with some other tag. The central
way with man_made=dyke will be associated with the area because it
will be entirely inside of it. (This would also work for cuttings or
railway embankments with two sides, if you want to map them as a
single area).

You can use a relation of type=multipolygon for this, as with any
area, but a closed way works just as well in most cases, and is
probably easier to map and maintain.

This is better than creating a new type of relation, and provides all
the information that a database user might want.

(But again, please consider that places like Tokyo have very high
quality Digital Elevation Models available, now often based on laser
readings which are accurate within decimeters, so if the goal is to
create a 3D map of the surface or contour lines or shading for a map,
this is not really necessary.)

- Joseph Eisenberg

On 11/13/19, John Willis via Tagging <tagging at openstreetmap.org> wrote:
>> On Nov 13, 2019, at 3:44 AM, Richard <ricoz.osm at gmail.com> wrote:
>> We need new tags for the bottom of embankmets, top of cuttings, bottom of
>> cliffs, earth_banks
>> and maybe a few others if we want to map them.
> that is very true.
> I think we can cleanly do this with the ways you mentioned.
> We need to chose a scheme for these “base” tags that doesn’t reinvent the
> wheel, isn’t vague, and can easily be interpreted. my mis-reading of
> embankment led to some big problems, simply because I assumed the tag could
> document things it couldn’t.  Your tags look really good to me.
>> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer <dieterdreist at gmail.com>
>> wrote:
>>  A relation seems easier to evaluate and explicit, while a spatial query
>> heuristic will inevitably fail in some cases
> I think there is a need for a basic relation, if I understand Martin
> correctly, to simply associate the two lines, (for example, an =embankment
> and an =embankment_base pair). When mapped, they are not joined. They are
> merely adjacent. I am not sure of what “type” of relation to choose in iD,
> but I assume someone will tell us which type to use.
> When mapping a simple cutting or embankment, you would have only one “base”
> line adjacent - so there is little ambiguity, and the relationship can be
> inferred (IIUC), but in complicated tagging, there could easily be a
> situation where which base belongs to which line is unclear, and lead to
> problems.
> Simply putting them into a relation says “these members are related” and the
> renderer can know for certain that these two ways that don’t share nodes are
> a pair, no inference needed.
> This again raises the question of levees - is the levee worthy of it’s own
> levee relation? do you put all 4 embankment lines into relation with the
> man_made=dyke line? this seems to be the only solution to:
> - properly group the embankments with the levee
> - not have to use super=relations (putting the embankment relations into a
> levee relation)
> - providing the most flexibility to weird situations
> - allowing for the extent of the top of the levee to be defined (large
> levees have varying width tops with usable areas, as shown, in which a “way”
> is insufficient ).
> But I am unsure that this is the “only way” and perhaps putting the two
> embankment relations + dyke line into a levee super-relation would allow
> mapping of the embankments to be a uniform process (making mapping the
> details of levees a bit more complicated at the expense of standardized
> embankment mapping).
> Javbw
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

More information about the Tagging mailing list