[GRASS-user] XTF reader neede - triton format for sonar

[G. Allegri]

It would be great to have a "libxtf" library. Yet I'm not such an expert C
programmer, so I can't contribute very much to it...
Anyway I'll promote the idea inside the research institue to verify if it
would be possible to support the development.

XTF is not a very simple format to parse, so for now I will look for other
formats converions to see if it would be possible to analyze my KEB datas
using the code of MBsystem.

2008/8/3 Hamish <hamish_b at yahoo.com>

> G. Allegri a écrit :
> > > I'm facing the need to process some sonar files in XTF (eXtensible
> > > Triton Format), but I can't find anything as OS to do it.
> > > Does anyone have experience with such a format?
> > >
> > > XTF References:
> >
> http://www.tritonimaginginc.com/site/content/public/downloads/FileFormatInfo/Xtf%20File%20Format_X24.pdf
> > http://woodshole.er.usgs.gov/operations/sfmapping/sonar_xtf.htm
> > >
> > > Free (as free beer) reader:
> > http://www.knudsenengineering.com/html/software/postsurvey.htm
>
> Thierry Schmitt wrote:
> > There is nothing free to read XTF format that I know of.
> > The format is freely available on triton's website. The format has
> > become a standard de facto. However it is still difficult to get a
> > really standard xtf file in between the manufacturer of sonar
> > processing software.
> > My advice would be
> >
> > 1) knowing the name of the application that acquired the sonar data.
> > 2) have a quick look at MBsystem which is the only sonar processing
> > software free as free beer!! It won't read xtf but you might find a
> > way to find a common denominator.
> >
> > I ll be glad to know how you proceed as I might be of better help if
> > you are more specific (acquisition software, sonar....)
>
>
> Hi,
>
> Some months ago I had a look at doing this, partly out of need, partly as a
> learning experience. From a search of the mailing list archives I don't
> think I posted anything public about it.
>
> I am keen to see this happen, but am stalled until our new multibeam system
> is fully commissioned and I find some funding/time/cirtical need to justify
> the effort. A motivating factor is the effort to remove all software
> dongles. To me they just represent pain, satellite phone calls in the
> middle of the night, and lost ship time+data. For zero science gain.
> grumble grumble grumble. Something similar might be said for OS lock-in.
>
>
> But sounding out a plan of action doesn't cost much, so...
>
> I had considered a few alternatives:
>
> - create a generic libxtf (LGPL?)
> - GRASS support via a new C module (without a libxtf)
> - postgis import tool
> - sqlite import tool
> - stand alone command line converter to csv or xml ascii format
>  (then shell script or python script importer to GIS)
> - volunteer to hack support for it into MBSystems (see libxtf above)
>  (then work on MBSystems -> GRASS workflow code)
>
> A hard part for me will be fighting the urge to write the prototype as
> a Matlab script and only writing enough to get what we need from our
> particular instrument. I'd hope to leverage the power of FOSS to solve
> those and create a generic solution, rather than going the lone coder
> route with code useful only to our particular setup and needs.
>
> please do add ideas+needs here:
>  http://grass.osgeo.org/wiki/Marine_Science#Sidescan_sonar_processing
>
>
> comments, criticisms, ideas?
>
> Hamish
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20080803/5e846a01/attachment.html