[Tagging] [OSM-dev] Coastline generalization tool and data

[Martin Koppenhoefer]

pulling this from dev to tagging


2013/2/11 Christoph Hormann <chris_hormann at gmx.de>:
> You might notice various strange forms in the coastline at some places,
> most of them are caused by features being tagged as coastline which in
> fact should probably not be.  I put up a wiki page [5] to collect these
> problems.  If you find more or fix them feel free to edit that.
> [5]
> http://wiki.openstreetmap.org/wiki/User:Imagico/coastline_problems_for_generalization


I had a look on the examples, the first one is the Suez canal.

What I found strange is that the southern part is closed while the
northern isn't (i.e. in the south there would be an overlapping
coastline, which probably shouldn't occur).

But: it is an open (i.e. there are no locks) connection between the
Mediterranean Sea and the Red Sea with saline water. It is not a
natural feature, ok, but isn't it still a coastline?

This is also an example for a common problem:

there are 2 relations where this way belongs to:
http://www.openstreetmap.org/browse/way/97208606   // has no meaningful tags

http://www.openstreetmap.org/browse/relation/1410016  // with the
following tags:
is_in = Egypt, جمهورية مصر العربية
various name tags  (name:en = Great Bitter Lake)
natural = water
type = multipolygon
3 redundant (because interlinked) language-specific wikipedia tags


http://www.openstreetmap.org/browse/relation/1211874  // has no tags
which really tell what this is:
boat = yes   // attribute
man_made = yes   // attribute
name = Suez Canal  // probably not the local language, but that's not
my point here
various other name tags
type = canal   //  undocumented relation type

shouldn't there be some tag to say what kind of object this second
relation is, e.g. natural=water or natural=coastline or
waterway=riverbank?

But then you would get 2 overlapping water areas because also the
other relation (above) has a natural=water tag (maybe this is not a
problem?). I don't think you can safely asume that this relation
inherits the kind of object from one of its members.

This kind of problem also occurs in other contexts, e.g. a forest with
a name which is part of a bigger forest (with a different name).
Currently as far as I have seen this on the map there is mostly
tagging for the renderer (one object only gets the name, while the
other gets the forest-tag and the name). But this way you don't know
what kind of object is the one with just the name.

This could be resolved if we had a clear distinction of physical
objects and logical objects, e.g. a tag that says: this is a "forest"
and it has the name foo, this is another forest and it has the name
bar (and foo and bar could well overlap), while you would have another
tag that says: here are growing trees (because you cannot asume that
inside the polygon that is commonly called "forest foo" there will be
trees everywhere, e.g. there could be a lake in the forest, and still
this lake could be considered "in the forest, part of the forest" so
excluding it with a multipolygon inner role from the logical (named)
forest would be wrong). In my interpretation, the named, logical
object forest would be tagged with the key "natural" while the second
object (here trees) could be landcover.

cheers,
Martin