OpenCPN

[blubaju]

Originally Posted by Rhoel_Asia

Just a quick thought - is there a need for a man-over-board button/icon?

Rhoel

Hope never, but would be nice to have, but to be really helpful it should be triggered by a remote knob every one can reach (cockpit) or maybe two (saloon) or three (depends on the size of ship), but yes, why not start with the first one right from keyboard ?

If it can be remotely set it could easily be upgraded with any kind of overboard sensor, but this then is not an openCPN problem any more. The GPS personal EPIRBS might work fine in US and western EU, even in Greece they might not come for rescue already, the more in Africa or Southern Pacific. Fastest rescue can always be done from the own ship, a direction finder set on the homing frequency of the PLB helps a lot (had this on my last catamaran, unfortunatly sold with boat). Now if that direction finder could tell openCPN where to go,... ok, I stop dreaming

Henry

[bdbcat]

All....

On the keyboard, <CTRL-Spacebar> will drop a MOB mark at the current GPS (own-ship) position. Hard to see with the ship icon blocking it unless you are moving.....

Thanks for all the good reports on 728.


Next Feature: Ideas on Track recording solicited. Separate toolbar button to start/stop? Save as GPX by name? Other considerations?

Dave

[Viking Sailor]

Dave,

Congratulations on a great version of OpenCPN. Well done!

What are your plans for supporting different geodetic datums? Geodetic datums define the size and shape of the earth and the origin and orientation of the coordinate systems used to map the earth. Hundreds of different datums have been used to frame position descriptions since the first estimates of the earth's size were made by Aristotle. Datums have evolved from those describing a spherical earth to ellipsoidal models derived from years of satellite measurements. Datum shifts resulting from interpreting latitude, longitude, and height values based on one datum as though they were based in another datum can cause position errors in three dimensions of up to one kilometer. Not having the correct datum could result in OpenCPN displaying a vessel moving across land instead in the water.

The standard datum for GPS charting is WGS84. Outside of the US many charts are based upon datums other then WGS84. There are algorithms that can compute the offsets needed to convert from one datum to another. These algorithms tend to be computationally intensive and require a database describing each datum. Open source software is available for performing the datum comversions.

The datum conversion code GEOTRANS (Geographic Translator) is an open source application program which allows you to easily convert geographic coordinates among a wide variety of coordinate systems, map projections, and datums. GEOTRANS runs on Microsoft Windows (95, 98, NT, 2000, XP), Linux and UNIX Motif environments.

Another method to correct for datum shift is to manually enter the latitude and longitude offsets. These offsets have the effect of moving the chart so that the GPS positon of vessel is correctly positioned on the chart. In other words, the chart datum is corrected to WGS84.

It may also be possible to send commands to the GPS receiver to select a different datum. This function may not be available on all GPS receivers or for all installations.

Thanks again for a great application,

Paul

[bdbcat]

Viking Sailor....

Opencpn handles datum shift by reading the chart datum from the chart meta-information in its header. Then, we use a Molodensky Transform to convert GPS positions to the native chart datum for drawing on the screen. This transform takes advantage of well known ellipsoids, and can support many, many different datums. It works by calculating offsets. which are simply applied to the GPS lat/lon. We don't care about elevation.

The assumption here is that the GPS will always be set for WGS84, and that the transform is done in opencpn plotting.

To be honest, I have only seen a digital chart with one datum that is not effectively WGS84. I saw "European 1950" on an old French BSB 1 chart. This is what motivated the inclusion of the conversion algorithms in opencpn.

Do you know of any other datums commonly seen on digital charts?


There is of course a potential problem here. If a user wants to manually plot points from a GPS onto a non-WGS84 paper chart, it is common to set the GPS to perform the conversion. If that same GPS feeds opencpn, there will be double offsets applied, with resulting wrong position results.

Not sure how to handle this problem..... Ideas?

Thanks for the info
Dave

[Viking Sailor]

Dave,

I understand what you are doing with the datums. Can you confirm that you are getting chart datum info from the CM93 charts? I am fairly sure that the charted positions for Mexico are not to WGS84 datum.

Thanks,

Paul

[bdbcat]

Viking...
I'll check

Dave

[sinbad7]

Dave.. Would it be possible/preferrable to give the AIS Report age in the format 22:11:35 UTC rather than in seconds? I presume it means the time received the last message? I am no sure what Recent report period means?

