One thing I've been working on expanding is the number of sonar formats the IMC can break down.

This message is to assess which formats (freely available or through explicit access rights) we can break down with the IMC application.

In the current version, we support SLG/SL2. Over the past day I added MGD77 and MGD77T. I can't convert Kongsberg, Humminbird, Garmin, etc. without explicit permission from those companies (not going to happen with direct competitors).

I'm looking for other ideas of which formats I need to support internally.

The current reference links I'm working off of now are:
www.ngdc.noaa.gov/mgg/dat/geodas/docs/mgd2000.htm
www.mbari.org/data/mbsystem/formatdoc/index.html

Meanwhile I have heared, that the data from Open Sea Map (a few depth data and navigation marks) are contained in the regular data of Open Street Map.

It would be really great, if IMC also could handle these contents, perhaps in a way that the user can choose, if these signs and bathymetric data should be processed or not.

As far as I know, they aren't directly integrated into OpenStreetMap. I kind of wish they were because being separated that like that, it's very difficult to maintain standards and piggy back off the same output formats. The rules that I put into place for processing OpenStreetMap requires commonality in the exact way that OpenSeaMap encodes their information.

I took a look at integrating and there were some minor problems with their extraction tools that I didn't have a good way to work around (like not populating bounds information for their extraction sections).

On top of that, Woso has been working on a OpenSeaMap conversion of their data objects already. If he makes shapefiles available, it would be wasted effort.

The sonar formats are just a time filler. Usually takes less than a day to incorporate a sonar format.

There are also issues with OpenSeaMap merging objects that are separated within the S57 standard. They could've gone with any naming convention and S57 has one of the best attribute/documentation systems out there but, instead, they decided to merge objects (ex. buoys and lights in a single object instead of separated like S57) and go with an attribution system that was completely different from S57 even though they were pulling 90% of their data directly from the S57 charts. By doing so, they made the attribution a bit of a mess. My application's knowledge of OSM attributes would have to quadruple to cover all the attributes OpenSeaMap added. I at least understand the reason OpenStreetMap went that direction.

I'm not sure why I would try to convert from a half baked format instead of directly from the S57 data (especially since OpenSeaMap is duty bound not to incorporate any charts that cost any money). At least with S57, you could be sure you were getting recent data and they specify a target map layer so you could create layering yourself instead of messing with a format that consists of a single layer of merged data objects.

I presume that would be free ENC data, like the ones that can be found on www.ris.eu/background/what_is_ris_/elect..._navig__charts__enc_ ?

Yes, ENC uses the S57 standard. iENC is a variation off of it using a few new types (and I think fields).

gpiverson wrote:
That would be nice if the IMC could convert these ENC directly. For example, the ENC from the south-west part of the Netherlands (Delta) even contain lots of depth readings.

My information was from WoSo ;)

Two weeks ago I met a guy from Open Sea Map at the 'Boot' show in Duesseldorf. Ahead we German Reefmaster users discussed, that I should ask about the ability to get OSeaM data for Lowrance plotters. My result from there was, that OSM only have a few depth data and the rest like navigation signs they did not collect themselves.

The second result was, that this guy wanted a simple OSM background map generated with the IMC from me ...
The answer to why he did not just generate it himself was sobering and funny.

More things about it and my thoughts should not be posted in a public forum by me ;)

To be honest, I'm not a huge fan of the way OSM decided to organize their data. It was a miracle I was able to extract anything usable out of that and the memory usage started out as a sobering 450 GB or so of RAM usage on my first attempt to parse a planet file. Since then, I've managed to get that down closer to 3 GB. I'm not sure there is anyone else in the world that processes directly from those PBF files for large regions without first converting to another database.

OSeaM following in their footsteps wasn't the most delightful news. I think it's a good idea but I honestly think they're still 3 years away from being "there".

OSeaM has produced raster tiles in the past and ran it through the IMC but my assumption is they want to focus exclusively on vector. I'm a fan of them doing it themselves first if only to show how difficult some of those formats can be to work with.

Probably the biggest problem with the format is a complete lack of scale in the data which means you have to have a very advanced form of decluttering built into the processing system.

Hi Greg,

to return to the topic , Sonar formats, rather than chart formats, I'm sure a lot of us would find it valuable if SL2 was a little more flexible. I'd welcome the ability to "chop" sl2 files into smaller sections, and also to convert directly to xtf without having to replay it in a simulator and record in xtf.
A versatile format / editor, that retained bathy data, and was capable of being easily manipulated with other applications (RM) without too many technical problems (Sonarviewer has many to overcome) would be a huge bonus.

T

The functionality is defined and is limited intentionally.

Right now, the flow is essentially: Sonar Format -> CSV/Shapefile/LSF (our local shapefile format without the restrictions). The only exported fields are Latitude/Longitude/Depth/Channel Identifier.

I have additional filters built in to the process like the ability to remove estimated or interpolated points, the ability to restrict based on data quality, the ability to restrict based off the cone angle for side scan formats that provide depths for all the across track depth soundings (SL2 is not one of them).

This question as far as potential formats is which formats we should allow to convert from. In the normal workflow, I can add XTF as a read format but I can't write to it.

I might be able to encode an SL2 splitter because there would be no format to format conversion. This could also be used as a way to strip off bands from the sonar files. The main concern with something like this is making the format any easier to reverse engineer.

Thanks Greg for the quick reply.

I can write xtf on my HDS, its interesting that there is a problem with writing xtf from an application that legitimately reads SL2 (such as Sonarviewer) ? Its perfectly possible, though time consuming, to convert SL2 to xtf on my HDS unit - I'm a little confused about exactly what the difference is !

How about adding the ability to parse and convert from raw NMEA ?

Re-reading your above comment - are you saying that the limitations and horrendous location bugs with Sonarviewer are actually intentional or are you referring to the SL2 format ?

T