[OSM-dev] Coastline, lakes, rivers

[Paweł Paprota]

Good idea but I think you will find that this is much harder task to
tackle from technical perspective and most people would rather work on
random projects like live viewers, mappers nearby and endless stream of
other gadges based on the basic replication stream...

On Mon, Apr 15, 2013, at 19:28, Sandor Seres wrote:
> I would like to suggest a bit more focus on the OSM source data related
> documentation and data quality. The many loose/fuzzy definitions (if they
> are definitions at all) allow wide freedom of interpretations. In turn,
> these interpretations are causing many (but really many) logical errors.
> As a rule these errors are constantly present in most of the OSM data
> based mapping systems. Of course in the reference Slippymap too.
> 
> Let me illustrate the former notes with just a few examples.
> 
> -The natural=water tag related Wiki description opens for many various
> interpretations (definitions by examples, as we know, present serious
> methodological errors). Even an area fragment of a larger water area
> might
> have this assigned. This is extensively used by editors to refine
> coastline sections, as well as lake and river banks. They create virtual
> "natural=water" objects, areas that slightly overlap for example a
> coastline section and have only a few long edges inside the larger water
> area. The logic is simple: to change a long coastline section is
> dangerous, so doing changes by smaller lakes is much less risky and the
> result is almost the same. But this is very wrong. As a result, the
> correction is just partly performed, many islands disappear (or if the
> borders are rendered, mystical/strange lines appear on top of the water)
> and a huge amount of data redundancy is added.
> 
> To see this, anyone can perform the following experiment: render/display
> the lakes area object layer using for example light blue for fill and
> black for the border lines. Render/display over this the planet_land area
> object layer (the land bodies created from the coastline data) using for
> example a yellow color fill and no borders. Now, if you pan along the
> coastline in an approprite scale, you will see lots of strange black-blue
> spots. When these are rendered in the opposite order, these will slightly
> and on certain places overwrite the coastline. In a way I could say that
> the coastline data based land-borders are actually never complete.
> 
> -The waterway=riverbank tag is used for presenting river section areas.
> Most of the rivers are still tagged and uploaded using this key/value
> pair. Though, in the "New tagging" section is a note that ".riverbanks
> aren't treated as areas any more." Here, it is quite legal to interpret
> the tag as a poly-line/way that represents a water/land border section.
> And this is used by editors very often. The consequences are, again, lots
> of logical errors. For example, look at the extract from the Slippymap,
> permalink:
> 
> http://www.openstreetmap.org/?lat=38.0542
> <http://www.openstreetmap.org/?lat=38.0542&lon=-121.5038&zoom=12&layers=M>
> &lon=-121.5038&zoom=12&layers=M
> 
> As you can see, only on this little extract there are many, many errors
> caused by the described misunderstanding (water as land, islands as
> water). There are many open polygonal line sections here, though
> connected
> properly to other area sections. And so on.
> 
> Of course a robust data-preparation process could coop with these kind of
> logical errors (I estimate that around 90% of all logical errors is
> resolvable programmatically). But this requires lot of unnecessary work.
> To refine the documentation should be much more pragmatic and effective.
> 
> Regards, Sandor. 
> 
>  
> 
>  
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev