Open Chart Standard

[dacust]

Let's try to spell out what we want to accomplish.

My Goal
My goal is to be able to take a raster image, geo-reference it, and be able to display it in (at least) OpenCPN. And I should be able to post and freely distribute that result with no legal problems.

In other words, I want to do what we are doing right now with mc3bsbh, but be able to distribute the results.

That's my goal. -- What's yours?



The idea of vectorizing raster charts is a great thought, but at least at this point, I don't think that should be the direction. As Rhoel points out, that would be a huge programming effort.

Creating a new open source graphics format that will load portions quickly and decompress fast also sounds good. But, that's also more complicated than my abilities. Olle has said he does not have much time to devote to this. But he seems more than willing to offer his suggestions and expertise. If there is someone in here with the programming expertise to handle this, I think it would be awesome. And I'll pitch in where I can.

If that can't be done, I think we need to find an existing graphics format that will work for us. Maybe what we have to do is go the "world file" route. Have the image and an accompanying text file with the geo information.

Basically, it doesn't require a new format or vectors to meet my goal. But it's exciting to think about, and if it could be done, way cool. But if not, if it'll just work, I'll be happy.

If we go down a route that is out of my league, I'll still be happy to write all the little utility scripts, etc. that I can. I'll host downloads, documentation, discussions, etc. on my website. In short, I'll contribute what I can.

-dan

[jonasaberg]

Barnakiel,

I think what Rhoel talks about is taking a raster chart, have an algorithm (a method) that finds all the shore line and depth curves, all grounds and shallows, all the lighthouses and markers, all the wrecks and all other things we know how to interpret using our eyes.

Then use the algorithm to automaticly generate mathematical expressions and functions that recreates all that information.

This is a daunting task and I think this is done today when vector charts are created - just that hords of operators are checking the "automaticly" generated charts and add all the things that are missing and corrects everything that goes wrong. This is why sometimes the vector charts are terribly wrong. There have been many examples of this presented in the boating magazines.

I just dont think this is within reach for us.

My interest is on the same level as Dans. I want something that works and is legal. Even if this in my case is mostly about scaning the charts I own. I would get away with MapCal+mc2bsbh+tif2bsb but I fully support the idea with an open format.

Maybe Olle could comment on whether it would be possible to use png, an open bitmapped palet format with very good (and open) compression.
Would it be possible to add the ability to load it in chunks and add pointers within it?
Would it be be possible to interest the png crowd in this, would they be interested in adding something to png to make it possible to calibrate it?

We probably need to link up some experienced graphic format guru, someone like Olle but with more spare time... ;-)

/Jonas

[barnakiel]

But vectors are not made like that ....

I think the two things any plotter should have are:

1) compatibility with some (preferably many) present standards (say C-map, BSB, navionics, you name it), and
2) compatibility to work with geo-referenced bitmaps (bmp, tiff, jpg, you name it) - to be able to use aerial photography, screen dumps, scanned charts.


And off we go.
b.

[idpnd]

I feel Rhoel went a bit over the top on autoconverting raster to vector charts, according to the definition below, KML appears to be perfectly fine for georeferencing raster images:

The KML file specifies a set of features (placemarks, images, polygons, 3D models, textual descriptions, etc.) for display in [...] any other 3D earth browser (geobrowser) implementing the KML encoding.

Compression is not a problem either:

KML files are very often distributed in KMZ files, which are zipped files with a .kmz extension. [...] The contents of a KMZ file are a single root KML document (notionally "doc.kml") and optionally any overlays, images, icons, and models referenced in the KML including network-linked KML files.

Would someone comment on the feasibility of displaying graphical images (non-vector) using this or indeed any other open format in opencpn?

[Rhoel_Asia]

Originally Posted by idpnd

I feel Rhoel went a bit over the top on autoconverting...

moi, finding the most difficult solution?!

In case I didn't make it clear, images can be used - my concern was the 256 tile approach as mentioned in an earlier post - KML is very flexible and I have not seen any such limitations before - I might be wrong here but my suspicions are it's a application specific approach. I have archaeological KML data here with 3meg+ images ... none are divided into 256 tiles.

Originally Posted by idpnd

Would someone comment on the feasibility of displaying graphical images (non-vector) using [KML] ... in opencpn?

