Cannot read Ozi Explorer .map files with UTM projection

[nsands]

OziExplorer .map files that have a projection specified as "(UTM) Universal Transverse Mercator" cannot be read by GDAL.

The following code results in the WKT displayed below the code, and no spatial reference can be formed from it.

UTM is of course a very common projection, so this affects a large number of Ozi .map files.

CODE:

	char *srcWKT = (char *)GDALGetProjectionRef( hSrcDS );
	
	if ( srcWKT == NULL || strlen(srcWKT) <= 0 )
		return NO;
	
	printf("srcWKT:\n\n%s\n\n", srcWKT);

	OGRSpatialReferenceH srcSRS = OSRNewSpatialReference(srcWKT);
	
	if ( ! srcSRS )
	{
		printf("FAILED TO GET SOURCE SPATIAL REFERENCE SYSTEM.\n");
	}

WKT:

LOCAL_CS[""Ozi" projection "(UTM) Universal Transverse Mercator"",UNIT["Meter",1]]

Some example .map files are attached. (They can be paired with any .ozf2 file by changing the extension of the file name at the end of the path in the .map file to .ozf2 and changing the name of the .ozf2 file to match that in the .map file.)

[nsands]

Some example .map files with UTM projection

[warmerdam]

I took a brief look, but I don't have any ozi files to pair the map's with, so I gave up.

[nsands]

Sample .ozf2 file. Rename it to match the file name in the path of the .map file (and change the extension in the .map file to .ozf2)

[jcrepetto]

I have looked at the GDAL source code, and found that the "(UTM) Universal Transverse Mercator" projection is not supported. If nobody else is interested, I can implement it and submit a patch.

[jcrepetto]

Patch for UTM support in OziExplorer .map files

[jcrepetto]

I have attached to this ticket a patch to add the UTM support. Note that I had to create a new function :

OGRErr OGRSpatialReference::importFromOzi( char **papszLines, int nLines )

because this one :

OGRErr OGRSpatialReference::importFromOzi( const char *pszDatum,
                                           const char *pszProj,
                                           const char *pszProjParms )

was missing necessary data from the .map file (for example the UTM zone).

I have not removed the old function, because it would break the API. It will be possible to remove it in GDAL 2.0.

[Even Rouault]

Jean-Claude,

I've committed your patch in r25256 with a few changes.

For consistency with the rest of similar GDAL/OGR API, the signature of the new function is OGRErr OGRSpatialReference::importFromOzi( const char * const* papszLines ) (removal of nLines parameter, assuming the array is NULL terminated). And I've remapped the implementation of the old method to the new one by forging a fake array.

Question: is the removal of the following lines in gcore/gdal_misc.cpp really intended ? I assumed yes.

                if ( EQUAL(papszTok[16], "S") )
                    dfLat = -dfLat;

[jcrepetto]

Yes, the change was intended. Northings are not necessarily negative in the southern hemisphere.