I have also tried setting the lost target deletion in the toolbox AIS section to any variable but the old targets still remain?? I presume this means lost targets are marked as such an/or deleted after the specified time period?

[gjorgensen]

I think you need a separate toolbar button that toggles tracking on/off. I'd add a check box in the "Etc" config tab to enable/disable the Tracking button. As you suggest, save them the same way you save routes, i.e. right-click on the track to save as GPX by name, and the big GPX Out toolbar button would dump all routes and tracks into the same file. I don't think the UI needs to be more complicated than that. You can always use something like GPSUtility to edit/merge/whatever the route and tracks outside of openCPN if you need.

Probably the only consideration is the number of track points you can save and the frequency with which you save them. If you can have an essentially unlimited buffer, then I'd just fix it at something like one point every 10 seconds or 10th of a mile. If there's a reasonably small fixed size limit to the buffer, it would be nice to make the track point frequency, in terms of time and distance, user configurable. I can see a need for very long multiple day tracks that can tolerate lower resolution (but which can certainly be high resolution if the buffer is very large), and also short high resolution tracks. At a 10 second resolution you're looking at 8640 track points per day, so if the buffer can be something like 100,000 track points you could just fix the interval and not even make it configurable.

Each track point should include Lat/Lon, COG, SOG, and time/date

Originally Posted by bdbcat

All....

Next Feature: Ideas on Track recording solicited. Separate toolbar button to start/stop? Save as GPX by name? Other considerations?

Dave

[phiggins]

Dave,

I have another request: add a logbook feature similar to the one in SeaClear. In SC you simply press F7 (or CTRL-L) and up pops a message entry box where you enter anything you like and when you press enter it logs an entry to a .TXT file (LOGBOOK.TXT) that contains the time, your position, the total NM and the text you entered, two examples:

7/30/2009 3:14:22 AM, 38°55.963'N, 074°51.552'W, 0.00nm, Leaving Cape May
7/30/2009 3:16:35 AM, 39°06.153'N, 074°35.628'W, 40.00nm, Passing Avalon Shoal

It also has the capability to automaticall log certain events like the program starting or stopping, a way point reached, etc.

From this data it is very easy to create a KML file that can be loaded into Google Earth to send to anyone who is interested in tracking your voyage.

[phiggins]

BTW Dave, your new build looks good but I still get the exception while running the AIS simulator. Be glad when you can give me the build data for Visual Studio so I can create a DEBUG version so I can give you more information on where the error is occurring.

[bdbcat]

Viking Sailor....

It appears that the geometry of all features in CM93 has been adjusted by the database compiler to WGS84 datum within the database, so that when drawn the chart cell is properly registered automatically.

For information, the cell metadata also indicates the source of the data, which is sometimes not WGS84.

You can inspect this by turning ON META Objects in Toolbox->Vector Charts
and looking at the M_COVR object.

I have not yet written the code to look up the attributes and convert to readable strings, so bear with me here.

HORDAT (2) implies WGS84

_sorhd(?) indicates the Source Horizontal Datum

_wgsox, _wgsoy are offsets in meters that have been applied to source data.

Check out LeHavre in France, 49 30.0N x 000 4.0W, CM93 2003 Scale D
This has _sorhd = (3) which decodes as European 1950 (European Datum).

At this location I did careful checks of the buoy defined location vs the apparent charted location, and can find no discrepancy.

Are there other areas in the world that we should study, just to be sure? I don't find too many non-WGS84 sources in the 2009 dataset....

Thanks for the question. All very interesting.....
Dave

[Viking Sailor]

Dave,

Did a random sample and found the following locations where lights are charted to a datum other then WGS84:

28 02.708 N 115 10.954 W
Attributes
CSCALE (511500)
_dgdat (19981008)
SORIND (21005)(US NGA graph 21005)
_chcod (21-05650)
_quart (4)
NMDATE (20090502)
MARSYS IALA B(2)
RECDAT (20090510)
HORDAT (0)

24 35.549 N 110 23.566 W
Attributes
CSCALE (667680)
_dgdat (20010801)
SORIND (21014)(US NGA graph 21014)
_chcod (21-01950)
_quart (4)
NMDATE (20090502)
MARSYS IALA B(2)
RECDAT (20090510)
HORDAT (0)

