Request to add a driver for blx files to the SVN

[henjo]

I wrote a GDAL driver for the topographical data format used by Magellan GPS devices called 'blx'. The driver has both writing and reading functionality. I sent an announcement about it to the gdal-dev mailing list for quite a long time ago and it is quite stable. I now would like to include it in the main gdal tree if possible.

The license was before LGPL but was changed to MIT/X to comply with the license of GDAL.

Best regards,

Henrik Johansson

[henjo]

zipped BLX directory

[Even Rouault]

I've looked quickly at the source (only looked, not even compiled) and there are a few things that you should fix before it is included :

• the todo about get_double/put_double. You can use CPL_SWAP64PTR to swap bytes. You must take into account the endianness of the running CPU too.
• you should replace the standard I/O functions (fseek, fopen, , etc...) in blx.c by their VSI equivalents (VSIFOpen, VSIFSeek, etc.)
• you should replace malloc/free by VSIMalloc/VSIFree
• errors / warnings should be reported by CPLError(CE_Failure/CE_Warning, ...) instead of printf
• debug messages should be reported with CPLDebug("BLX", ...) instead of printf

Could you also point a URL or attach some dataset so that we can test the driver a bit ?

[henjo]

Thanks for looking into this. I have tried to fix all the issues you pointed out. Replying to rouault:

I've looked quickly at the source (only looked, not even compiled) and there are a few things that you should fix before it is included :

• the todo about get_double/put_double. You can use CPL_SWAP64PTR to swap bytes. You must take into account the endianness of the running CPU too.

I didn't want to include anything gdal related in blx.c to leave the possibility to use it in other applications so I couldn't use CPL_SWAP64PTR. But it should be fixed now.

• you should replace the standard I/O functions (fseek, fopen, , etc...) in > * you should replace malloc/free by VSIMalloc/VSIFree
• errors / warnings should be reported by CPLError(CE_Failure/CE_Warning, ...) instead of printf
• debug messages should be reported with CPLDebug("BLX", ...) instead of printf blx.c by their VSI equivalents (VSIFOpen, VSIFSeek, etc.)

The VSI,CPL equivalents are now used in blx.c if GDALDRIVER is defined at compiletime. It is defined from the makefile

Could you also point a URL or attach some dataset so that we can test the driver a bit ?

I included two blx files in blx2.zip file, one big and one little endian

Best regards,

Henrik

[Even Rouault]

From a legal point of view, can those files be distributed into gdalautotest suite ?

[Even Rouault]

Driver added to trunk in r14029.

I did a few changes. As I wasn't sure of the portability of VA_ARGS, I just create BLXdebug0, BLXdebug1, etc... macros. I replaced blxopen(...,...,"r") by blxopen(...,...,"rb") I changed BLXRasterBand::GetNoDataValue to set *pbSuccess to TRUE, otherwise the no data value is not reported.

[Even Rouault]

I precise my above commentary : "can those BLX sample files be distributed into gdalautotest suite ?"

[henjo]

Replying to rouault:

I precise my above commentary : "can those BLX sample files be distributed into gdalautotest suite ?"

No, the samples were generated from commercial software so I guess it's better to generate something from free data. I submitted two samples that comes from ASTER DEM files instead.

Henrik

[Even Rouault]

The bounding box of testdem.blx (and .xlb) is not good, as a lat/long WGS84 file :

Origin = (736143.189539877232164,6893048.123116249218583)
Pixel Size = (30.000000000000000,-30.000000000000000)
Corner Coordinates:
Upper Left  (  736143.190, 6893048.123) (736143d11'4294967318.34"E,6893048d 7'25769803799.22"N)
Lower Left  (  736143.190, 6877688.123) (736143d11'4294967318.34"E,6877688d 7'25769803799.22"N)
Upper Right (  751503.190, 6893048.123) (751503d11'4294967318.34"E,6893048d 7'25769803799.22"N)
Lower Right (  751503.190, 6877688.123) (751503d11'4294967318.34"E,6877688d 7'25769803799.22"N)
Center      (  743823.190, 6885368.123) (743823d11'4294967318.34"E,6885368d 7'25769803799.22"N)

[henjo]

Replying to rouault:

The bounding box of testdem.blx (and .xlb) is not good, as a lat/long WGS84 file :

Sorry my mistake,

I have prepared another testdems.zip with other sample files with SRTM data that should be ok.

Regards,

Henrik

[Even Rouault]

Autotest added in r14035

[Even Rouault]

In r14036, I commited a small change to use memcpy to avoid potential data alignment problems on some architectures like SPARC. See bug #2268.

Closing now.

[Even Rouault]

Memory leak fixed in blx_encode_celldata