#3694 closed defect (fixed)
ogr2ogr MIF recogntion.
Reported by: | cruserad | Owned by: | chaitanya |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SF | Version: | unspecified |
Severity: | normal | Keywords: | mapinfo mif |
Cc: | Daniel Morissette, warmerdam |
Description (last modified by )
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.
Change History (7)
comment:1 by , 14 years ago
Cc: | added |
---|---|
Component: | default → OGR_SF |
Description: | modified (diff) |
Keywords: | mapinfo mif added |
Owner: | changed from | to
comment:2 by , 14 years ago
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)
comment:3 by , 14 years ago
Status: | new → assigned |
---|
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.
comment:4 by , 14 years ago
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.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:6 by , 14 years ago
comment:7 by , 14 years ago
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.
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.