[GRASS-user] XTF reader neede - triton format for sonar
hamish_b at yahoo.com
Sat Aug 2 20:45:29 EDT 2008
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:
> > Free (as free beer) reader:
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....)
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:
comments, criticisms, ideas?
More information about the grass-user