OGR does not open MapInfo MIF with no MID

[lpinner]

The MapInfo MIF format specification (​http://resource.mapinfo.com/static/files/document/1074660800077/interchange_file.pdf) states that the .mid file is optional (last line in spec).

OGR fails to open a MapInfo MIF with no associated MID file.

[lpinner]

MIF with no MID

[Even Rouault]

r26120 "MITAB: support reading MIF file with no associated MID file (when MIF file advertizes 'Columns 0') (#5141)"

For upstream: MITAB ticket filed at ​http://bugzilla.maptools.org/show_bug.cgi?id=2446 with the patch

[Even Rouault]

Submitted as ​https://github.com/mapgears/mitab/pull/7

[oleinik]

This decision (only check "Columns 0") doesn't meet the specification. Columns in MIF file can contain any value. But when there is no MID file, all fields are blank.

[Even Rouault]

Confused by your comment. The "Columns XXX" line indicate the number of columns (page 9 / 681 of ​http://resource.mapinfo.com/static/files/document/1074660800077/interchange_file.pdf. So when XXX = 0, no need to look for a .mid file. Do you have examples where the implementation doesn't work ?

[oleinik]

I agree that "Columns XXX" indicates number of columns. But even Columns value isn't zero corresponding MID-file is optional. In this case all fields have to be considered as empty. About it it is written in last line in specification. The simplest way to check - load such MIF-file to MapInfo.

[Jukka Rahkonen]

By reading the specification I interpret it like oleinik. If MID file is missing then MIF file should be used as if it had "Columns 0".

Meanwhile that's a good workaround to know: If you have lost the MID file, edit MIF so that it has "Columns 0" and magically GDAL finds what can be found instead of throwing an error.

[Daniel Morissette]

Given that this is what the spec says and that this behavior has been confirmed in MapInfo, then I agree that in the absence of a MID file we should still open the dataset, and if columns > 0 then we still create the fields and their values should be left blank. Now, we still need someone to implement the fix.

[oleinik]

I think mitab_miffile.cpp needs to be appended only one condition to implement this.
Current text:

        if (m_poMIDFile->Open(pszTmpFname, pszAccess) !=0)
        {
            if (!bTestOpenNoError)
                CPLError(CE_Failure, CPLE_NotSupported,
                        "Unable to open %s.", pszTmpFname);
            else
                CPLErrorReset();
            
            CPLFree(pszTmpFname);
            Close();
            
            return -1;
        }

Changed text:

        if (m_poMIDFile->Open(pszTmpFname, pszAccess) !=0)
        {
            if (m_eAccessMode == TABWrite)
            {
                if (!bTestOpenNoError)
                    CPLError(CE_Failure, CPLE_NotSupported,
                            "Unable to open %s.", pszTmpFname);
                else
                    CPLErrorReset();
                
                CPLFree(pszTmpFname);
                Close();
                
                return -1;
            }
            else
            {
                delete m_poMIDFile;
                m_poMIDFile = NULL;
            }
        }

Unfortunatelly I can't test it myself. I use compiled windows binaries from ​http://www.gisinternals.com/query.html?content=filelist&file=release-1600-gdal-mapserver.zip
Anybody can check this solution ?

[Even Rouault]

trunk r28852 "MITAB: accept opening .mif without .mif even if the .mif declares attributes (patch by oleinik + added test case, #5141)"

[Even Rouault]

Removing obsolete milestone

[Even Rouault]

Batch closing of MITAB tickets fixed in GDAL. They were kept open because not merged into MITAB separate repository, but the latter one is inactive, so let's close them definitely.