ogr2ogr MIF recogntion.

[cruserad]

the output of a conversion program generates mif/mid files of point geometry multibeam data wish to convert to shapefile.

attempting to convert mif/mid point geometry, WGS84 DDcoordinate system to shapefile format.

using this comad string,

ogr2ogr -f "ESRI Shapefile" mydata.shp mydata.mif

I get this error msg

error 6: data keyword not found in mydata.mif  file may be corrupt.

failure:
unable to open data source with the following drivers.
(list of drivers)

here's the mif headder,

Version 3
Delimiter ","
INDEX 3
Coordsys Earth Projection 1,104
Columns 14
   Lon Decimal (11,6)
   Lat Decimal (10,6)
   Dep Decimal(7,1)
   Src_ID CHAR(8)
   Snd_datum CHAR(5)
   HYSAS_Src_ID CHAR(7)
   Eval Smallint
   Class CHAR(1)
   Adj CHAR(1)
   Surv CHAR(1)
   Trk CHAR(1)
   WG84 CHAR(1)
   Updated DATE
   Point_Type CHAR(1)
   Data
   Point  -113.793621   20.506910
     SYMBOL (49,16711680,6)

(Note indentation of keywords data, point, and symbol

Note: these mif/mid files ae accepted by FME workbench and mapinfo as working files.

[warmerdam]

Hi,

I think we will need an actual data file to test this.

Chaitanya, can you followup when the data is available.

I have added Daniel in case he has any comments.

[dmorissette]

Here is a copy of my reply to the FWTools list that explains the issue and the fix. We could possibly make the MITAB driver more forgiving, but I consider that it's an issue with the data.

The MIF driver expects the DATA statement to be at the beginning of the
line. This is also the case of several other keywords, such as the POINT
keyword for instance, and this is the way MapInfo produces its files.

If you change your MIF file to remove the spaces before the DATA and
POINT keywords then it works:

Version 3
Delimiter ","
INDEX 3
Coordsys Earth Projection 1,104
Columns 14
   Lon Decimal (11,6)
   Lat Decimal (10,6)
   Dep Decimal(7,1)
   Src_ID CHAR(8)
   Snd_datum CHAR(5)
   HYSAS_Src_ID CHAR(7)
   Eval Smallint
   Class CHAR(1)
   Adj CHAR(1)
   Surv CHAR(1)
   Trk CHAR(1)
   WG84 CHAR(1)
   Updated DATE
   Point_Type CHAR(1)
Data
Point  -113.793621   20.506910
     SYMBOL (49,16711680,6)

[chaitanya]

The header provided by cruserad has not only the DATA line but the following lines indented. So the problem doesn't end there. The indentation doesn't even serve cosmetic purposes. I consider it a problem with the data.

Daniel, is it OK if a field is named 'DATA'? Right now, unless the field rows are indented a field name 'DATA' will cause a problem.

[dmorissette]

The COLUMNS keyword specifies the number of field definitions that follow, so it is possible to fix the code to parse a file where the data field would be indented (like what cruserad provided).

My point is that it's the first time in 10 years of existence of MITAB that someone comes up with a file like this, so instead of adding complexity to the parser of the MITAB driver, I would try to encourage the author of the tool that generated this file to fix it and produce a file that looks more like what MapInfo? produces, and what the human eye would expect.

[chaitanya]

Made some minor changes for more lenience in indentation in mif file. According to the format description, indentation is not compulsory in the field entry lines.

Changes in trunk (r20160) and 1.7 branch (r20161).

Daniel, Please upstream the code to mitab library.

[chaitanya]

Modified a test code according to the test data in the trunk (r20173 and r20175)

[aboudreault]

The above patch was incomplete. After a test, only the Failure about DATA keyword not found was skipped. The features weren't read in the other functions. I've reverted that change and made another patch. Now, the lines read do not contain any space at the beginning. They are automatically skipped in the GetLine?() method.

Fixed in mitab CVS HEAD (will be in 2.0) and in gdal trunk in r20818.