CM93 v2 Charts

[stevead]

I have been using a set of CM93 version 2 charts that were given to me by a fellow cruiser the past year. These charts were supposedly updated in 2010.

There are various versions of these charts downloadable from the Internet, updated at different times (2002, 2004, 2009, 2010 etc)

On other forums, in addition to updated information being displayed on the chart, some cruisers have noted that some information has been incorrectly deleted from the charts (eg some features that are actually present and were shown on 2009 charts, are not shown on 2010 charts)

From the CM93 chart structure used by OpenCPN I have built my own quick & dirty code to parse the charts and have noticed that there are discrepancies in some charts; the number of vector, area and feature records described in the chart header does not match the number of records parsed.

I have three questions:

1. Has anyone else using CM93 charts noticed discrepencies between different updates of CM93 charts ?

2. Does OpenCPN log any discrepencies when parsing CM93 charts (actually a rhetorical question as it doesn't appear that the code correlates the header information with the number of parsed records)

3. Does anyone know how or by what process CM93 charts are being updated ? I guess the question really should be "Is their any appetite in the community to take ownership of creating a process to update CM93 v2 charts ?"

[idpnd]

Ive heard that some versions are better than others before.

The updating seems to be legacy work on older charts by Jeppersen.

There has been some appetite on community fed markup but nothing has materialised so far. Integration of an online social network for sharing navigational info certainly high on list though. Piotr has been working on an update for a markup layer that might lead the way

[dougwm10]

Hi

Can anyone help with identifying the geographical areas covered by each of the folders in CM93 ver 2 ???? - some 150 folders

and

Can anyone help with a file reader or program which can open and read the contents of the *.inf file in each of the folders in CM93 ver 2 ????

[brak]

BTW, PolarView includes a schema-driven and open (as in - should be open, but no one seems to care enough and I had no time to document it ) API to import/display/describe point items (think - points of interest).

The primary data format is technically an extension to GPX. Information pages, data etc are described by a schema (more XML).

If OpenCPN is working in that direction, I'd be glad to document/share the API. I am interested in additional sources of information, of course. Plus, it would be good to get some sort of common format for these things. GPX is doing a good job for what it was created, but it's pretty limited in scope.

Originally Posted by idpnd

There has been some appetite on community fed markup but nothing has materialised so far. Integration of an online social network for sharing navigational info certainly high on list though. Piotr has been working on an update for a markup layer that might lead the way

[cagney]

The CM93 directory contains a number of subdirectories named from
"00300000" to "04501020". These folders cover a geographical area of
40 deg x 40 deg. The first four numbers describes the latitude and the last the longitude of the SW corner of the area covered.
The key to understanding the numbers is to realize that CM93's coordinate system of the world starts at the South Pole or to be exact at lat -90 long 0 and from there proceeds North a East with a factor of 3 for each degree of lat and long.
The tile 00300000 hence covers the lat from 90S + 0030:3 = 80S to
40S and longitude from 0E to 40E.
Looking at 04501020 it brakes down to lat 90S + 0450:3 = 60N and long 1020:3 = 340E => 20W. So we have he SW corner at 60N and 20W .

This is the tile 03900840 with the SW corner at 40N x 80W i loaded all by itself.

Each of these sub-folders in turn contains folders with the individual charts. Ordered in scale from smalest to largest they are Z,A,B,C,D,E,F and G. Where Z is an overview chart and G is a harbor plan. Note that, generally, not all of these are present in each subdirectory.

Z covers 40 x 40 deg and OpenCPN typically uses 1:3.000.000 scale
A covers 20 x 20 deg and OpenCPN typically uses 1:1.000.000 scale
B covers 10 x 10 deg and OpenCPN typically uses 1:200.000 scale
down to
..
G covers 20' x 20' and OpenCPN typically uses 1:3500 scale.

This info should make it possible for users to load the part of CM93 that they are interested in. For full documentation see the OpenCPN source code or ask Dave who must know the nitty gritty details.

Thomas

[nohal]

Originally Posted by brak

BTW, PolarView includes a schema-driven and open (as in - should be open, but no one seems to care enough and I had no time to document it ) API to import/display/describe point items (think - points of interest).

The primary data format is technically an extension to GPX. Information pages, data etc are described by a schema (more XML).

If OpenCPN is working in that direction, I'd be glad to document/share the API. I am interested in additional sources of information, of course. Plus, it would be good to get some sort of common format for these things. GPX is doing a good job for what it was created, but it's pretty limited in scope.

People would care if they knew At least the one here. I'm currently working on something similar for opencpn and one of the "things" that surprised me (in a negative way of course ) is the total lack of any (documented) api to exchange anything...

Pavel

[idpnd]

Open standard API for POI trading? Sounds extremely sensible!

[diama]

thanks to Cagney for the great explanation contained in
" the world according to CM93 v2" .....this post has succinctly
answered many questions I had.

[brak]

Yep, I also thought that's unfortunate. Even GPX isn't as common as I think it should be, and not perfectly supported. Garmins Mapsource will not accept "cmt" attribute, even though it's part of a standard. Not only will it not read it, but will actively refuse to load GPX that has this attribute - that took extra work

It's a bit of a horse and carriage thing. I designed my own format because there was little else, I'd like to open it, but since no one ever asks - and documentation just isn't as much fun, it just keeps sitting there.

I'll post below a small sample of what both look like in the next message. See if this is something that may be useful, and depending on that - I'll try to document it properly.

Originally Posted by nohal

People would care if they knew At least the one here. I'm currently working on something similar for opencpn and one of the "things" that surprised me (in a negative way of course ) is the total lack of any (documented) api to exchange anything...

Pavel

[brak]

Here we go, an actual document (best viewed in "vi" ).

Documentation here: http://www.polarnavy.com/docs/poi_readme.txt
Sample schema and data here: http://www.polarnavy.com/docs/poi_sample.tar

Check it out, see if this is something you'd like to work with.

[nohal]

brak,
do you think anybody could use anything else than vi? Like emacs? Those people would have to be insane
Thanks for the sample and description, it looks very usable. Do you have any ambitions to aim at non-point objects in the future as well? Will be ugly in the GPX extensions, but doable it is...

Pavel

[brak]

Originally Posted by nohal

brak,
do you think anybody could use anything else than vi? Like emacs? Those people would have to be insane

I've been a vi/vim user for almost 20 years now. Never really got emacs (I honestly tried ).

Thanks for the sample and description, it looks very usable. Do you have any ambitions to aim at non-point objects in the future as well? Will be ugly in the GPX extensions, but doable it is...

Pavel

I considered other types of geometry. Like you said, GPX does not lend itself very conveniently to lines and polygons, though I think there may be solutions (pretend lines are tracks or routes?) Perhaps by then compatibility won't matter that much.

Personally, I think the scope of this format at least for now is POI and they are points by definition. Going into geometry we are entering less of "information exchange" and more of "chart" territory, and there are better ways to convey chart-like data than XML. The hard part with geometries is drawing them in a way that makes sense. Simply slapping polygons in order they appear in the file will likely not look anything like what user wants to see. So if this thing goes the way of charts, schema would have to become quite a bit more complex to handle visualization issues beyond "what icon to pick" etc.

In any case, I think data format should "grow organically". If there will be sufficient amount of data out there, and that data needs other geometries - I think the solution will reveal itself based on practical needs

If you decide to work with this - let me know, I'd certainly like to keep things compatible. There is a bit more to format than readme describes:

1. Updates - in the most basic case a new data entry from the same source with the same ID replaces the old one, but see below. Same goes for removing entries.

2. In addition to main body of data, there are "records" - basically sub-sets of data within main data record. They have their own ID separate from that of the main entry. They exist for two reasons:

- Updates - you can update records of a given entry independently of the entire record. I.e. you can update portions of data without touching the whole, and vice versa, you can update main record without touching sub records. This is useful where data is mapped from combined sources (like database tables or whatever), and you map one set to main body of POI, another to a specific record etc.

- Repeating fields. You can have multiple records in the main entry with the same fields. Visually I am mapping these to multiple data "groups" on the same page (like, for example, reviews for a business - each review is a record). They don't have to be visualized the same way of course, but the purpose is to convey repeated information for a single entry.

I think that about covers it - and if you are interested, I'll document these items too.

[Gypsy23]

Just used your formula to more precisely cull the CM93 charts for the region I want. It turns out there is some information needed from adjacent 40x40 blocks so individual folders will not always load properly by themselves. However, it is a simple task to add nearby folders until the area you need works. I was able to get the area of AUS and NZ from 15 master folders using only 68MB.
Thanks again.