To fg index -|- gshhs 01 -|- newscenery.htm
In page trials: [1] [2] [3] v0vsgshhs [4] [5] [6]

Global Self-consistent, Hierarchical, High-resolution Shoreline

Some experimentation with GSHHS - see - as the 'Default' land use base data...

The first try was not very successful ;=(( I added some simple limits to the gshhs 'chop-into-poly-files' tool, but this perhaps 'breaks' the resultant polygon. On the second try I extended these limits by first 10 and then 20 degrees, and the results improved.

2011-05-12: Minor update, especially of a mapserver link v0 vs gshhs, and the link to poly-view source.


Trial 1

Some GSHHS attempts can yield 'interesting' results ;=)) For the 'Default' land mass -

(a) using GSHHS ONLY (b) combined GSHHS and VMAP0
location: "--heading=280 --lat=-33.8764 --lon=151.2995 --altitude=1000"
ns4 024 jpg ns4 023 jpg

In the first, Sydney has gone under the sea - global warming extreme ;=)), and in the 2nd most of the harbor has been filled in ;=)) So it comes down to how to correctly apply GSHHS? Maybe I should be using the 'boundaries' GSHHS data base?? Lots of questions here...

Is there a 'tool', or can I build a tool, that lets me VIEW the 'Land Use' data?


Trial 2

The second try started to yield some slightly better results, but it seems the 'shoreline' got considerably extended! Here it is filled in by the 'default' landmass cover - green vegetation ;=))

Using GSHHS as 'Default'
ns4 028 jpg ns4 029 jpg
Using VMAP0 as 'Default'
ns4 030 jpg ns4 033 jpg
location: "--heading=280 --lat=-33.8764 --lon=151.2995 --altitude=1000"

All these images were from scenery where the terrafit tool was used with the additional parameter --maxerror 15, thus the 'ridge' has been reduced to a line, and maybe The Rocks looks better...

ns4 031 jpg ns4 032 jpg
"--heading=176 --lat=-33.877 --lon=151.24955
"--heading=235 --lat=-33.86325 --lon=151.2224


Trial 3

In the above, when a point was out-of-range I simply excluded it, but perhaps this was not good. In this next trial, I now add every point, but check for out-of-range 'buckets' before writing the 'tile' poly file. This takes a lot of time, since all the polygon chopping is done first, and only at the last second, decide to write it or not... let's see...

2011-05-12: Corrected the URL, and as the images below show -
the GSHHS coastline - pink lines - do not match that of VMAP0 - GSHHS seems a little north and east??? but the GSHHS detail is exquisite, but for some strange reason stops short of showing the deep inner harbor ;=))

Sydney Harbor
ms 001 gif ms 002 gif
Area around St. John, Newfoundland
ms 006 png ms 005 png
Hong Kong
ms 003 png ms 004 png

Still more to understand here... but it looks like the GSHHS - the thin red line - is displaced north-east compared to VMAP0 'borders'. The above shows the regions around (lat, lon) Sydney at -33.9434,151.1798 (YSSY), St. John at 47.6199,-52.7459 (CYYT) and Hong Kong at 22.3083,113.9178 (VHHH).

Maybe the GSHHS 'chop' tool needs to have a '--nudge=<degs>' parameter, like the genapts, and fgfs-construct tools, or even an 'xnudge' and 'ynudge', if the displacement is not equal in both directions? Then MAYBE the coastline from the GSHHS databases can be used in place of the tgvpf extraction of 'bnd polbnda' as the 'Default' land use ;=)) MAYBE???

So I built a (unfortunately presently windows only) poly viewer - poly-view exe - to read raw polygon files written by the 'gshhs' and 'tgvpf' TerraGear tools, to be able the SEE the difference on the Sydney coastline -

pv 01 gif
pv 02 gif

These image show the problem quite clearly! The gshhs coastline, painted in RED is far more detailed compared to the tgvpf VMAP0 boundaries extraction, painted in BLUE, but appears 'shifted' north and east. The small gap in each polygon is only where my tool presently 'misses' joining the first and last points of each polygon... As can be seen, this is tile e150s40/e151s34/5426679 ...


Trial 4

And the above painted with a little -0.008 nudge ;=)) applied to the gshhs coastline, painted in RED. The tgvpf VMAP0 boundaries are painted in BLUE

pv 03 gif

Now things start to line up better ;=)) But this 'nudge' was after-the-fact, so the bucket boundaries are also nudged. I also managed to fully close the polygons, painting the last back to the first...

This indicates that the nudge should be back in the bucket-chopping tool, 'gshhs' in this case...  So now to try adding '--nudge=<degs>' to 'gshhs'... and to also try to speed up gshhs extraction process...


Trial 5

And with a little bit of work, I was able to fill the background with the current Scenery-1.0.1. The first attempt was a bit of a failure ;=(( I tried to directly paint the wgs84 nodes, and normal nodes to the scene :-

pv 04 png pv 05 png

But eventually I got it right - well nearly...

pv 06 png

As can be clearly seen, the 'nudging' also causes my display of borders to be offset from the actual scenery borders... and I got the 'colors' a bit messed up. The 'gray' should be blue water! And the following is WITHOUT a 'nudge'. Remember, the 'blue' is the VMAP0 borders, and the 'red' is the GSHHS borders...

pv 07 png


And then I decided to load some buckets around the central bucket, and nudge GSHHS towards the existing VMAP0 scenery, and it started to look like a real map ;=))

With surrounding bucket of scenery loaded

I even fiddled with the colors, using the AtlasPallette file format, but still got them quite 'wrong' ;=((.

And it is 'interesting' to 'see' all the 'triangles' that make up the FlightGear scenery. Ralf recently mentioned that there is an attempt to stay below 10,000-triangles-per-tile - that is approx 1/8 by 1/8 degree tiles...

showing the triangles showing the triangles

One can see this can easily be achieved when there is lots of water around, but the triangle count really jumps when there is an airport, as shown in the right image


Trial 6

An ongoing saga...


EOP - GSHHS-02.doc - April, 2009 - 2010/03/12 - 20110512

checked by tidy  Valid HTML 4.01 Transitional