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 <[EMAIL PROTECTED]> > 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 > > > > > >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
