OpenCPN

[bdbcat]

gjorgensen...

The G level chart of Shelter Island does not exist in CM93_2009.

It is, however, in CM93_2003, or at least in mine.
On the other hand, CM93_2003 does not have an E or F scale chart at this location.

Are you sure that you are using the same CM93 for both versions?

I'm afraid this is another case of Forrest Gump's chocolate....

Dave

[bdbcat]

Rhoel...

I took a look at the KML file which you linked.

Straightforward lats/lons of linear ring features in this dataset. Easily assimilated.

I see no logical problem with overlaying this, or any KML file over either CM93 or the WVS dataset currently supported by opencpn.

In effect, we will be reproducing some function of Google Earth using local data as opposed to GE online geography. Could be cool...

Before I start to do any real coding, I'd like to learn more about the whole KML space.

What other types of GIS data are available as KML? What tools create KML? How does ARCGIS relate? Any photo data available?

Especially interested in photo stuff.

Background....
I have not too much interest in Google Earth plug-ins for opencpn. The simple reason: AFAIK, is that there is no interface by which an application (say opencpn) can call the GoogleEarth server and request an image at a certain lat/lon/scale. Rather, it works the other way. You run GoogleEarth and create/submit KMLs which overlay your data onto Google Earth. This seems to mean that you must be online for this to work dynamically. Of course we understand the GE business model needs to work this way. But opencpn is an at-sea chart navigator/plotter. We want no dependence on the internet for day-to-day functions, no matter how compelling.

I hope someone on the forum can show how wrong I am about this understanding of Google Earth. I'd love to be wrong on this.

So, there are my thoughts.
Comments, anyone?

Dave

[gjorgensen]

Dave,

I'm using the exact same directory tree for both. Sorry, I didn't mean to imply that this is CM93_2009. The only copy I have is CM93_2003, and that's what I'm using for both. It very repeatedly works with 1.3.0, early 1.3.1 beta versions before you introduced the zoom limit, but not with 1.3.2. I figured out how to decode the directory tree names, and I do not have an E or F level, but I do have a G that's the detailed version which loads in 1.3.0.

Yeah, with CM93 you're never sure what you're gonna get. :-)

[Viking Sailor]

Originally Posted by bdbcat

Rhoel...

I took a look at the KML file which you linked.

Straightforward lats/lons of linear ring features in this dataset. Easily assimilated.

I see no logical problem with overlaying this, or any KML file over either CM93 or the WVS dataset currently supported by opencpn.

In effect, we will be reproducing some function of Google Earth using local data as opposed to GE online geography. Could be cool...

Before I start to do any real coding, I'd like to learn more about the whole KML space.

What other types of GIS data are available as KML? What tools create KML? How does ARCGIS relate? Any photo data available?

Especially interested in photo stuff.

Background....
I have not too much interest in Google Earth plug-ins for opencpn. The simple reason: AFAIK, is that there is no interface by which an application (say opencpn) can call the GoogleEarth server and request an image at a certain lat/lon/scale. Rather, it works the other way. You run GoogleEarth and create/submit KMLs which overlay your data onto Google Earth. This seems to mean that you must be online for this to work dynamically. Of course we understand the GE business model needs to work this way. But opencpn is an at-sea chart navigator/plotter. We want no dependence on the internet for day-to-day functions, no matter how compelling.

I hope someone on the forum can show how wrong I am about this understanding of Google Earth. I'd love to be wrong on this.

So, there are my thoughts.
Comments, anyone?

Dave

Dave,

You can in fact save GE views to files for viewing offline. Please see post 175 for an example of using GE views with OpenCPN. All of the GE views referenced in the post were save to a named file for later use.

Paul

[idpnd]

Originally Posted by bdbcat

I have not too much interest in Google Earth plug-ins for opencpn. The simple reason: AFAIK, is that there is no interface by which an application (say opencpn) can call the GoogleEarth server and request an image at a certain lat/lon/scale. Rather, it works the other way. You run GoogleEarth and create/submit KMLs which overlay your data onto Google Earth. This seems to mean that you must be online for this to work dynamically.

You can download google earth images to the local cache and use the data from there. This has been demonstrated elsewhere. However, the closed nature of the GE server would mean that one would have to use GE to download the data for later usage in openCPN, which does not merit the development of a plugin IMO. Perhaps world wind, the free NASA database of satellite shots, which has free access may be of value in this context. It does not offer the level of (proprietary) aerial shots GE has however.

