Problems with reading OziExplorer .MAP files

[alexbruy]

Since 1.7.0 GDAL has support of OziExplorer .MAP files for gif images. But there is some problems with reading information from this files.

I upload two raster files here ​http://www.4shared.com/file/TPtnOhq1/ozi_testtar.html (~18 Mb)

Raster from folder 01_invalid translated to GeoTiff with errors (projection tags are incorrect); raster from folder 02_valid translated successfully.

Tested on GDAL 1.7.2 under Linux

[dron]

Replying to alexbruy:

Raster from folder 01_invalid translated to GeoTiff with errors

What kind of errors do you have during translation? Could you paste the full gdal_translate output?

Tested on GDAL 1.7.2 under Linux

I believe it is related to a problem fixed in r19246 which was applied to trunk only. I have ported that fix to 1.7 branch, see r19900.

Please, test whether it solves the issue for you.

[alexbruy]

Replying to dron:

What kind of errors do you have during translation? Could you paste the full gdal_translate output?

I mean gdal_translate does their work without errors. But resulting file have very strange Coordinate System tag (reported with gdalinfo)

Coordinate System is `'
GCP Projection = 
PROJCS["unnamed",
    GEOGCS["Pulkovo 1942",
        DATUM["Pulkovo_1942",
            SPHEROID["Krassowsky 1940",6378245,298.2999999999998,
                AUTHORITY["EPSG","7024"]],
            AUTHORITY["EPSG","6284"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4284"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",63],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
GCP[  0]: Id=1, Info=
          (137,80) -> (552397.625909395,6877454.68273995,0)
GCP[  1]: Id=2, Info=
          (2180,111) -> (604786.328642074,6878665.96513834,0)
GCP[  2]: Id=3, Info=
          (4222,107) -> (657157.174055164,6880684.90214696,0)
GCP[  3]: Id=4, Info=
          (105,1525) -> (552969.214251874,6840309.57656881,0)
GCP[  4]: Id=5, Info=
          (2170,1558) -> (605929.564427973,6841530.26785797,0)
GCP[  5]: Id=6, Info=
          (4233,1553) -> (658872.175142674,6843564.89943853,0)
GCP[  6]: Id=7, Info=
          (72,2971) -> (553538.985272156,6803166.23745202,0)
GCP[  7]: Id=8, Info=
          (2157,3005) -> (607069.17046574,6804396.17201715,0)
GCP[  8]: Id=9, Info=
          (4244,3001) -> (660581.74384809,6806446.22240412,0)

When I try to get information with gdalinfo from GDAL 1.7.0dev shipped with OSGeo4W, it crashes on this file with standart Windows alert "gdalinfo.exe has encountered a problem and needs to close. We are sorry for the inconvenience." gdalinfo from GDAL 1.7.2 show info without errors. Sorry for inaccurate description (English is not my native).

Please, test whether it solves the issue for you.

Thanks, I'll try it in a few days

[dron]

Replying to alexbruy:

I mean gdal_translate does their work without errors. But resulting file have very strange Coordinate System tag (reported with gdalinfo)

Well, I see nothing wrong with that. The only missing part is a proper TOWGS string for Pulkovo 42 CS, but that's not a grave bug. And looking on your files second time I see there is no problem related to the one fixed with r19900 (though that patch is still worth to go in 1.7). Everything should be fine even before r19900.

[dron]

Replying to alexbruy:

I mean gdal_translate does their work without errors. But resulting file have very strange Coordinate System tag (reported with gdalinfo)

One more thought. You probably wondering why the dataset doesn't have the Projection/Geotransformation stuff set. That's because the source image georeferenced with the set of tie points specified in Ozi .MAP file and lacks regular georeference. To get the regular raster from the unprojected source image you need to warp it.

gdalwarp -r near 200k--p41-23_24.gif 200k--p41-23_24.tif

Should do the trick. Note the nearest neighbor interpolation method, it is required because the source image has color table. To use weighted interpolations convert it into RGB before warping.

[Jukka Rahkonen]

Sample images have disappeared from the download service so I am kind of blind. By the description it looks like gdal_translate made an acceptable result.

Closing the ticket as invalid.