GSHHS High Resolution Source - ZyGrib?

[nohal]

Rick...
We would certainly need more info on how to reproduce your bad routing crossing land. But as you can see here, the land detection provided to the plugins by the core seems to be working fine, at least on my system.



I also can't reproduce the problem with GSHHG disappearing at certain scales (But I of course have https://github.com/OpenCPN/OpenCPN/c...5dd7db0d80fdf8 - make sure your build is recent enough)

Pavel

[rgleason]

bool PlugIn_GSHHS_CrossesLand(double lat1, double lon1, double lat2, double lon2) { static bool loaded = false; if(!loaded) { gshhsCrossesLandInit(); loaded = true; }
return gshhsCrossesLand(lat1, lon1, lat2, lon2); }

Thanks Pavel, I think I actually understand it, the return is to the external messaging for the Plugins. The land test also helps.

I will git fetch and rebuild. Test and then try TDan's suggestion to relocated the folder back to it's original location.

Thanks.

[nohal]

Rick...
Relocating anything anywhere without knowing why is not exactly a good idea. The "original location" is not even looked at by the current code once a directory with GSHHG data is discovered during the chart database update. If you want to help, relax, read the logs, and present a reproducible problematic usage pattern without doing any random manual harakiri.

Pavel

[bcn]

A grain of salt and call for cross checking -

comparing oeSENC/S-57 charts with GSHHS HiRes using some tracks.

GSHHS for Majorca, Cabrera and Columbretes are not correctly geo-referenced. About 1 cable off.
Ibiza, Formentera and Spanish mainland look right.
The issue when using base material with a resolution of 50-100m

So be careful when using the sets for auto-routing!

It would be interesting to see some more examples from other places.

[rgleason]

Git - fetch upstream, checkout master, reset --hard upstream/master, push origin master --force
Then using BatchUtils from TDan "Build Clean" and "Build Package"
Merge branch 'master' of github.com:OpenCPN/OpenCPN
remotes/OpenCPN/AIS_cache d2ddf01 Correct
Uninstall Opencpn [now forced to do this to install to the same location], Install Opencpn
Now Current to Branch * master 54b5217 Merge branch 'master' of github.com
My Chart paths, Chart Groups and ChartDownloader setups remained, so my OpenCPN.ini was not overwritten which is good.


Found my Opencpn.ini set to this:
[Settings/ChartDnldr]
ChartSources=All GSHHG basemaps|https://raw.githubusercontent.com/ch...\Chart\\GSHHG|
Source=0
BaseChartDir=C:\\Users\\Frederick\\Documents\\Char ts
PreselectNew=0
PreselectUpdated=1
AllowBulkUpdate=0

[ChartDirectories]
ChartDir11=D:\\Data-Juno\\Chart\\GSHHG^18378318866500742208
There are others.

[Directories]
S57DataLocation=
InitChartDir=D:\\Data-Juno\\Chart
GPXIODir=
TCDataDir=
BasemapDir=D:\\Data-Juno\\Chart\\GSHHG\\
WMMDataLocation=C:\\Program Files (x86)\\OpenCPN 4.8.0\\plugins\\wmm_pi\\data\\
GRIBDirectory=D:\\Data-Juno\\Grib

[Groups/Group1]
GroupName=Empty
GroupItemCount=0

[Groups/Group2]
GroupName=GSHHG
GroupItemCount=0

Both of these Chart Groups have paths to D:\Data-Juno\Chart\GSHHG
Earlier, I used ChartDownloader to downloaded to D:\Data-Juno\Chart\GSHHG

I now find folder C:\Program Files (x86)\OpenCPN 4.8.0\gshhs and it is the low res background.
Also a folder C:\Users\Frederick\Documents\Charts\GSHHG which has the GSHHG_Catalog.xml and chartdldr_pi.dat, but nothing else.
and also the same files which I think I am using, at D:\Data-Juno\Chart\GSHHG plus all the other very recent high res files.

With GSHHG World Basemaps downloaded and expanded into D:\Data-Juno\Chart\GSHHG\ or
The High Res Basemap disappears when you zoom down from scale 508600 to 492200


I've now deleted C:/Charts completely, because D:\Data-Juno\Chart\ is where I keep charts.
and I have changed BaseChartDir=C:\\Users\\Frederick\\Documents\\Char ts to BaseChartDir=:\\Data-Juno\\Chart\\ and saved the ini.

