Ah, GSHHG 3 … thanks for clarification! I really had no clue.
Yep, GSHHG3 is ultimately the better but even with shapes we should be able to do better. I hate the waste of shapefiles (doubles only, when doubles are hardly ever needed) but the fact that it’s an index format should be useful for this. Unfortunately I tried ogr2ogr -spat, (similar to -R...) and it didn’t work for the Cabo Verde example (that is, for the bounding box around the archipelago). To clarify, I was expecting a fast extract of the needed polygons.
Since it is apparently a GIS “thing” to take the Antarctica polar cap polygon and make its shoreline take a rapid detour via the south pole, spin around 180 and streak back up to the same point, you will need to remove this fake data (~360 points) before plotting with GMT. Some awk-ing revealed this to work well:
awk '{ if (NR < 17753931 || NR > 17754314) print $0}' landpoly_osm.gmt | gmt convert -bo2f -fg > landpoly_osm.bf2
@pwessel if I understand it correctly you are basically counting the numbers of records and dropping some (the roundtrip to the South Pole) based on those numbers.
In my mind this only works with this exact version of the source file: If something on the coastline is changed by a OSM contributor the source file number of records will change as well and something unrelated will be removed by your command.
While this works nicely for the current source file it seems not terribly future proof. Maybe you have another trick up your sleeve?
You are absolutely right. I am not sure how easy it is to write a script to do the general case though. For our (eventual) C-professing of this data to GSHHG3 we will do it in C-code.
Since you did find the OSM files, would you know if (or how) we may get lake polygons? It seems they are not making shapefiles for that so one may have to deal with the entire OSM database…
To my knowledge there is no shape file readily downloadable for water polygons that are not oceans or seas. Most probably because this is a bit like opening Pandora’s box.
Your main problem will be tagging convention and tagging quality if you want to differentiate between lakes and rivers and exclude manmade structures such as irrigation ponds etc.
Lakes are somewhat easy. Have a look at the tag natural=water and the key water=lake. According to OSM, natural=water applies to “any body of water, from natural such as a lake or pond to artificial like moat or canal” but not rivers. This can be a problem for example with the large rivers of South America and their wast surface areas.
When you are interested in OSM rivers (good introduction) you are in for some fun. There is a multitude of ways in which they can be mapped. Just looking at the waterway=riverbank tag which is mostly used for “large rivers, or sections of a river which are wide enough to “require” mapping of distinct areas of water/river banks” gave me a headache.
You have to wrangle planet.osm by yourself (the mirrors are usually faster). The planet is pretty bulky at a good 86 GB when using the XML variant and still a bit unwieldy with a good 50 GB when using the smaller .pbf format.
You most probably knew this already but GDAL supports working with OSM .pbf files. I haven’t tried it myself so far. I experimented with QGIS (GUI) which was totally overwhelmed by the planet and Osmium (command line) which held up better to the planet. Unfortunately my experimentation led nowhere. Mainly due to the lack of knowledge on my part.
The site https://osmcode.org may be of interest as well. They have a C++ library for working with OSM data.
@leouieda did you get my private message about contributing to the GMT Docs?
As users are occasionally redirected here to learn about the problems with GSHHG and SRTMGL1 I feel it would be beneficial to have a direct link to the example in the gallery:
Example 51: OpenStreetMap coastlines in GMT
There the workflow is explained in detail and there is no need to crawl trough this whole thread and piece it together by yourself.
4 Likes