Very feasible - the KML image is geo-referenced, scaleable and rotatable. How Dave impliments the KML format is something only he can comment upon. But its possible to take a non-referenced aerial image, scan or whatever and add coordinates, adjust the scale and angular numbers until it matches WGS84. That can already be done in Google Earth free versions - check the Add Image Overlay button/help. Note: Using the image transparency control makes it much easier to line up on known ground objects.

Vectoring:
The reason for considering vectoring lies in their very small file size - it opens the possibility of downloading charts over mobile connections whilst at sea.

Keep in mind Flash vectorizes raster images, creating tiny files from big bitmaps. Their approach is different, not tracing lines but converting into colour areas. There is no error involved that way. No idea if any of their codec are public or based on public algorithms.

Fundamentally, the use of KML in OpenCPN as the default open format has my vote ... from a programming point of view, it's very accessible.

But its a very big coding approach - KISS is probably best.

One thing which is worth considering is building a public collection here of legally distributable free OpenCPN ready charts for download. I have had real difficulty in finding any detailed ENC for large parts of the world (read pretty much anywhere outside the USA).. Be good to have a pooled library of legal material.I have servers/rack space if its needed.

Rhoel

[idpnd]

Originally Posted by Rhoel_Asia

One thing which is worth considering is building a public collection here of legally distributable free OpenCPN ready charts for download. I have had real difficulty in finding any detailed ENC for large parts of the world (read pretty much anywhere outside the USA).. Be good to have a pooled library of legal material.I have servers/rack space if its needed.

Wouldn't it be nice [insert beach boys song] I think the (re)distribution rights for the charts would have to be ascertained first.. If you consider the issues the xtides developers have compiling tidal information distributing such data seems to be a legal minefield..

How about world files? Can be georeferenced using this open source java tool from google and seems to be easily converted to/from KML/Z.

I also ran into this tool for comparing projections of maps.

[Rhoel_Asia]

Originally Posted by Rhoel_Asia

I might be wrong here but my suspicions are it's a application specific approach.

Just checked the manual - its the requirement for <ImagePyramid>, the default is 256 thought 512 pixels are recommended. Its the Google Earth requirement for displaying very large images.

Details of the KML PhotoOverlay including code is Adding PhotoOverlays - KML - Google Code

Rhoel

[manimaul]

Rhoel, as always, great input from you. Welcome back. Just to clear things up for others...KML can be both raster and/or vector, one or a hybrid of both as layers. Rhoel, you seemed curious about raster 512x512 tiles, so I'll post an example for you and others to check out. Open with google earth or any kml app.

NOAA raster chart 18450_1.KMZ as raster only KML
(How to BSB to KML raster charts via comand line here or gui here)

Comparison:
18450_1.KAP = 4,071 KB
18450_1.KMZ = 4,788 KB (512X512PX JPG tiles)

Everybody likes screenshots:
RASTER EXAMPLE (conversion process documented...links above):


VECTOR EXAMPLE (conversion process in active development):

[dacust]

Manimaul,

Could you post a description of how that was done? Manual processes, automated parts, etc?

-dan

[idpnd]

Looks great mani..

Also cf capcode, they have implemented nasa worldwind for a 3D view within their nav suite..

[manimaul]

Originally Posted by dacust

Manimaul,

Could you post a description of how that was done? Manual processes, automated parts, etc?

-dan

Dan,

There are two ways to make these raster conversions.
Via command line: howto link
Via gui: gui software link

The vector chart conversion was also done with gdal using the ogr2ogr utility converting s57 to kml. Then manually manipulating the output. I'm working on automating this process.

[Rhoel_Asia]

Originally Posted by manimaul

The vector chart conversion was also done with gdal using the ogr2ogr utility converting s57 to kml.

Manimaul, can gdal/ogr2ogr convert shapefiles (.shp) and/or KML to S57?

[manimaul]

Originally Posted by Rhoel_Asia

Manimaul, can gdal/ogr2ogr convert shapefiles (.shp) and/or KML to S57?

Unfortunately no: OGR Vector Formats

gdal is pretty amazing... you mentioned that you use FME. FME uses gdal under the hood as does Opencpn.

[Rhoel_Asia]

Originally Posted by manimaul

Unfortunately no:

I guess that would have been too easy :-) Thanks for the link.

[manimaul]

You might be interested...I just discovered libs52, part of the openev project.

info:
S-57 data - GRASS-Wiki

I wonder if opencpn is using some of this code?