Marine GeoTiff - Open Chart Standard

[dacust]

We want free charts! And we want to be able to create our own charts from scanned images.

Requirements as I see them:

1. Open Source or public domain image type
2. Open source or public domain header for geo-referencing and chart info
3. Open Source or public domain calibration tool(s)
4. Usable in all navigation packages

Marine GeoTIFF (MGT) seems to be the way to go

1. tiff is a public domain image type
2. GeoTIFF is a public domain standard for using the user defined tags within the tif standard
3. There are things out there, we just need to either find one that will work, or find one we can modify, or create our own.
4. I don't think this will happen. The current standard is BSB, and that is copyrighted. So, I think we have to settle for 1-3. However, some commercial packages support types of GeoTIFF, so it may accidentally work on one here or there.

If we do this well, it may well get picked up by other open source developers and used in their navigation packages.

Some GeoTIFF links:
The main page for the geo-tif standard
That page links to this page with the specs definition
Or jump straight to the Specs contents index
You might want to start here, for some geotif tag examples

I have a feeling it may be possible to just use standard GeoTIFF tags. Example 3.2.1 shows the beginnings of what we'd probably need. These are simple examples. The GeoTIFF standard is huge and complex. All that means is we'll have to dig to find the elements we need to use. Once we identify as much as we can, we can go on to GeoTIFF discussion forums and ask questions. (I like my first post in forums like that to sound like I've done my homework.) Actually, I think I will go ahead and ask if there is already someone that does something like this. They may save us some work.

Tasks:

• Identify what information we need to display.
• Determine how that can be mapped into the GeoTIFF standard.
• Identify what information we have that cannot fit into the standard (hopefully none)
• Locate open source calibration package that will do what we need, or be a starting point.

I'll start a page on my site to document the lists we come up with.

Obviously, this will do us no good at all if no marine package uses it, so we want to work closely with Dave and make sure what we do is easy for him to support in OpenCPN. We need his buy-in at various points. So far, it sounds like he is open to the idea.

So, Dave, are you on-board with us heading down this path?

-dan

[sinbad7]

The GeoTIFF standard and implementation sounds very complicated to me as a user of limited technical ability. Surely there must be an easier way to convey the most important navigation data onto a raster image. The calibration facilities used by MapCal,Fugawi,OziExplorer and Shipplotter are quite adequate for most leisure sailors.
The whole point of OpenCPN is simplicity of use for all levels of knowledge.
We don't need a system which can only be used by the very technically endowed or having to pay someone for the job.

In any case,a simple,front end user interface in plain language should be designed,where the users can input the required data for the calculations and conversions,producing the end product chart without further intervention or technical knowledge from the user.

[dacust]

Originally Posted by sinbad7

The GeoTIFF standard and implementation sounds very complicated to me as a user of limited technical ability. Surely there must be an easier way to convey the most important navigation data onto a raster image. The calibration facilities used by MapCal,Fugawi,OziExplorer and Shipplotter are quite adequate for most leisure sailors.
The whole point of OpenCPN is simplicity of use for all levels of knowledge.
We don't need a system which can only be used by the very technically endowed or having to pay someone for the job.

In any case,a simple,front end user interface in plain language should be designed,where the users can input the required data for the calculations and conversions,producing the end product chart without further intervention or technical knowledge from the user.

I gotta run to a meeting, so this will be quick.

Under the covers, all those other methods are that complicated. They only appear simple on the surface.

The end result of what we would produce with the MGT would be as simple. And we should aim at making it even simpler.

So, first we gotta do the complicated stuff so we can provide the simple solution to the user.

-dan

[Viking Sailor]

Dan,

You may want to consider the option to cleanup/modify/correct libbsb to produce BSB charts readable by OpenCPN. It is open source C code. Once libbsb is working it should be straightforward to modify it's output to an OpenCPN unique format if desired. A GUI based upon the techniques utilized in OpenCPN would also need to be developed.

Steps:
1. Find out what libbsb is doing worng.
2. Fix libbsb to generate OpenCPN compatible BSB charts.
3. Modify libbsb to generate OpenCPN unique charts. (?)
4. Spec OpenCPN GUI calibration utility.
5. Write OpenCPN GUI calibration utility based upon OpenCPN GUI code.

Dave can maybe help getting someone started with step 5.

Paul

[sinbad7]

Dan..

I was hoping you'd say that..
Let the programers create the code necessary but don' forget to create a simple user interface for us mere mortals... Thank you for your initiative and your tenacity in solving this conundrum.

[idpnd]

I concur with Dan's purist demands as to the intellectual property properties (no pun intended) of the chart format, to ensure legal certainty (of the format at least..) and thus futureproofness. Wasn't the KML format under discussion a while ago?

[dacust]

Originally Posted by Viking Sailor

Dan,

You may want to consider the option to cleanup/modify/correct libbsb to produce BSB charts readable by OpenCPN. It is open source C code. Once libbsb is working it should be straightforward to modify it's output to an OpenCPN unique format if desired. A GUI based upon the techniques utilized in OpenCPN would also need to be developed.

Steps:
1. Find out what libbsb is doing worng.
2. Fix libbsb to generate OpenCPN compatible BSB charts.
3. Modify libbsb to generate OpenCPN unique charts. (?)
4. Spec OpenCPN GUI calibration utility.
5. Write OpenCPN GUI calibration utility based upon OpenCPN GUI code.

Dave can maybe help getting someone started with step 5.

Paul

You must not be aware, we already have a method using libbsb that produces OpenCPN readable BSB charts. See the mc2bsbh thread. I have produced a few hundred charts from the Terraserver, and several people have produced dozens of marine charts.

We could come up with our own hybrid format, but it seems to me that since GeoTIFF is partly (possibly all the way) there already there, we might as well take the easy way out and use it.

Dave can give us an idea if one way or the other will cause more work on his part.

There is a libtiff and libgeotiff (sp?) to facilitate reading and writing tiff and geotiff tags.

The KML idea may or may not be better. Frankly it's a little over my head, so I am not the person to make that decision. I can only give my impressions.

I think the KML idea is great for adding features, maybe kinda creating our on vector objects?

But it seems to me that for raster charts, using a tried and true (1994?) public format is the better way to go.

Maybe we need both?

-dan

[cagney]

I have my doubts about using geo tiffs, based on the very slow interaction with my older hardware. For example to geo reference the NZ tiffs I have to use the "admirals" XP box, my own box with 1gig of memory and an old Athlon processor comes to a standstill.
Cropping tiffs with convert takes about 5 minutes! Don't know how this fits in with a rather zippy OpenCPN, and using hardware onboard that is not a powerhog. Just a thought.........

Thomas

[jonasaberg]

Dan and I have had an off-forum discussion with Seaclears developer about this and Dan will post some stuff in this forum later tonight. (My emails are in Swedish, easier for Dan to just repost) (se the mc2bsb thread...)

Olles main point is that GeoTIFF is a poor choice. it needs:
1. A fast decompression compression standard.
2. Needs to be able to be read in chunks to be able to be plotted/uppdated fast on the screen, aspecially on low spec hardware.

More will folllow...

/Jonas

[bdbcat]

All...

Patiently awaiting more thoughts from Ollie before I weigh in with an opinion on geoTiff for opencpn.

Dave

[dacust]

I posted Olle's reply in a new thread "Open Chart Standard". After reading his e-mail, I think it's pretty obvious that a GeoTIFF is not the best route. It may turn out to be the easiest, and who knows we may come back to it. But it would be so much better to come up with a new standard that is optimal, and not just do something because it is the easy way out.

-dan

[manimaul]

Hmmm, geotiff will also be a huge problem for file size and disk space...memory was already mentioned. My vote remains for KML/GML.

Some Benefits:
KML can be raster or vector data.
Raster tiles are typically PNG or JPG.
Open Source conversion tools exist
*see gdal2tiles

[dacust]

Originally Posted by manimaul

Hmmm, geotiff will also be a huge problem for file size and disk space...memory was already mentioned. My vote remains for KML/GML.

Some Benefits:
KML can be raster or vector data.
Raster tiles are typically PNG or JPG.
Open Source conversion tools exist
*see gdal2tiles

You should post this in the new "Open Chart Standard" thread.

I'll respond there, but to be honest I somehow didn't take KML seriously. But, embarrassingly enough, I just now for the first time googled KML standards, and a quick read tells me I had a totally wrong impression of it. It may well be what we need.

-dan