genericmappingtools / gshhg-gmt Goto Github PK

I was extracting information from gshhg v2.3.7 and ran across 4 distinct values for source:

source code with count

W: 179825
C: 8058
A: 673
c: 56

Commands I used to obtain those numbers:

gmt gshhg gshhs_f.b | grep '>' | tr -s ' ' | cut -d ' ' -f5 | grep W  | wc
gmt gshhg gshhs_f.b | grep '>' | tr -s ' ' | cut -d ' ' -f5 | grep C  | wc
gmt gshhg gshhs_f.b | grep '>' | tr -s ' ' | cut -d ' ' -f5 | grep A  | wc
gmt gshhg gshhs_f.b | grep '>' | tr -s ' ' | cut -d ' ' -f5 | grep c  | wc

I found docs on this page: https://docs.generic-mapping-tools.org/latest/supplements/gshhg/gshhg.html

It says, "Source is either W (World Vector Shoreline) or C (CIA World Data Bank II)"

I found this page: https://www.soest.hawaii.edu/pwessel/gshhg/

It lists the sources as:

World Vector Shorelines (WVS).
CIA World Data Bank II (WDBII).
Atlas of the Cryosphere (AC).

So, I'm guessing that A means "Atlas of the Cryosphere". Anyone know what lowercase 'c' means? Is it the same as uppercase 'C'?

See GenericMappingTools/gmt#4032 for details.

In order to fix the border a should replace WDBII_Borders_Level_02.txt (in WDBII/borders/) with the new file, right?

There are longitude values in the range of [-180,360]. While not necessarily illegal, it's strange.

When I tried to run a query in MySQL 8 against the field that is of type POLYGON, I get an error:

A parameter of function st_contains contains a geometry with longitude 180.004972, which is out of range. It must be within (-180.000000, 180.000000].

I know this MySQL problem isn't a concern of this library, but I wanted to at least give others a heads up of the range of values and the problem they might encounter if they load the data.

Description of the desired feature
The Brazilian state of Tocantins was created on 1988, but its border is not included on GMT database. Is it possible to include it by default on pscoast command?

Thank you

Are you willing to help implement and maintain this feature? No

Some time ago (2 years) we implemented a scheme wherein GMT would try to download the GSHG data set from the GMT server if the data were not installed on the user's system. The files are current (2.3.7) and stored in a version-less directory /export/gmtserver/gmt/data/geography/gshhg. The process works fine but there is on problem:

1. We have no reminders or guidelines to update these files.

The same setup applies to DCW and here we are behind on the version. We need to document this process here so that the next GSHHG is also placed on the server in the same directory.

There is a gap in the border in northern sector of Portugal and Galicia. ca. 42 N along the coast. It can be seen in example 44.

Hello,

I am compiling data to document deglacial sea level changes in Greenland, and I noticed there is an error in the coastlines in GSHHG. I have illustrated this error by comparing the shorelines to the GEBCO 2021 topography dataset (the black lines are the GSHHG shorelines):

The red dots are locations where radiocarbon dated fossil shells and driftwood have been found in glacial isostatically uplifted marine and shoreline deposits. Many of these data were reported in a paper by Funder et al., 2011 (https://doi.org/10.1126/science.1202760). I asked Dr. Funder about this, and he said that the locations of data they collected were measured using GPS, so they are undoubtedly accurate. The map in the paper shows the correct shoreline positions.

At its worse, the coastline in GSHHG dataset is about 35 km from the (apparent) true location. This error also affects Google Earth. The georeferencing of the satellite imagery in Google Earth appears to have used GSHHG as a base. It appears that the coastline west of about 53W and south of about 78N is accurate

I have attached the script I used to create the above image (though you will have to download GEBCO separately).

test_greenland.zip