00 45.393 S 090 16.687 W
Attributes
CSCALE (60000)
_dgdat (19990930)
SORIND (22528)(US NGA graph 22528)
_chcod (20-03440)
_quart (4)
NMDATE (20090425)
MARSYS IALA B(2)
VERDAT Mean low water springs(1)
_hvdat (16)
HORDAT (0)
RECDAT (20090511)

27 09.962 S 109 21.998 W
Attributes
CSCALE (100000)
_dgdat (20060919)
SORIND (GB UKHO graph 1389A)
_chcod (50-0A96A)
_quart (4)
NMDATE (20090430)
MARSYS IALA B(2)
_hvdat (17)
HORDAT (0)
RECDAT (20090511)

03 51.262 N 159 21.941 W
Attributes
CSCALE (1728000)
_dgdat (19990628)
SORIND (83015)(US NGA graph 83015)
_chcod (50-04000)
_quart (4)
NMDATE (20090425)
MARSYS IALA A(1)
HORDAT (0)
RECDAT (20090511)

18 37.738 S 174 04.293 W
Attributes
CSCALE (73360)
_dgdat (19991028)
SORIND (8234)(NZ LINZ graph 8234)
_chcod (50-08110)
_quart (4)
NMDATE (20090417)
MARSYS IALA A(1)
_hvdat (17)
HORDAT (0)
RECDAT (20090511)

21 03.316 S 167 27.238 E
Attributes
CSCALE (302900)
_dgdat (20050209)
SORIND (6686)(FR SHOM graph 6686)
_chcod (50-04740)
_quart (4)
NMDATE (20090425)
MARSYS IALA A(1)
_hvdat (3)
RECDAT (20090510)
HORDAT (0)

01 57.126 S 147 19.855 E
Attributes
CSCALE (750000)
_dgdat (19970717)
SORIND (462)(AU AHS graph 462)
_chcod (50-07920)
_quart (4)
NMDATE (20090410)
MARSYS IALA A(1)
_hvdat (20)
HORDAT (0)
RECDAT (20090511)

09 05.115 N 123 15.761 E
Attributes
CSCALE (1550000)
_dgdat (20040607)
SORIND (943)(GB UKHO graph 943)
_chcod (31-03650)
_quart (4)
NMDATE (20090430)
MARSYS IALA A(1)
_hvdat (17)
HORDAT (0)
RECDAT (20090511)

00 18.102 S 104 59.916 E
Attributes
CSCALE (800000)
_dgdat (20040323)
SORIND (1312)(GB UKHO graph 1312)
_chcod (50-06830)
_quart (4)
NMDATE (20090430)
MARSYS IALA A(1)
_hvdat (21)
HORDAT (0)
RECDAT (20090511)

16 37.112 N 039 19.588 E
Attributes
CSCALE (700000)
_dgdat (20090429)
SORIND (7099)(FR SHOM graph 7099)
_chcod (30-05720)
_quart (4)
NMDATE (20090425)
MARSYS IALA A(1)
_hvdat (19)
HORDAT (0)
RECDAT (20090511)

25 35.169 S 045 08.830 E
Attributes
CSCALE (1000000)
_dgdat (20061220)
SORIND (760)(GB UKHO graph 760)
_chcod (41-01850)
_quart (4)
NMDATE (20090430)
MARSYS IALA A(1)
_hvdat (17)
HORDAT (0)
RECDAT (20090511)

05 47.439 N 055 53.503 W
Attributes
CSCALE (300000)
_dgdat (19950704)
SORIND (24370)(US NGA graph 24370)
_chcod (21-00550)
_quart (4)
NMDATE (20090502)
MARSYS IALA B(2)
VERDAT Low water springs(9)
_hvdat (3)
RECDAT (20090510)
HORDAT (0)

One of the above for Baja was about 1/2 NM out of position. I'm sure that there are many more like the above.

Is there enough info in the Meta data to correct the charts to WGS84?

Best Regards,

Paul

[idpnd]

Originally Posted by phiggins

It also has the capability to automaticall log certain events like the program starting or stopping, a way point reached, etc.

From this data it is very easy to create a KML file that can be loaded into Google Earth to send to anyone who is interested in tracking your voyage.

+1 for complete logging of track (with annotation?), I would consider this as an always-on feature, similar to a flight recorder in aviation. The package geohist provides direct logging of gps output to a database, which provides the exact function described.

