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@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
