[GIS] Driver error when converting MapInfo file to Shapefile with ogr2ogr

gdalmifogr2ogrshapefile

I am trying to convert a MapInfo file to an ESRI shapefile using GDAL's ogr2ogr command as described here, but I am getting the following error:

FAILURE:
Unable to open datasource `Iceland2pts.mif' with the following drivers.
  -> ESRI Shapefile
  -> MapInfo File
  -> a bunch more drivers listed...

Just to be sure I have updated my GDAL install to the latest version (1.10.1) on Ubuntu, so I'm thinking it has to do with the format of the file (due to this), but I just don't know enough about these to know what is going wrong.

Example format of MapInfo file:

VERSION 300
Charset "WindowsLatin1"
COLUMNS 0
DATA
REGION 156
 4
        -22.556955         64.777794
        -22.555510         64.782730
        -22.544556         64.779297
        -22.546009         64.777359
 5
        -22.493431         64.767670
        -22.486217         64.774597
        -22.483826         64.772453
        -22.486826         64.768799
        -22.493431         64.767670

Does the formatting look incorrect, or is something else eschew?

Thanks!

Update: Example of the possible MID header

VERSION 300
Charset "WindowsLatin1"
COORDSYS Earth
PROJECTION 1, 104
COLUMNS 0
DATA
REGION 1
19814
        -23.8252        65.7438
        -23.8289        65.7445
        -23.8355        65.7472
        -23.8421        65.7503
        -23.8477        65.7531

Best Answer

From the MapInfo site:

MIF/MID format is comprised of two files, one with an extension of MIF, the other with the same name, but the extension MID. The MIF file contains the actual points that represent the objects, while the MID file contains the text information about the objects.

The MapInfo MIF format specification notes that the .mid is optional, but the GDAL/OGR documentation refers to "a pair of .MIF + .MID files" and a quick test using a MIF with no MID shows that ogrinfo fails when the MID is missing.

It looks like your MIF is not supposed to have an associated MID (i.e COLUMNS 0) so it seems like this is a bug in GDAL/OGR. I've opened a ticket (and in only a few hours it's been fixed in trunk scheduled for release in GDAL 2.0).

Related Question