[Rhoel_Asia]

Originally Posted by bdbcat

AFAIK, is that there is no interface by which an application (say opencpn) can call the GoogleEarth server and request an image at a certain lat/lon/scale. ... But opencpn is an at-sea chart navigator/plotter.

I'd love to be wrong on this.

Dave

Okay, you're wrong .

Lets take one step back: The interest is not displaying live GoogleEarth overlays but displaying Pilot charts in KML format which are derived from a variety of sources ... some might come from Google but most will be built from GPS data or from ERSI shapefiles misappropriated from whichever government agency. The interest is in the KML format which appears to support high grade polygon vectored charts, features sets and the like (I'm still reading the documentation). Being XML based, open-source and the 2.2.0 now locked, KML seemed the logical format to support. In the absence of other means to create S-57/ENC charts, KML as an affordable chart importer looks very promising.

Software:
MapMaker (which comes in free and paid versions), announced it is to support KML output in the next release; ArcGIS already does - in fact, the up;oaded KMZ file came from ArcGIS 9.3, using a publicly released shapefile (originally linked from the geodjango project). The KML cam from importing the KMZ into GE, then exporting it as an um-zipped KML data file. Google, of course, also have tools for KML generation. There are others which I am still reviewing.

The biggest question is how to maintain the naming of layer for OpenCPN to identify the land, vs drying area vs lights, etc.

One option I discussed with my boss this afternoon was the possibility of writing a plug-in for OpenCPN, specifically to vector pilot charts from geoTIFFS or other uncalibrated sat-images which have 2 known trig points. This plug-in option would remove the issue over the internal naming structure of how lights, buoys and other features were marked and tagged.

The advantage of GE compatibility is its potential when on land: it can be used to overlay the new file over their data to check alignment (keeping in mind the GE tile is often out-of-alignment by 25 or so meters): If the pilotage its roughly in the right place, and not suddenly the size of a continent or appearing on Google's Mars globe or whatever, then its good enough for the nautical equivalent of VFR (visual flight rules), eyeballing the local features.

I have been tasked by the boss to work up a PDF of the workflow, the how to physically make a chart, step by step. I can post this on the server if folks will find it useful. I still have a few question unanswered, like would the chart app use layers, one for land, one for drying, another for fairways etc, basically the way ESRI/ENC charts are prepared. This seems the most flexible as its future-proofed, making updates easy. but would it cause a problem of stacked polygons - does OpenCPN need the ploys to be matched/common bordered.

From what I see, some of the core code needed already exists within OpenCPN - things such as the ability to draw on screen in the right geo-space, to add icons and to import/export track data. The hub and axle will have to be built but the wheel's already there.

But however generated, 3rd part, a plugin or a Postgre spatial database, having the KML import will be very useful.


Rhoel.

[Rhoel_Asia]

Originally Posted by idpnd

Perhaps world wind, the free NASA database of satellite shots, which has free access may be of value in this context. It does not offer the level of (proprietary) aerial shots GE has however.

Can I add one extra reason why the plug-in is a good idea. Katarina B (my Itchen 25) used to be moored in Milford Haven, West Wales. Despite her tiny size, I thoroughly enjoyed living aboard during the winter before moving her to Southampton (my home port). Whilst whiling away the winter nights, I vectored in Illustrator a berthing plan of the marina, marking out the pontoons and finger berth numbers, the waste disposal points, showers and parking areas. It took about a week to get it right.

Several people saw the print out and immediately asked for a copy - it was better than the data supplied by the marina.

Now imagine you could use it in OpenCPN, and the situation where you are approaching the marina for the first time: Marina marina control tells you to hook up at B37. Personally, I can see great comfort in having as reference a well vectored marina plan. Consider the potential of the marina itself mading the pilot and posted it on its website. Consider the advantage they are maintaining the data themselves. Considder you are trana-Atlantic voyaging and are berthed in la Rochelle and now heading to the UK: You know Falmouth Marina have the latest KML data online ... you want to download an update before setting out? I think you want.

The problem at present is the software needed to produce ENC charts is prohibitively expensive. Worse, much of the worlds marine data is maintained by governments with specific interest in commercial shipping. No Government is going to spend big bucks producing Sailing Guide to the Andaman Islands, a guide which might be used by less than a few dozen users. But an enterprising yachtie just might, providing they could afford the kit to make the chartlets. Selling online is very cheap and access worldwide.

So the interest is not in Google Earth or reproducing any of their functionality. It's all about a very versatile data format which Google Earth generously made public. The only roles I can see Google Earth playing is providing imagery as a base for personal chartlets, and for a "play-back" viewer (I use GE for overlaying Government IR imagery).

Rhoel

[bdbcat]

Rhoel....

OK, I was on a temporary thought diversion to GE overlays. This is a popular request for opencpn, always in the back of my mind. I picture cached, georeferenced raster images (sounds like BSB format, no?) which could be loaded into opencpn as pseudo-charts. Don't know how accurate is the georef, however......

Back to KML...
Features could be loaded as tagged layers. Why not use the existing S57 layer definitions? In S57 lingo, these are called object classes. They are standardized, and supported by opencpn. The list is in

opencpn/data/s57data/s57objectclasses.csv

This list indicates the name of the class, and the attributes which might be expected for that class, and the primitive type (point, line, or area)

Opencpn can also handle a class which does not appear in the list. These are seen on CM93 charts, for instance.

Regarding poly borders: opencpn considers each poly separately. Shared border line geometry is considered only in a very limited case where rendering priority is ambiguous. So, a simple fully defined KML poly, tagged as say LNDARE (Land Area) could be rendered using the same rules as are used by the S52/S57 renderer.

The poly overlap problem could be solved by tagging polys with a rendering priority. Low priority means draw this one first. Higher priority poly s will be drawn later, and overlayed.

This is giving me another idea. Opencpn's SENC file format is home-brew, as are all SENC formats. Wonder if KML could be a useful format for SENC files? Would grow the SENC file size, since it is XML human readable, and not binary. But so what?

Progress!

Dave

[slyholborn]

Originally Posted by bdbcat

For slyholborn....

Welcome aboard. Your English is fine.

There is a known problem with "Send to GPS" for Magellan devices.

This is on the list to be fixed, but since I do not own a Magellan GPS, the debugging is very slow. Occasionally I can borrow one, work on it a bit, and then have to return it. Slow progress.....

Anyway, stay tuned.

Thanks
Dave

Thanks a lot! if i can help in any way... i'll watch that with the greater interest...

[GDD]

Hi Everyone,

This quote from Dave sounds to me like a breakthrough.
However, the mystery remains about who has been updating CM93.

I just checked an area where I am 'missing' charts and sure enough there is another file with the right letter appended to the beginning of the name. For example, my 04110708.D file seems incomplete when viewed in OpenCpn, but the directory contains a file D4140708.D. It sounds like this file likly has the missing info.

In hindsight, this is not surprising. If the CM93 updates are in fact 'real' then they are much newer than any of the software (except for opencpn) being used to view them. (CmapEcs is from 1999 or so. The last version of Maxsea to support cm93/2 is from 2005 i think).

There seems to be a change to file structure that the old viewers don't know how to deal with. Its like Ms Office 2003 trying to open an Ms Office 2007 file.

Am i understanding correctly?
Is there reason to be hopeful that Dave's fix will get us the charts missing in the 'updates'?

On the other hand, whats been said about navionic charts 'missing' the same areas is very confusing and could be evidence that I'm totally wrong.

Originally Posted by bdbcat

For GDD and others...

At 49 30 N and 124 14 W, I agree that version 1.3.3 misses some charts at C-scale and better. This version of CM93 evidently uses "sub-scale" charts with a different naming convention in order to keep file sizes reasonable.

Have a look in the folder cm93/03900660/C

There are files like A4140696.C, etc. The A,B,C file name prefix is indicating a chart section, at the indicated scale. Usually, we don't see the A,B,C prefix.

First time I've seen them, and opencpn had no idea what to do with them........

I imagine the same thing will be true at many other places on the globe, as discovered by Sinbad7, et al.

Anyway, fix is straightforward, and will be present in the next Beta release, which I anticipate as about 1 week from today.

Thanks again for your focus here. This really helps wring out the bugs in a hurry.

Dave

[Rhoel_Asia]

Originally Posted by bdbcat

Why not use the existing S57 layer definitions? In S57 lingo, these are called object classes. They are standardized, and supported by opencpn. The list is in

opencpn/data/s57data/s57objectclasses.csv

This list indicates the name of the class, and the attributes which might be expected for that class, and the primitive type (point, line, or area)

I like it already. The Objects are referred to as "ObjectClass" or "Acronym".

I'll look into the priority poly layering - seems more logical than messing with co-joined boundaries.

Rhoel

[sinbad7]

I am still having strange behaviour from OpenCPN in regards to the display of AIS information in the Query boxes. Using alternatively two separate IP feeds from entirely different sources,the contents of the QB (query box) are often showing course as 555 and speed 666 and also copying itself to the next target query and will not clear until OpenCPN is re-set.

I furthermore understood that only the GREEN targets are showing ship name,callsign etc. but I am also seing YELLOW targets with full info,EXCEPT, course: 555 and speed:666 I would like to know whether anybody else are experiencing the same?

I have a set of CD's with cm93 v3-2003 which are showing charts at all possible levels and details but are unfortunately unable to use them in OpenCPN. They are however an excellent source for producing calibrated raster maps in compressed .jpg format. I wish sometime in the future that OpenCPN would also accept this type of maps.

[dacust]

Dave,

Here's an idea. Might not be a good one, because as far as I know, there is only USA data for this. And I wouldn't be surprised if it is a proprietary format (maybe Rhoel knows?)

But there are freely downloadable B&W satellite photos of the US. Also some color and topo maps. And they are georeferenced. These are from the Microsoft Terraserver.

The two pieces of software I use to download them are USAPhotoMaps and TerraFetcher. (Or download them directly from my download page. They are the last two on the list.

The main problem I see is that they are stored with multiple (thousands) of tiles in a single file. A single tile is 200x200 pixels. A single file is one tile high by 6 degrees of longitude wide. I think there is a directory embedded in this file. Also, the position, type and resolution of the file can be derived from the file name. I don't know what other software there might be for reading this. (Again, maybe Rhoel knows?)

The advantage is you download them and they stay on your disk.
Resolutions available for each of 3 file types.

• Color - 1/4 meter per pixel, 4 meters per pixel (Very limited areas)
• B&W - 1 meter per pixel, 8 meters per pixel (almost all the lower 48 states)
• Topo - 4 meters per pixel, 64 meters per pixel (almost all 50 states)

So, like I said, it may be too difficult, ar at least too much work for the audience. Don't know.

If you want a sample file, I can get you some.

-dan

[bdbcat]

Folks....

Its new Beta time for Windows users.

Download 1.3.3 Build 728 (Windows)from:

opencpnbeta

CVS at sourceforge also updated.

Total Changelog:

1. Improve AIS Target Management
2. Support Windows COM Ports above COM9
3. Improve GPS and AIS shared port selection logic.
4. Correct Route Plan Speed limit.
5. Correct handling of named waypoint in route delete logic.
6. Correct radar range ring display.
7. Implement Route Export... Right click to Export, GPX-IN to import.
8. Corrected colour schemes on some BSB charts, allowing default RGB colours if present
9. Changed Mouse Wheel Zoom logic. Now zooms centered at cursor point.
10. Correct Route Properties to display times in Days/Hours/Minutes.
11. Highlight selected waypoint in Route Properties dialog.
----------Publish Beta 1.3.3 Build 715---------

12. Improve AIS CPA Alert graphics
13. Make Wheel-Zoom-to-cursor option configurable in Toolbox->Etc
14. Correct AIS Class B decoding.
----------Publish Beta 1.3.3 Build 716---------

15. Improve search for cm93 auxiliary dictionary files.
16. Improve Route and Waypoint graphics on GPX-In
17. Correct some CM93 chart detection algorithms.
18. Implement "Measure" Tool, experimental. Right-Click->"Measure..."
19. Change/simplify linux serial port detection logic.
----------Publish Beta 1.3.3 Build 728---------


Special requests:
1. Check out all those problematical CM93 spots.
2. Comments on Measure tool. I don't personally use this tool, so I need input.

Enjoy!
Dave

[sinbad7]

OpernCPN build 728 looking GREAT!! AIS target info seems to be solved.
Will know better as I test more thoroughly tomorrow.
Great job Dave,thanks a bunch!

Tore