[bdbcat]

Viking Sailor...

Paul:
I took a look at one point you mentioned. Lets compare notes and see if we have the same understanding.

At Morro Redondo, on Cerro de Cedros, Near Cabo

CM93 May 2009
The light tower.
by opencpn Object Query

Chart scale B
position: 28 02.708 115 10.954
Compilation Scale 511,500
HORDAT (0) undefined

Chart scale C
position: 28 02.606 115 10.974
Compilation scale 300,000
HORDAT(2) WGS84

Now, then, where is the lighthouse?

I would judge that the lighthouse is closer to the position indicated by the C scale chart, since the M_COVR on this chart is explicitly WGS84, and it is a finer scale chart

How do we interpret the B scale chart, then?

It seems clear that the cartographer did not use any kind of common database for feature locations.

Using the cartographers rule of thumb, the accuracy of charted features is roughly 1.5 mm at the compilation scale. So, this means that the implicit accuracy of features on this B chart is about

.0015m * 511,500 = 767 meters = .44 NM (Half a mile!!)

The Query position on the B scale chart is within 0.44 NM of the stated position on the C chart, so all is at least consistent.

If you mouse around on the B scale chart, the positions indicated in the opencpn status bar are accurate to within 0.44 NM.

To look more closely, drop a mark near the lighthouse, then edit its properties to be the same as the Query values obtained from the C chart, i.e. the presumably more accurate.
Then zoom out to the B chart. The mark will be a few pixels off, but maybe close enough for a B chart.

I conclude that the B scale chart was simply digitized from an old paper chart, and is accurate enough for a B scale chart.

Here is our old friend overzoom come to call again.

I occasionally play around with the idea of rendering all the features that I have access to on vector charts, as well as the ownship symbol, routes, waypoints, etc. in a kind of "fuzz-ball" graphic, trying to indicate the uncertainty of position. Could also incorporate the current GPS LDOP values. This would be really scary....

So, to answer your question.
I think that a cell that has an indeterminate HORDAT and _sorhd cannot be further corrected, and should be considered to be no better than the large paper chart it came from.

Comments?
Dave

[Viking Sailor]

Dave,

When using a GPS receiver with paper charts it is necessary to select the same datum for the GPS receiver as is used by the paper chart. This datum selection insures that the latitude and longitude displayed by the GPS receiver uses the same coordinate system as used for the paper chart. Otherwise, when the GPS position is plotted on the paper chart it is likely to be in error.

When using a GPS receiver with electronic raster or vector charts it is still necessary to insure that they both use the same datums. As with paper charts it is possible to set the GPS receiver to the native datum used for the electronic chart. It is also possible to leave the GPS receiver set to its standard (WGS84) datum and convert its output to the native chart datum in the electronic chart display. A third way to insure that the GPS and chart datums are the same is to convert the electronic vector chart from it native datum to the standard WGS84 datum as necessary and when possible in the electronic display.

It appears that most electronic vector charts already use the standard WGS84 datum, are being converted to WGS84 when updated, or can be converted to WGS84 in the electronic chart display. Furthermore, since CM93 is the closest thing we have to a free worldwide vector chart database, and the U.S. vector charts are also free perhaps OpenCPN development should focus on making the available vector chart as usable as possible.

As you have indicated there is not much that can be done to improve the accuracy of the CM93 charts. This is way I suggested the implementation of a manual datum offset function to OpenCPN. Where the latitude and longitude offsets are applied to the vector chart being displayed. This way the waypoints and the MOB position will be remain in WGS84 coordinates. I don't think that there is any other way to fix datum problems in CM93 due to their lack of datum info.

The idea behind the manual datum offset function is that you compare the real world with what is being displayed and correct the display to match the real world. Say your real world has you between two channel bouys and about a third of the way into the channel from the port bouy. Your chart display on the other hand has you ploughing up the beach. You turn on manual datum offset and use two spin wheel controls to move to the correct position. It would be nice if these controls could take effect in real time.

If you get a chance you might want to check out Fanning Atoll at 03 51.262 N 159 21.941 W. There is nothing WGS84 about this spot. It even looks like the light moves from the point into the passage. The B level chart meta data does not seem to have any datum info. However, the E level chart meta data has a parameter _hvdat(17). Could this indicate the charts datum?

Thanks for your time, efforts, and consideration.

Paul