{"id":22282144,"url":"https://github.com/genericmappingtools/gshhg-gmt","last_synced_at":"2025-07-28T20:31:55.820Z","repository":{"id":44912804,"uuid":"231486496","full_name":"GenericMappingTools/gshhg-gmt","owner":"GenericMappingTools","description":"Scripts and raw data that combine to produce the GSHHG data sets for GMT","archived":false,"fork":false,"pushed_at":"2022-06-17T21:42:20.000Z","size":175010,"stargazers_count":21,"open_issues_count":5,"forks_count":3,"subscribers_count":9,"default_branch":"master","last_synced_at":"2025-04-05T03:31:50.522Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"lgpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/GenericMappingTools.png","metadata":{"files":{"readme":"README.md","changelog":"ChangeLog","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-01-03T01:11:53.000Z","updated_at":"2025-02-11T00:44:52.000Z","dependencies_parsed_at":"2022-09-05T13:11:32.724Z","dependency_job_id":null,"html_url":"https://github.com/GenericMappingTools/gshhg-gmt","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/GenericMappingTools/gshhg-gmt","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GenericMappingTools%2Fgshhg-gmt","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GenericMappingTools%2Fgshhg-gmt/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GenericMappingTools%2Fgshhg-gmt/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GenericMappingTools%2Fgshhg-gmt/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/GenericMappingTools","download_url":"https://codeload.github.com/GenericMappingTools/gshhg-gmt/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GenericMappingTools%2Fgshhg-gmt/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":267580524,"owners_count":24110857,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-07-28T02:00:09.689Z","response_time":68,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-03T16:25:46.964Z","updated_at":"2025-07-28T20:31:55.421Z","avatar_url":"https://github.com/GenericMappingTools.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# GSHHG: Global Self-consistent Hierarchical High-resolution Geography\n\n![GitHub release (latest by date)](https://img.shields.io/github/v/release/GenericMappingTools/gshhg-gmt)\n![GitHub](https://img.shields.io/github/license/GenericMappingTools/gshhg-gmt)\n\nThis repository contains the data and scripts that maintain and build\nthe gmt-gshhg package used by GMT.\n\nGMT uses the [coast](https://docs.generic-mapping-tools.org/latest/coast.html)\nutility to access a version of the GSHHG data specially formatted for GMT.  The\nGSHHG data have strengths and weaknesses. It is global and open source, but is\nbased on relatively old datasets and hence may not be accurate enough for very\nlarge-scale mapping projects. The current GSHHG version used by GMT is 2.3.7. \nBelow is a mostly technical description of how the GSHHG data set was assembled,\nprocessed, and formatted to meet the requirements of GMT.\n\n\u003cp align=\"center\"\u003e\u003cimg alt=\"gshhg global map\" src=\"https://docs.generic-mapping-tools.org/6.2/_images/gshhg.jpg\" width=\"500\" /\u003e\u003c/p\u003e\n\n## Download\n\nYou can download the latest gshhg-gmt package from\n[GitHub releases](https://github.com/GenericMappingTools/gshhg-gmt)\nor from the [GMT main site](https://www.generic-mapping-tools.org/download/).\n\n## The five resolutions\n\nWe will demonstrate the power of this database by starting with a\nregional hemisphere map centered near Papua New Guinea and zoom in on a\nspecified point. The map regions will be specified in projected km from\nthe projection center, e.g., we may want the map to go from km to km in\nthe longitudinal and the latitudinal direction.\nAlso, as we zoom in on the projection center we want to draw the outline\nof the next map region on the plot. To do that we use the **-SJ** option\nin [plot](https://docs.generic-mapping-tools.org/latest/plothtml).\n\n### The crude resolution (**-Dc**)\n\nWe begin with an azimuthal equidistant map of the hemisphere centered on\n130°21'E, 0°12'S, which is slightly west of New Guinea, near the Strait of\nDampier. The edges of the map are all 9000 km true distance from the\nprojection center. At this scale (and for global maps) the crude\nresolution data will usually be adequate to capture the main geographic\nfeatures. To avoid cluttering the map with insignificant detail we only\nplot features (i.e., polygons) that exceed 500 km\u003csup\u003e2\u003c/sup\u003e in area.\nSmaller features would only occupy a few pixels on the plot and make the\nmap look \"dirty\". We also add national borders to the plot. The crude\ndatabase is heavily decimated and simplified by the DP-routine: The\ntotal file size of the coastlines, rivers, and borders database is only\n283 kbytes. The plot is produced by the script:\n\n\n    gmt begin GMT_App_K_1\n\t    gmt set GMT_THEME cookbook\n\t    gmt set MAP_GRID_CROSS_SIZE_PRIMARY 0  MAP_ANNOT_MIN_SPACING 0.3i \\\n\t        MAP_ANNOT_OBLIQUE lon_parallel,lat_horizontal,tick_normal\n\t    gmt coast -R-9000/9000/-9000/9000+uk -JE130.35/-0.2/3.5i -Dc \\\n\t\t    -A500 -Gburlywood -Sazure -Wthinnest -N1/thinnest,- -B20g20 -BWSne\n\t    echo 130.35 -0.2 | gmt plot -SJ-4000 -Wthicker\n    gmt end show\n\n\u003cp align=\"center\"\u003e\u003cimg alt=\"gshhg crude resolution global map\" src=\"https://docs.generic-mapping-tools.org/6.2/_images/GMT_App_K_1.png\" width=\"400\" /\u003e\u003c/p\u003e\n\nHere, we use the [MAP_ANNOT_OBLIQUE](https://docs.generic-mapping-tools.org/latest/gmt.conf.html#term-MAP_ANNOT_OBLIQUE)\nsetting to achieve horizontal annotations and set\n[MAP_ANNOT_MIN_SPACING](https://docs.generic-mapping-tools.org/latest/gmt.conf.html#term-MAP_ANNOT_MIN_SPACING)\nto suppress some longitudinal annotations near the S pole that otherwise would\noverprint. The square box indicates the outline of the next map.\n\n### The low resolution (**-Dl**)\n\nWe have now reduced the map area by zooming in on the map center. Now,\nthe edges of the map are all 2000 km true distance from the projection\ncenter. At this scale we choose the low resolution data that faithfully\nreproduce the dominant geographic features in the region. We cut back on\nminor features less than 100 km\u003csup\u003e2\u003c/sup\u003e in area. We still add\nnational borders to the plot. The low database is less decimated and\nsimplified by the DP-routine: The total file size of the coastlines,\nrivers, and borders combined grows to 907 kbytes; it is the default\nresolution in GMT. The plot is generated by the script:\n\n    gmt begin GMT_App_K_2\n\t    gmt set GMT_THEME cookbook\n\t    gmt coast -R-2000/2000/-2000/2000+uk -JE130.35/-0.2/3.5i -Dl -A100 \\\n\t\t    -Gburlywood -Sazure -Wthinnest -N1/thinnest,- -B10g5 -BWSne\n\t    echo 130.35 -0.2 | gmt plot -SJ-1000 -Wthicker\n    gmt end show\n\n\u003cp align=\"center\"\u003e\u003cimg alt=\"gshhg low resolution global map\" src=\"https://docs.generic-mapping-tools.org/6.2/_images/GMT_App_K_2.png\" width=\"400\" /\u003e\u003c/p\u003e\n\n### The intermediate resolution (**-Di**)\n\nWe continue to zoom in on the map center. In this map, the edges of the\nmap are all 500 km true distance from the projection center. We abandon\nthe low resolution data set as it would look too jagged at this scale\nand instead employ the intermediate resolution data that faithfully\nreproduce the dominant geographic features in the region. This time, we\nignore features less than 20 km\u003csup\u003e2\u003c/sup\u003e in area. Although the script\nstill asks for national borders none exist within our region. The\nintermediate database is moderately decimated and simplified by the\nDP-routine: The combined file size of the coastlines, rivers, and\nborders now exceeds 3.35 Mbytes. The plot is generated by the script:\n\n    gmt begin GMT_App_K_3\n\t    gmt set GMT_THEME cookbook\n\t    gmt coast -R-500/500/-500/500+uk -JE130.35/-0.2/3.5i -Di -A20 -Gburlywood -Sazure -Wthinnest -N1/thinnest,- -B2g1 -BWSne\n\t    echo 133 2 | gmt plot -Sc1.4i -Gwhite\n\t    gmt basemap -Tmg133/2+w1i+t45/10/5+jCM --FONT_TITLE=12p --MAP_TICK_LENGTH_PRIMARY=0.05i --FONT_ANNOT_SECONDARY=8p\n\t    echo 130.35 -0.2 | gmt plot -SJ-200 -Wthicker\n    gmt end show\n\n\u003cp align=\"center\"\u003e\u003cimg alt=\"gshhg intermediate resolution global map\" src=\"https://docs.generic-mapping-tools.org/6.2/_images/GMT_App_K_3.png\" width=\"400\" /\u003e\u003c/p\u003e\n\n### The high resolution (**-Dh**)\n\nThe relentless zooming continues! Now, the edges of the map are all 100\nkm true distance from the projection center. We step up to the high\nresolution data set as it is needed to accurately portray the detailed\ngeographic features within the region. Because of the small scale we\nonly ignore features less than 1 km\u003csup\u003e2\u003c/sup\u003e in area. The high\nresolution database has undergone minor decimation and simplification by\nthe DP-routine: The combined file size of the coastlines, rivers, and\nborders now swells to 12.3 Mbytes. The map and the final outline box are\ngenerated by these commands:\n\n    gmt begin GMT_App_K_4\n\t    gmt set GMT_THEME cookbook\n\t    gmt coast -R-100/100/-100/100+uk -JE130.35/-0.2/3.5i -Dh -A1 \\\n\t\t    -Gburlywood -Sazure -Wthinnest -N1/thinnest,- -B30mg10m -BWSne\n\t    echo 130.35 -0.2 | gmt plot -SJ-40 -Wthicker\n    gmt end show\n\n\u003cp align=\"center\"\u003e\u003cimg alt=\"gshhg high resolution global map\" src=\"https://docs.generic-mapping-tools.org/6.2/_images/GMT_App_K_4.png\" width=\"400\" /\u003e\u003c/p\u003e\n\n### The full resolution (**-Df**)\n\nWe now arrive at our final plot, which shows a detailed view of the\nwestern side of the small island of Waigeo. The map area is\napproximately 40 by 40 km. We call upon the full resolution data set to\nportray the richness of geographic detail within this region; no\nfeatures are ignored. The full resolution has undergone no decimation\nand it shows: The combined file size of the coastlines, rivers, and\nborders totals a (once considered hefty) 55.9 Mbytes. Our final map is\nreproduced by the single command:\n\n    gmt begin GMT_App_K_5\n\t    gmt set GMT_THEME cookbook\n\t    gmt coast -R-20/20/-20/20+uk -JE130.35/-0.2/3.5i -Df -Gburlywood -Sazure -Wthinnest -N1/thinnest,- -B10mg2m -BWSne\n    gmt end show\n\n\u003cp align=\"center\"\u003e\u003cimg alt=\"gshhg full resolution global map\" src=\"https://docs.generic-mapping-tools.org/6.2/_images/GMT_App_K_5.png\" width=\"400\" /\u003e\u003c/p\u003e\n\nWe hope you will study these examples to enable you to make efficient\nand wise use of this vast data set.\n\n## Technical Details\n\n### Selecting the right data\n\nThere are two well-known public-domain data sets that could be used for\nthis purpose. Once is known as the World Data Bank II or CIA Data Bank\n(WDB) and contains coastlines, lakes, political boundaries, and rivers.\nThe other, the World Vector Shoreline (WVS) only contains shorelines\nbetween saltwater and land (i.e., no lakes). It turns out that the WVS\ndata is far superior to the WDB data as far as data quality goes, but as\nnoted it lacks lakes, not to mention rivers and borders. We decided to\nuse the WVS whenever possible and supplement it with WDB data. We got\nthese data over the Internet; they are also available on CD-ROM from the\n[National Centers for Environmental Information, Boulder, Colorado](http://www.ncei.noaa.gov/).\n\n### Format required by GMT\n\nIn order to paint continents or oceans it is necessary that the\ncoastline data be organized in polygons that may be filled. Simple line\nsegments can be used to draw the coastline, but for painting polygons\nare required. Both the WVS and WDB data consists of unsorted line\nsegments: there is no information included that tells you which segments\nbelong to the same polygon (e.g., Australia should be one large\npolygon). In addition, polygons enclosing land must be differentiated\nfrom polygons enclosing lakes since they will need different paint.\nFinally, we want [coast](https://docs.generic-mapping-tools.org/latest/coast.html)\nto be flexible enough that it can paint the land *or* the oceans *or* both. If\njust land (or oceans) is selected we do not want to paint those areas\nthat are not land (or oceans) since previous plot programs may have\ndrawn in those areas. Thus, we will need to combine polygons into new\npolygons that lend themselves to fill land (or oceans) only (Note that\nolder versions of [coast](https://docs.generic-mapping-tools.org/latest/coast.html)\nalways painted lakes and wiped out whatever was plotted beneath).\n\n### The long and winding road\n\nThe WVS and WDB together represent more than 100 Mb of binary data and\nsomething like 20 million data points. Hence, it becomes obvious that\nany manipulation of these data must be automated. For instance, the\nreasonable requirement that no coastline should cross another coastline\nbecomes a complicated processing step.\n\n*  To begin, we first made sure that all data were \"clean\", i.e., that\n   there were no outliers and bad points. We had to write several\n   programs to ensure data consistency and remove \"spikes\" and bad\n   points from the raw data. Also, crossing segments were automatically\n   \"trimmed\" provided only a few points had to be deleted. A few hundred\n   more complicated cases had to be examined semi-manually.\n\n*  Programs were written to examine all the loose segments and determine\n   which segments should be joined to produce polygons. Because not all\n   segments joined exactly (there were non-zero gaps between some\n   segments) we had to find all possible combinations and choose the\n   simplest combinations. The WVS segments joined to produce more than\n   200,000 polygons, the largest being the Africa-Eurasia polygon which\n   has 1.4 million points. The WDB data resulted in a smaller data base\n   (~25% of WVS).\n\n*  We now needed to combine the WVS and WDB data bases. The main problem\n   here is that we have duplicates of polygons: most of the features in\n   WVS are also in WDB. However, because the resolution of the data\n   differ it is nontrivial to figure out which polygons in WDB to\n   include and which ones to ignore. We used two techniques to address\n   this problem. First, we looked for crossovers between all possible\n   pairs of polygons. Because of the crossover processing in step 1\n   above we know that there are no remaining crossovers within WVS and\n   WDB; thus any crossovers would be between WVS and WDB polygons.\n   Crossovers could mean two things: (1) A slightly misplaced WDB\n   polygon crosses a more accurate WVS polygon, both representing the\n   same geographic feature, or (2) a misplaced WDB polygon (e.g., a\n   small coastal lake) crosses the accurate WVS shoreline. We\n   distinguished between these cases by comparing the area and centroid\n   of the two polygons. In almost all cases it was obvious when we had\n   duplicates; a few cases had to be checked manually. Second, on many\n   occasions the WDB duplicate polygon did not cross its WVS counterpart\n   but was either entirely inside or outside the WVS polygon. In those\n   cases we relied on the area-centroid tests.\n\n*  While the largest polygons were easy to identify by visual\n   inspection, the majority remain unidentified. Since it is important\n   to know whether a polygon is a continent or a small pond inside an\n   island inside a lake we wrote programs that would determine the\n   hierarchical level of each polygon. Here, level = 1 represents\n   ocean/land boundaries, 2 is land/lakes borders, 3 is\n   lakes/islands-in-lakes, and 4 is\n   islands-in-lakes/ponds-in-islands-in-lakes. Level 4 was the highest\n   level encountered in the data. To automatically determine the\n   hierarchical levels we wrote programs that would compare all possible\n   pairs of polygons and find how many polygons a given polygon was\n   inside. Because of the size and number of the polygons such programs\n   would typically run for 3 days on a Sparc-2 workstation.\n\n*  Once we know what type a polygon is we can enforce a common\n   \"orientation\" for all polygons. We arranged them so that when you\n   move along a polygon from beginning to end, your left hand is\n   pointing toward \"land\". At this step we also computed the area of all\n   polygons since we would like the option to plot only features that\n   are bigger than a minimum area to be specified by the user.\n\n*  Obviously, if you need to make a map of Denmark then you do not want\n   to read the entire 1.4 million points making up the Africa-Eurasia\n   polygon. Furthermore, most plotting devices will not let you paint\n   and fill a polygon of that size due to memory restrictions. Hence, we\n   need to partition the polygons so that smaller subsets can be\n   accessed rapidly. Likewise, if you want to plot a world map on a\n   letter-size paper there is no need to plot 10 million data points as\n   most of them will plot several times on the same pixel and the\n   operation would take a very long time to complete. We chose to make 5\n   versions on the database, corresponding to different resolutions. The\n   decimation was carried out using the Douglas-Peucker (DP)\n   line-reduction algorithm (Douglas and Peucker, 1973). We chose the cutoffs so\n   that each subset was approximately 20% the size of the next higher resolution.\n   The five resolutions are called **f**ull, **h**igh,\n   **i**ntermediate, **l**ow, and **c**rude; they are accessed in\n   [coast](https://docs.generic-mapping-tools.org/latest/coast.html),\n   [gmtselect](https://docs.generic-mapping-tools.org/latest/gmtselect.html), and\n   [grdlandmask](https://docs.generic-mapping-tools.org/latest/grdlandmask.html) with the **-D** option.\n   For each of these 5 data sets (**f**, **h**, **i**,\n   **l**, **c**) we specified an equidistant grid (1, 2, 5, 10, 20) and\n   split all polygons into line-segments that each fit inside one of the\n   many boxes defined by these grid lines. Thus, to paint the entire\n   continent of Australia we instead paint many smaller polygons made up\n   of these line segments and gridlines. Some book-keeping has to be\n   done since we need to know which parent polygon these smaller pieces\n   came from in order to prescribe the correct paint or ignore if the\n   feature is smaller than the cutoff specified by the user. The\n   resulting segment coordinates were then scaled to fit in short\n   integer format to preserve precision and written in netCDF format for\n   ultimate portability across hardware platforms (Wessel and Smith, 1996).\n\n*  While we are now back to a file of line-segments we are in a much\n   better position to create smaller polygons for painting. Two problems\n   must be overcome to correctly paint an area:\n\n   -  We must be able to join line segments and grid cell borders into\n      meaningful polygons; how we do this will depend on whether we want\n      to paint the land or the oceans.\n\n   -  We want to nest the polygons so that no paint falls on areas that\n      are \"wet\" (or \"dry\"); e.g., if a grid cell completely on land\n      contains a lake with a small island, we do not want to paint the\n      lake and then draw the island, but paint the annulus or \"donut\"\n      that is represented by the land and lake, and then plot the\n      island.\n\n   GMT uses a polygon-assembly routine that carries out these tasks on the fly.\n\n## References\n\n- Bohlander, J. and T. Scambos. 2007. Antarctic coastlines and grounding line\n  derived from MODIS Mosaic of Antarctica (MOA), Boulder, Colorado USA:\n  National Snow and Ice Data Center.\n- Douglas, D.H., and T. K. Peucker, 1973, Algorithms for the reduction\n  of the number of points required to represent a digitized line or its\n  caricature, *Canadian Cartographer*, 10, 112–122.\n- Gorny, A. J. (1977), World Data Bank II General User GuideRep. PB 271869,\n  10pp, Central Intelligence Agency, Washington, DC.\n- Soluri, E. A., and V. A. Woodson (1990), World Vector Shoreline,\n  Int. Hydrograph. Rev., LXVII(1), 27–35.\n- Wessel, P., and W. H. F. Smith (1996), A global, self-consistent, hierarchical,\n  high-resolution shoreline database, J. Geophys. Res., 101(B4), 8741–8743.\n\n## Authors\n\n- Paul Wessel     Primary contact: pwessel@hawaii.edu\n- Walter H. F. Smith\n\n## Changelog\n\nThe detailed changelog is available [here](ChangeLog).\n\n## License\n\nThe project is distributed under the\n[GNU Lesser General Public License](http://www.gnu.org/licenses/lgpl-3.0.html).\n\n## Earlier GSHHG Version-specific comments:\n\nVersion 2.3.7 June 15, 2017\n\nUpdates the Northern Mariana Islands with CUPS data from NOAA, adds\ntwo missing islands to northern Norway, and adds in the missing\nKosovo-Serbia boundary.\n\nVersion 2.3.6 August 19, 2016\n\nFixed 11 crossings in Antarctica grounding line and one in the ice front.\nAdded missing islands Georgetown and MacMahan, ME, and updated Jan Mayen, Norway\n[thanks to Norwegian Polar Institute]\n\nVersion 2.3.5 April 12, 2016\n\nAdded missing boundary between Sudan and South Sudan.\nFixed non-closure of the Slovenia, Croatia and Hungary borders.\n\nVersion 2.3.4 Jan 1, 2015\n\nCorrected formatting error in the binary versions of the borders\nand rivers files.  Added \"Lake\" Maelaren (Sweden) to the coastline\nwhich reverted 11 \"lakes\" to their proper status as islands.\n\nVersion 2.3.3 Nov 2014:\n\nRemoved the obsolete Saudi-Kuwait Neutral Zone diamond-shaped border\nand replaced with something resembling what Google Earth shows.\n\nVersion 2.3.2 August 2014:\n\nRemoved several internal crossovers for the two new Antarctica\npolygons.  All other polygons are unchanged.\n\nVersion 2.3.1 July 2014:\n\nUpdated to include Peter I Island near Antarctica which had gone\nmissing during the switch to the Antarctica data source for 2.3.0.\n\nVersion 2.3.0 Feb 2014:\n\nThis data set consists of three related components:\n\nGSHHS:\tGlobal Self-consistent Hierarchical High-resolution Shorelines:\n\tThese originate as individual polygons at five different\n\tresolutions.  The ocean-land shorelines derive from WVS (World\n\tVector Shoreline project) [Soluri and Woodson, 1990] while the\n\tpolygons for lakes, islands-in-lakes, and ponds-in-islands-\n\tin-lakes derive from WDBII [Gorny, 1977], which is a much older\n\tand lower-quality data product.  Our compilation combines these\n\tdata into a self-consistent product; see Wessel and Smith [1996]\n\tfor processing details.  Over the years we have manually added\n\tnew data in areas that were poorly represented in the original\n\tdata set; however, as users zoom in closely they can see that\n\tthe old data may in places be mis-registered relative to recent\n\tdata such as used in Google Earth.\nAC:\tStarting with release 2.3.0 we have replaced the poor Antarctica\n\tpolygon and associated islands with newer and more accurate\n\tdata from Bohlander and Scambos (2007) via Atlas of the Cryosphere.\n\tThis lets us consider two polygon: ice-line and grounding line.\n\tNew processing was needed to allow a run-time switch on which\n\tpolygon to use (since it changes how many islands to include).\n\tAntarctic ice-front polygons are given level 5 while Antarctic\n\tgrounding-line polygons are given level 6. Non-GMT users of these\n\tdata should skip one of these two levels are reset the other one\n\tto level = 1.  The next GMT5 release 5.2.0 will allow users to\n\tselect their Antarctica coastline while older versions will simply\n\tuse the ice-front line as the single Antarctica coastline; the\n\tgrounding line data are not visible to those versions.\n\nWDBII:\tCIA World Data Bank II lineaments for borders and rivers.\n\tOver the years, political boundaries have changed and we have\n\tupdated these to reflect realities based on feedback from our\n\tusers. As mentioned above, WDBII is also used for lakes.\n\nGSHHG is distributed in several representations:\n\n\t1. The binary and shapefile distributions provide the complete\n\t   GSHHS polygons and WDBII lineaments in their five resolutions\n\t   (i.e., after our full processing), and differ only in the\n\t   file formats (native binary data files versus standard GIS\n\t   shapefiles).  These distributions are normally used by\n\t   users interested to use these data outside the standard\n\t   GMT-based environment, or GMT users who wish to access the\n\t   whole GSHHS polygons.\n\t2. The netCDF distribution provides specially processed netCDF\n\t   representations of GSHHS and WDBII where the polygons and\n\t   lines have been subdivided and indexed to deliver rapid map-\n\t   making for GMT.  Users who wish to access GSHHG outside of\n\t   GMT are advised to use the binary and shapefile version of\n\t   the actual polygons as there is no user documentation for\n\t   how to access the netCDF files.\n\nMany thanks to Tom Kratzke, Metron Inc., for patiently testing\nmany draft versions of GSHHS and reporting inconsistencies such as\nerratic data points and crossings.\n\nVersion 2.2.4 Nov 2013: We added three missing lakes (Mono, Trinity,\nand Isabella) in California, plus two islands in Lake Mono. Also found\na bug in polygon_consistency that failed to find some spikes (~20-25\npolygons affected), as well as an incorrect lake in Antarctica.\n\nVersion 2.2.3 July 2013: We eliminated ~120 spikes (\u003c 2m thick excursions)\nfrom a few dozen full resolution polygons. Also fixed an old mistake\nin Baffin Island in all but the crude resolution; this also converted\ntwo mislabeled \"lakes\" into islands in the full and high resolution data.\n\n\nVersion 2.2.2 January 2013: We have removed Sandy Island, Coral Sea\n(non feature), shifted Society Island polygons ~1 arc minute to the west,\nand replaced Mehetia Island with better data.  Furthermore, 50 islands\nthat were imprecise duplicates of more accurate WVS features were removed.\nApart from the Agalega islands, these duplicates were mostly found in\nthe Red Sea, the Persian Gulf, and in the Cook-Austral region.  GSHHG is\nnow released under the lesser GNU License, v3 or any earlier version.\n\nVersion 2.2.1 July 2012: We have renamed the product GSHHG since it\ncontains more than just shorelines (we distribute political boundaries\nand rivers as well).  The GSHHG building and distribution is now\nfully decoupled from GMT.  We have also changed the name of the\nnetCDF files for GMT to use the more standard extension *.nc.\nFurthermore, the packages have been renamed for clarity and follow\nthe form gshhg-{gmt,bin,shp}-\u003cversion\u003e.{tar,zip}\nThere are no significant changes to the actual data features, other\nthan a glitch in SA-NT border in Australia and removal of 7 zero-length\nborder segments.  Following the rebranding to GSHHG the names of the\ndistribution files have changed as well.\n\nVersion 2.2.0 July 2011: The area of small (\u003c 0.1 km^2) polygons\ngot truncated to 0.  This would cause gshhs to consider them\nas lines (borders or rivers) instead of polygons.  Furthermore,\nthe areas were recomputed using the WGS-84 ellipsoid as the previous\narea values were based on a spherical calculation.  Thanks to\nJosé Luis García Pallero for pointing this out.  We now store\nthe area with a magnitude scale tuned to each polygon.  Also, the\ngreenwich flag is now a 2-bit flag composed of 1 (crosses Greenwich),\n2 (crosses Dateline), 3 (both) or 0 (no such crossing).  See gshhs.[ch] for\ndetails.  Finally, the binary gshhs files now store Antarctica in\n-180/+180 range so as to avoid a jump when dumped to ASCII.\nAlso, the WDBII shapefiles  only had the first 3 levels of rivers;\nversion 2.2.0 has all 11.  Finally, to be able to detect the river-lake\nfeatures in the WDBII binary files we set the river flag to 1 if a closed feature.\n\nVersion 2.1.1 March 2011: Relatively minor fixes to low-resolution\npolygons, including editing errors introduced in v 2.1, removing\na few spikes from 4-5 polygons, and fixing Germany-Poland border\nnear the Baltic Sea.\n\nVersion 2.1 July 2010: Fixes lack of river-lake flag in the binary\nand shapefile release.  Shapefile polygons of level = 2 and with a\nnegative area are river-lakes.  Also include WDBII border and river\ndata as shapefiles.\n\nversion 2.0 July 15, 2009: Differs from the previous version 1.x in\nthe following ways.\n\n1.  Free from internal and external crossings and erratic spikes\n    at all five resolutions.\n2.  The original Eurasiafrica polygon has been split into Eurasia\n    (polygon # 0) and Africa (polygon # 1) along the Suez canal.\n3.  The original Americas polygon has now been split into North\n    America (polygon # 2) and South America (polygon # 3) along\n    the Panama canal.\n4.  Antarctica is now polygon # 4 and Australia is polygon # 5, in\n    all the five resolutions.\n5.  Fixed numerous problems, including missing islands and lakes\n    in the Amazon and Nile deltas.\n6.  Flagged \"riverlakes\" which are the fat part of major rivers so\n    they may easily be identified by users.\n7.  Determined container ID for all polygons (== -1 for level 1\n    polygons) which is the ID of the polygon that contains a smaller\n    polygon.\n8.  Determined full-resolution ancestor ID for lower res polygons,\n    i.e., the ID of the polygon that was reduced to yield the lower-\n    res version.\n9.  Ensured consistency across resolutions (i.e., a feature that is\n    an island at full resolution should not become a lake in low!).\n10. Sorted tables on level, then on the area of each feature.\n11. Made sure no feature is missing in one resolution but\n    present in the next lower resolution.\n12. Store both the actual area of the lower-res polygons and the\n    area of the full-resolution ancestor so users may exclude fea-\n    tures that represent less that a fraction of the original full\n    area.\n\nThere was some duplication and wrong levels assigned to maritime\npolitical boundaries in the Persian Gulf that has been fixed.\n\nThese changes required us to enhance the GSHHG C-structure used to\nread and write the data.  As of version 2.0 the header structure is\n\n```\nstruct GSHHG {  /* Global Self-consistent Hierarchical High-resolution Shorelines */\n        int id;         /* Unique polygon id number, starting at 0 */\n        int n;          /* Number of points in this polygon */\n        int flag;       /* = level + version \u003c\u003c 8 + greenwich \u003c\u003c 16 + source \u003c\u003c 24 + river \u003c\u003c 25 */\n        /* flag contains 5 items, as follows:\n         * low byte:    level = flag \u0026 255: Values: 1 land, 2 lake, 3 island_in_lake, 4 pond_in_island_in_lake\n         * 2nd byte:    version = (flag \u003e\u003e 8) \u0026 255: Values: Should be 12 for GSHHG release 12 (i.e., version 2.2)\n         * 3rd byte:    greenwich = (flag \u003e\u003e 16) \u0026 1: Values: Greenwich is 1 if Greenwich is crossed\n         * 4th byte:    source = (flag \u003e\u003e 24) \u0026 1: Values: 0 = CIA WDBII, 1 = WVS\n         * 4th byte:    river = (flag \u003e\u003e 25) \u0026 1: Values: 0 = not set, 1 = river-lake and level = 2\n         */\n        int west, east, south, north;   /* min/max extent in micro-degrees */\n        int area;       /* Area of polygon in 1/10 km^2 */\n        int area_full;  /* Area of original full-resolution polygon in 1/10 km^2 */\n        int container;  /* Id of container polygon that encloses this polygon (-1 if none) */\n        int ancestor;   /* Id of ancestor polygon in the full resolution set that was the source of this polygon (-1 if none) */\n};\n```\n\nFollowing each header structure is n structures of coordinates:\n\n```\nstruct GSHHG_POINT {\t/* Each lon, lat pair is stored in micro-degrees in 4-byte signed integer format */\n\tint32_t x;\n\tint32_t y;\n};\n```\n\nSome useful information:\n\nA) To avoid headaches the binary files were written to be big-endian.\n   If you use the GMT supplement gshhg it will check for endian-ness and if needed will\n   byte swab the data automatically. If not then you will need to deal with this yourself.\n\nB) In addition to GSHHS we also distribute the files with political boundaries and\n   river lines.  These derive from the WDBII data set.\n\nC) As to the best of our knowledge, the GSHHG data are geodetic longitude, latitude\n   locations on the WGS-84 ellipsoid.  This is certainly true of the WVS data (the coastlines).\n   Lakes, riverlakes (and river lines and political borders) came from the WDBII data set\n   which may have been on WGS072.  The difference in ellipsoid is way less then the data\n   uncertainties.  Offsets have been noted between GSHHG and modern GPS positions.\n\nD) Originally, the gshhs_dp tool was used on the full resolution data to produce the lower\n   resolution versions.  However, the Douglas-Peucker algorithm often produce polygons with\n   self-intersections as well as create segments that intersect other polygons.  These problems\n   have been corrected in the GSHHG lower resolutions over the years.  If you use gshhs_dp to\n   generate your own lower-resolution data set you should expect these problems.\n\nE) The shapefiles release was made by formatting the GSHHG data using the extended GMT/GIS\n   metadata understood by OGR, then using ogr2ogr to build the shapefiles.  Each resolution\n   is stored in its own subdirectory (e.g., f, h, i, l, c) and each level (1-4) appears in\n   its own shapefile.  Thus, GSHHS_h_L3.shp contains islands in lakes for the high res\n   data. Because of GIS limitations some polygons that straddle the Dateline (including\n   Antarctica) have been split into two parts (east and west).\n\nF) The netcdf-formatted coastlines distributed with GMT derives directly from GSHHG; however\n   the polygons have been broken into segments within tiles.  These files are not meant\n   to be used by users other than via GMT tools (pscoast, grdlandmask, etc).\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgenericmappingtools%2Fgshhg-gmt","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgenericmappingtools%2Fgshhg-gmt","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgenericmappingtools%2Fgshhg-gmt/lists"}