[OSM-dev] Coastline – osm2pgsql

[SandorS]

As I understand the two involved processes are independent and the results are just mixed together at certain moment during the map-making process. This independence causes several serious issues. Let me mention some. 
Assume the coastline polygons are in classes {Pi}, i=0,1,2, where any from {P0} is strictly outside any other polygons, while any from the class {Pj}, j>0, is strictly inside one and only one polygon from classes {Pk}, k<j. The number of {P1} and {P2} polygons is large and their distribution may be presented by markers like here https://goo.gl/zJ4vsz. The {Pj} polygons, with just a few exceptions, in most of the OSM based maps are rendered incorrectly.
Strictly taken, from the topology point of view, any of the polygons {P1} is a hole in one of the {P0} polygons no matter orientation or additional tags. Consequently, all these holes should be rendered by blue/water colour (at least up to the border of eventually enclosed P2 polygons) and should never be visible in OSM maps as islands (missing islands).
Some map-makers use the orientation of the hole polygons in rendering. What ever the result is, strictly taken it is wrong. The requirement “...the land is on the left side and the water is on the right side...” cannot be valid because these polygons are on/inside the land masses.
Other map-makers use the tag place=island/islet in rendering forcing the corresponding P1 polygons to land areas even if the requirement “...piece of land that is completely surrounded by water...” can not be valid because any P1 is in/on the land. By the way, the latest Wiki text related to the tag natural=land is just a confusing and out-watered version of the former document where the natural=land tag was declared obsolete and suggested “not to be used”. Now, it is absolutely legal to use natural=land tag on coastline islands though this is obviously redundant. What more, interpreting the tag place=island/islet as an area-qualifier makes it logically equivalent to the obsolete natural=land tag.
Basically  there are two possible ways to minimize the described erroneous consequences. 
1.Users, in their data preparation, should keep only the {P0} polygons for creating the coastline land (or water) masses. The rest of the coastline polygons should be merged to lakes or rivers related data for further processing.
2.Perform the procedure under 1. but as a one/time action directly in the OSM source data.
Finally, it is worth noting that the absolute number of issues/errors caused by the uncoordinated coastline and osm2pgsql processing large, it is relatively moderate. However, the case indicates that there is a whole class of issues/errors that is rarely discussed and highlighted. This class of errors is caused by independent updates and processing of different object classes/layers like lakes and rivers, rivers and forests, lakes and coastline, coastline and roads and so on. The number of these anomalies is six-ciphered and they are passing any publicly available error “detectors” and “inspectors” today without being detected. While many map-makers may tolerate these erroors (especially in the raster colour-image based mapping, after all the errors are just logical) the situation is quite different in the OSM based GIS systems and vector map-making. For illustration just look at the coastline and lakes mismatch here https://osm.org/go/cjf3ZjVB-?layers=D . Of cause, it is possible to find many explanations why this happens but these do not help. The errors are already there and they are there in many years. Sandor
If interested in more arguments, examples or details of correction models mentioned under 1 and 2, you may visit the white paper here https://goo.gl/ECKBGJ.
Sandor

Sent from Mail for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180612/43b235be/attachment.html>