Coastline – osm2pgsql

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

 


_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Coastline – osm2pgsql

Sven Geggus
SandorS <[hidden email]> wrote:

> As I understand the two involved processes are independent and the results
> are just mixed together at certain moment during the map-making process.

Right.

The main reason for doing this is, that coastlines tend to be broken very
often. Likely they are broken more often than they are actually usable.

Thus it has been decided a long time ago, that land polygons are rendered from
shapefiles proven to be mostly correct (e.g. all continents do exist) and
up-to-date stuff produced by osm2pgsql.

If you like to render your own map you can easily produse matching data from
the same planet file.

The coastline processing toolchain is available here:
https://github.com/osmcode/osmcoastline

Regards

Sven


--
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Coastline – osm2pgsql

dieterdreist
2018-06-21 0:05 GMT+02:00 Sven Geggus <[hidden email]>:

The coastline processing toolchain is available here:
https://github.com/osmcode/osmcoastline


you can also get precompiled (fixed, splitted and not, 4326 and 900913) water polygons, land polygons and coastline shapefiles here:

Cheers,
Martin

_______________________________________________
dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/dev