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
_______________________________________________
dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/dev
