MIF SRS Error then Crash

[christian.ratliff@…]

The Polk County, TX roads layer, a MIF data source, imports into the wrong
location (Louisiana) when a coordinate transformation is created from its innate
type to WGS84.  I converted the file to a Shapefile via:

ogr2ogr.exe -f "ESRI Shapefile" roads.shp roads.mif roads

When I imported that file, the step where the PRJ SRS and a WGS84 SRS are passed
to OGRCreateCoordinateTransformation() results in an access violation. The
version of GDAL being used is 1.2.6 compiled with Microsoft VC 7.1.

[christian.ratliff@…]

A file with the source MIF and converted Shapefile.

[christian.ratliff@…]

This bug is associated with DeLorme DefectID #23621 and #23728.

[warmerdam]

The problem is that the false easting in the file stored in feet since
the coordinate system units are feet.   However, mitab_coordsys.cpp was
effectively treating it as always being in meters. 

I have corrected mitab_coordsys.cpp (reading and writing) to treat the
false easting and northing properly and confirmed correct operation.  

NOTE: I check the mif document and it wasn't clear on the units point.  But
I was able to confirm the approach with one other test file.  Christian also
confirmed that other software (ie. global mapper) treat the file in question
properly.

the change has been upstreamed into MITAB and committed in OGR.   I will try
and add a test in the test suite as well. 

[christian.ratliff@…]

We have the same data in both MIF and TAB formats. The MIF file works properly
following the update, but the TAB format exhibits the old problem. I should have
submitted both files at once, but the TAB file was just recently made available
to me.

[christian.ratliff@…]

The same data in TAB format.

[warmerdam]

Problem confirmed and corrected in mitab_spatialref.cpp. 

Fixed upstream in MITAB package, and in GDAL/OGR CVS head.