I open OpenCPN and checked ChartDownloader GSHHG and everything was up to date.
When I check zooming into Watch Hill, Rhode Island, the background still disappears at about 512900 - 490000 and reappears at about 502200.
This is not a small enough scale!

So then I copied all of D:\\Data-Juno\\Chart\\GSHHG\\
to C:\Program Files (x86)\OpenCPN 4.8.0\gshhs
deleting the original files first.

There was no change, I then added the path C:\Program Files (x86)\OpenCPN 4.8.0\gshhs and created a Chart Group with that path and set that Chart Group active and tried it. Still no change.

Then I checked zooming into Cape Hatteras, NC, Cape Lookout and Cape Fear and can zoom all the way down!
Then I checked England, and I cannot zoom in without loosing the background, much like Watch Hill, RI area.
Then I checked the Heel of Italy and I can zoom all the way into scale 1500

So there is something wrong with the Background mapping with regard to "Scaling" and Zooming in to small scales, I think. The problem seems to be topical. Nerw England & England, France have trouble zooming in all the way. While Cape Fear, Cape Lookout, Cape Hatteras, Italy (boot) can zoom all the way in with no trouble.

I will test Weather_routing land detection again now.

[rgleason]

Using Gilletarom's data and weatherroutingconfiguration.xml, grib and Odraw data from here
http://www.cruisersforum.com/forums/...ml#post2547341

But with the Odraw boundaries turned off. Then just do some routings.

Ok, here I have copied all the Gshhg data to the normal location opencpn\gshhs folder.
I also added a chart path to it and added that path to a Gshhg-Prog Chart Group and set that active to be doubly sure that weather_routing got the messages.
It made no difference. Why?

[Should I try using the old high res to see if these issue are there too?]

Please see these:

[nohal]

Rick...
Nice pictures, but I have no idea what you are doing from them. I also have no idea what GSHHS polygons you have. I also have no idea how you are doing the routings that you think are not detecting land and should. Could we, please, create one single clear and simple case that is not behaving correctly at a time?

So to start with.

I open OpenCPN and checked ChartDownloader GSHHG and everything was up to date.
When I check zooming into Watch Hill, Rhode Island, the background still disappears at about 512900 - 490000 and reappears at about 502200.
This is not a small enough scale!

Can not reproduce. The chart downloader, for a very long time already, uses the data from the chartdldr_pi.dat file next to your charts, not the charts themselves, for performance reasons. For a normal user, not messing around with stuff manually, this is good enough. In your case, well, I do not know. What I do know, is that that the downloader says you have everything up to date means nothing if you do not let it do it's work. All of it's work. All the time.
The GSHHS polygons are worldwide. There is the whole planet at the given quality in one single file. Which means, you have the data everywhere, or nowhere. There is no way they could be available in Italy and not in France, the UK or on Rhode Island. So please forget about geography here and try to concentrate on geometry. As in bcn's post from Barcelona a couple of days ago, where land and water seem to invert colors at very large scales with OpenGL off on ARM. Couldn't, possibly, something like this be also your case here?

Ok, here I have copied all the Gshhg data to the normal location opencpn\gshhs folder.
I also added a chart path to it and added that path to a Gshhg-Prog Chart Group and set that active to be doubly sure that weather_routing got the messages.
It made no difference. Why?

Stop copying stuff around manually, please, I beg you, really, there is absolutely no chance you fix something. Let the chart downloader and chart database updater do their jobs.
It is completely useless to add GSHHG to chart groups, these are no normal charts and once present and seen, can't be turned off or on by the user, by design.
There is always only one folder with them used on your system (Which needs to be any of the directories on the Chart Files tab), the last one found when updating the chart database, regardless of being or not in a group or wherever else. It does not matter how smart you try to be, you can't do anything about it. Let the chart downloader download your GSHHG basemaps, once, do not touch anything and they will simply work. If they don't, don't touch anything and let us look at it.
This is the only way problems can be identified and fixed.

Land detection "not working"

Can't reproduce your "disappointing" result. Whatever I try with Gilletarom's configuration and grib data, the results are like the attached, virtually perfect. This does not mean there aren't corner cases that are not optimal. They just have very little to do with the GSHHG basemap and are more weather routing plugin's design limitations (not decreasing step close to land, for example) and operator error (Wrong parameters, like too big step for the area)



And do not worry, we will identify and fix all the problems, one at a time, just give us as much info as possible, and some time.

Pavel

[stelian]

Originally Posted by nohal

Can't reproduce your "disappointing" result. Whatever I try with Gilletarom's configuration and grib data, the results are like the attached, virtually perfect.

Pavel,

I have the same results as you when I do the routing with a start date of 01/03 (as in your screenshot). However, try to set this to 01/01 (as in Gilletarom's original report), I think you'll see the cross-land final leg.

And my opencpn.log says: GSHHG: Loaded quality 4 for land crossing detection.

I have no idea if this is related to GSHHG or a WR bug, but just wanted to point out the difference in the starting date.

Stelian.

[nohal]

Stelian...
I of course tried also the departures on 1/1, severeal different times of day. Different polars, different steps, different GSHHG qualities available. Probably about 100 combinations between these two waypoints with this grib file in total so far. None yielded what I see on Rick's picture. I am probably lucky.

Pavel

[stelian]

Originally Posted by nohal

Stelian...
I of course tried also the departures on 1/1, severeal different times of day. Different polars, different steps, different GSHHG qualities available. Probably about 100 combinations between these two waypoints with this grib file in total so far. None yielded what I see on Rick's picture. I am probably lucky.

Pavel

Luck has probably nothing to do with it, some setting must be different.

Anyway, this is probably a WR issue, GSHHG charts seem fine to me.

[nohal]

Stelian...
What I see on your picture seems definitely a WR/step issue and an understandable one. If the end point is reachable over water at all, the last isochrone legs over land should be ignored and step decreased to find the way to the finish.
On Rick's picture it seems like several legs were computed on land, that sure should never happen.

Pavel

[rgleason]

To Answer some of your questions about the previous tests.

The last Log File
9:33 PM: Loading World Chart Q=0 in 0 ms.
8:59:33 PM: Background world map loaded from GSHHS datafiles found in: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs\
8:59:33 PM: Loading World Chart Q=4 in 0 ms.
8:59:35 PM: Initializing Chart D:\Data-Juno\Chart\USrnc\CG-05\12200\12200_1.KAP
8:59:35 PM: Loading World Chart Q=3 in 1 ms.
8:59:36 PM: Loading World Chart Q=2 in 1 ms.


The previous log has:
12:30:01 PM: Searching directory: D:\Data-Juno\Chart\GSHHG for *.kap
12:30:01 PM: Searching directory: D:\Data-Juno\Chart\GSHHG for *.geo
12:30:01 PM: Searching directory: D:\Data-Juno\Chart\GSHHG for *.000
12:30:01 PM: Searching directory: D:\Data-Juno\Chart\GSHHG for *.s57
12:30:01 PM: Searching directory: D:\Data-Juno\Chart\GSHHG for 00300000.a
----
12:30:51 PM: Searching directory: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs for *.kap
12:30:51 PM: Searching directory: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs for *.geo
12:30:51 PM: Searching directory: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs for *.000
12:30:51 PM: Searching directory: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs for *.s57
12:30:51 PM: Searching directory: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs for 00300000.a
12:30:51 PM: Finished chart database Update
----
12:30:51 PM: Metrics: m_display_size_mm: 254 wxDisplaySize: 2160:1440
12:30:51 PM: Chart cache purge
12:30:51 PM: Loading World Chart Q=0 in 0 ms.
12:30:51 PM: Background world map loaded from GSHHS datafiles found in: C:\Program Files (x86)\OpenCPN 4.8.0\gshhs\
12:30:51 PM: Loading World Chart Q=2 in 3 ms.
12:31:33 PM: Chart cache purge
12:31:33 PM: Metrics: m_display_size_mm: 254 wxDisplaySize: 2160:1440
12:31:35 PM: Chart cache purge
12:31:35 PM: Metrics: m_display_size_mm: 254 wxDisplaySize: 2160:1440
------
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:24 PM: gshhs ReadPoly failed
12:32:25 PM: Loading World Chart Q=3 in 0 ms.
12:32:26 PM: Loading World Chart Q=4 in 0 ms.
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:26 PM: gshhs ReadPoly failed
12:32:27 PM: Loading World Chart Q=3 in 0 ms.
12:32:28 PM: Loading World Chart Q=4 in 0 ms.
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: gshhs ReadPoly failed
12:32:28 PM: Loading World Chart Q=3 in 0 ms.
12:32:29 PM: Loading World Chart Q=2 in 0 ms.
12:32:30 PM: Loading World Chart Q=1 in 14 ms.
12:32:31 PM: Loading World Chart Q=0 in 0 ms.
12:32:35 PM: Loading World Chart Q=1 in 16 ms.
12:32:36 PM: Loading World Chart Q=2 in 4 ms.
12:32:36 PM: Loading World Chart Q=3 in 0 ms.
12:32:39 PM: Loading World Chart Q=4 in 0 ms.
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:39 PM: gshhs ReadPoly failed
12:32:41 PM: Loading World Chart Q=3 in 0 ms.
12:32:42 PM: Loading World Chart Q=4 in 0 ms.
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: gshhs ReadPoly failed
12:32:42 PM: Loading World Chart Q=3 in 0 ms.
12:32:44 PM: Loading World Chart Q=4 in 0 ms.
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:44 PM: gshhs ReadPoly failed
12:32:45 PM: Loading World Chart Q=3 in 0 ms.
12:32:46 PM: Loading World Chart Q=2 in 0 ms.
12:32:47 PM: Loading World Chart Q=1 in 2 ms.
12:32:48 PM: Loading World Chart Q=0 in 1 ms.
12:32:54 PM: Loading World Chart Q=1 in 5 ms.
12:32:54 PM: Loading World Chart Q=2 in 5 ms.
12:32:55 PM: Loading World Chart Q=3 in 3 ms.
12:33:00 PM: Chart cache purge
12:33:02 PM: Loading World Chart Q=4 in 1 ms.
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:02 PM: gshhs ReadPoly failed
12:33:03 PM: Loading World Chart Q=3 in 0 ms.
12:33:04 PM: Loading World Chart Q=2 in 1 ms.
12:33:11 PM: Loading World Chart Q=3 in 0 ms.
12:33:12 PM: Loading World Chart Q=4 in 0 ms.
12:33:23 PM: Loading World Chart Q=3 in 0 ms.
12:33:23 PM: Loading World Chart Q=2 in 1 ms.
12:33:28 PM: Loading World Chart Q=3 in 0 ms.
12:33:29 PM: Loading World Chart Q=4 in 1 ms.
----
12:42:37 PM: Chart cache purge
12:42:38 PM: Loading World Chart Q=3 in 0 ms.
12:42:39 PM: Loading World Chart Q=2 in 1 ms.
12:42:39 PM: Loading World Chart Q=3 in 0 ms.
12:42:40 PM: Loading World Chart Q=4 in 0 ms.
12:42:48 PM: Loading World Chart Q=3 in 1 ms.
12:42:49 PM: Loading World Chart Q=2 in 1 ms.
12:42:54 PM: Loading World Chart Q=3 in 1 ms.
12:42:55 PM: Loading World Chart Q=4 in 0 ms.
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:55 PM: gshhs ReadPoly failed
12:42:57 PM: Loading World Chart Q=3 in 0 ms.
12:42:59 PM: Loading World Chart Q=4 in 0 ms.
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: gshhs ReadPoly failed
12:42:59 PM: Loading World Chart Q=3 in 0 ms.
-----

I am going to
1. Delete the Log file,
2. All Chart directories & Chart Groups that refer to gshhs or gshhg.

Pavel:

There is always only one folder with them used on your system (Which needs to be any of the directories on the Chart Files tab), the last one found when updating the chart database, regardless of being or not in a group or wherever else. It does not matter how smart you try to be, you can't do anything about it. Let the chart downloader download your GSHHG basemaps, once, do not touch anything and they will simply work. If they don't, don't touch anything and let us look at it.
This is the only way problems can be identified and fixed.

It is unclear to me what to do here. Sorry.
I am just going to delete all files in gshhs or gshhg folders.
Then restart opencpn having renamed the old opencpn.ini so that it is completely new, and start over.

[rgleason]

During Download of the GSHHG catalog, I selected the path

D:\Data-Juno\Chart\GSHHG

Pavel - Despite what you may think, a single big map, the scaling at Cape Hatteras, Cape Fear, Watch Hill RI now works.

[rgleason]

Weather_routing is working much better now. I used Gille's example files and unchecked "Detect Boundary" and did not run ODraw.

Each of the routings completed without going over land.

Thanks for getting me straightened out.

[rgleason]

Attached are opencpn.ini and opencpn.log