MapInfo MID/MIF — text-based interchange format: history and current usage

MapInfo MID/MIF is a pair of text files where geometry and attributes live in human-readable form, and which for over thirty years was the primary way to move geodata out of MapInfo Professional into any other GIS. The .mif file contains Header, Columns, and Data sections with object coordinates in plain text, and the .mid holds the tabular part as CSV. Simplicity bordering on primitive: opening the file in Notepad++ and hand-fixing an errant point was normal practice in the 1990s, and legacy engineers in municipal cadastres still do it. In 2026 MID/MIF is no longer the primary working format but a historical bridge: new projects write GeoPackage and Shapefile, yet thirty-year-old archives live in .mif. Through osm2cdr.ru you can export OSM data to MID/MIF — for example, to load the current road network into MapInfo Pro 2025 and overlay it on an archived cadastral layer from 1998.

History: MapInfo Corporation, Troy, NY, 1986

MID/MIF's history is inseparable from MapInfo Corporation's. In 1986 in Troy, NY, four Rensselaer Polytechnic Institute graduates founded MapInfo Corporation — the first commercial desktop GIS designed with business intelligence in mind rather than cartography. While ESRI was promoting Arc/INFO for government agencies and large institutes, MapInfo targeted insurance companies, banks, realtors, marketers. The pitch was simple: "take an Excel sheet of customer addresses and put them on a map."

By 1990 MapInfo for Windows was popular in the US, by 1995 — in Europe. Documentation was translated into twelve languages. The product was adopted across municipal governments, utilities, retail chain planners, and insurance underwriters as the desktop GIS of choice.

Alongside the proprietary TAB format (MapInfo Pro's native binary) the company developed the Interchange Format — a text pair .mif + .mid — specifically for data exchange with other GIS and for debugging. The format is documented in detail in MapInfo Professional User's Guide Appendix E. Against the backdrop of ESRI Shapefile (created in 1992, binary, with compromises in attribute types inherited from DBase III), MID/MIF looked more "honest": openable in any text editor, no 10-character cap on field names, full UTF-8 support (from version 7.5).

In 2007 Pitney Bowes acquired MapInfo Corporation for $408 million, and the product was renamed Pitney Bowes MapInfo Pro. In 2018 Pitney Bowes spun off its software division as a separate company, Precisely, which today distributes MapInfo Pro 2025. MID/MIF is still officially supported but as legacy interchange — MapInfo Pro's primary working format has long been TAB, and for interop with the modern world it's GeoPackage.

What's inside a MID/MIF pair

MID/MIF files are a pair with the same basename and obligatorily co-located: roads.mif without roads.mid is invalid, and vice versa. No ZIP wrappers, no binary index — just two text files side by side.

The .mif file (MapInfo Interchange Format) starts with a header:

Version 300
Charset "WindowsLatin1"
Delimiter ","
Index 1
CoordSys Earth Projection 1, 104
Columns 3
  Name Char(50)
  Highway_Type Char(20)
  Length_M Decimal(10, 2)
Data

Then feature blocks follow. Geometry is described in simple notation:

Point 4.9041 52.3676
Line 4.9041 52.3676 4.9044 52.3680
Pline 4
  4.9041 52.3676
  4.9044 52.3680
  4.9048 52.3683
  4.9052 52.3687
Region 1
  4
  4.9041 52.3676
  4.9044 52.3680
  4.9048 52.3683
  4.9041 52.3676

Supported primitives: Point, Line, Pline (polyline), Region (polygon with inner rings), Arc, Text, Rectangle, Round Rectangle, Ellipse, Multipoint, Collection. Each feature can carry style attributes (Pen (1, 2, 0), Brush (2, 16777215, 16777215)) — a simplified CSS for display in MapInfo Pro.

The .mid file is CSV with the same delimiter as specified in .mif. If .mif says Delimiter ",", then .mid is a standard CSV, one row per feature in the same order as in .mif. If Delimiter ";", then semicolon-separated. Fields are quoted only when they contain the delimiter:

"Damrak","primary",1245.50
"Damrak","primary",980.30
"Prinsengracht","secondary",450.10

The coordinate system is described via a CoordSys line — MapInfo's own syntax with numeric codes for projections. For example, CoordSys Earth Projection 1, 104 means WGS84 latitude/longitude. For OGC-standard compatibility the MID/MIF pair may be accompanied by a .prj file with WKT, which GDAL/OGR writes by default.

Who needs MID/MIF: five roles

Cadastral engineer with 1990s–2000s archives. The primary audience today. Municipal cadastres, land-management schemes, subdivision plans from thirty years ago are often stored in MID/MIF. When a client wants to compare an old subdivision boundary with the current OSM map, you need to open both layers in one GIS — usually MapInfo Pro or QGIS.

Municipal GIS-department geoinformatician. In cities around the world municipal GIS was mass-deployed on MapInfo in the 2000s–2010s. Many are migrating to QGIS and ArcGIS Pro today, but the base archive of layers (address plan, road network, utility lines) is often kept in TAB/MIF. MID/MIF → GeoPackage conversion is a typical migration task.

Historical researcher. Archaeologists, urban historians, cartographic museums frequently receive historical data in MID/MIF — the format was popular in US and European academia in the 1990s–2000s. Opening and re-converting MID/MIF is a basic digital-humanities skill.

Insurance and real-estate GIS analyst. This was MapInfo's original audience: insurers analyzing risk zones, realtors analyzing housing demand. Many large insurance firms in the US and Europe still maintain legacy MapInfo Pro for historical data, and analysts come with the task "update our map using fresh OSM data."

Open-data cartographer-researcher. On government open-data portals MID/MIF appears as one of the available export formats — especially in Australia (data.gov.au), the UK (data.gov.uk), Poland (Geoportal), and some regional GIS in Eastern Europe. Reading the format without MapInfo Pro is a must-have skill.

Software to open and edit: seven programs

MapInfo Pro 2025 (Precisely). The canonical producer and editor of the format. Opens MID/MIF via File > Open > pick .mif, saves via Save As > MIF Interchange. Paid, license from $1,500/year. The current version supports 64-bit, Windows 11, Python API. precisely.com/product/precisely-mapinfo

QGIS. Free open-source GIS. Reads and writes MID/MIF through the built-in GDAL/OGR driver MapInfo File. Layer > Add Vector Layer → pick .mif. Save via Save As Vector Layer → format "MapInfo MIF". Version 3.34 LTR and above handle MID/MIF fully. qgis.org

GDAL / ogr2ogr (CLI). Command line for batch conversions. Basic workflow:

# MID/MIF → GeoJSON
ogr2ogr -f "GeoJSON" output.geojson input.mif

# MID/MIF → Shapefile
ogr2ogr -f "ESRI Shapefile" output.shp input.mif

# GeoJSON → MID/MIF
ogr2ogr -f "MapInfo File" -dsco FORMAT=MIF output.mif input.geojson

The driver is named MapInfo File (not MIF); the FORMAT=MIF option toggles between TAB (default) and MIF. gdal.org/drivers/vector/mitab.html

FME (Safe Software). Industrial ETL tool for large GIS conversions. Supports MID/MIF as both reader and writer, handles complex table mapping, schema validation, streaming processing of gigabyte datasets. About $4,000/year per seat, but pays for itself on big projects. safe.com

ArcGIS Pro (Esri). Esri has long competed with MapInfo, but via the Data Interoperability extension ArcGIS Pro imports MID/MIF directly. Without the extension ArcGIS reads MID/MIF through ArcCatalog "Quick Import" with a pre-conversion step. esri.com/en-us/arcgis/products/arcgis-pro

Manifold System. Alternative commercial GIS, supports MID/MIF as import/export with flexible mapping options. Budget alternative to ArcGIS — license from $145. manifold.net

MITAB library (open source). Base C++ library for reading and writing TAB and MID/MIF, used by the GDAL MapInfo File driver. Useful if you're writing your own converter or embedding MID/MIF reading into a Python/Node.js app. github.com/MapServer/MITAB

Pitfalls and tips

File pairing is critical. Never transfer .mif alone — without .mid the file is invalid. Always pack the archive as a ZIP with both files plus an optional .prj with the WKT CRS definition. Many users of legacy data have received "just the MIF" via email and then spent hours recovering attributes from filenames.

Encoding is a boobytrap. Before MapInfo Pro 7.5 the encoding was specified as Charset "WindowsCyrillic", Charset "Neutral", Charset "WindowsLatin1" — no UTF-8. If you receive a 1990s MID/MIF with Cyrillic street names, the encoding is almost certainly WindowsCyrillic (CP1251). On import in QGIS specify encoding explicitly (Source Charset: System or windows-1251), otherwise you'll get mojibake. For new exports always use Charset "UTF-8".

Format versions. Header Version 300 is MapInfo Pro 3.0 format (1996), Version 450 is 4.5 (1998), Version 700 is 7.0 (2002), Version 1100 is 11.0 (2012). In practice all GIS read any version, but on import of old files into current MapInfo Pro a warning about an outdated format may pop up. Solution — re-save in the current format via Save As.

CoordSys vs .prj. Paradox: MID/MIF has its own projection description (CoordSys Earth Projection X, Y, ...), but GDAL/OGR on export also writes a .prj file with WKT. If the two sources conflict, QGIS and MapInfo Pro can pick differently. Solution — keep them in sync: either delete the .prj, or manually ensure the CoordSys line and WKT agree.

Field-name length and types. Unlike Shapefile (max 10 chars) MID/MIF supports names up to 31 characters. Data types: Integer, SmallInt, Float, Decimal(width, scale), Char(length), Date, Time, DateTime, Logical. Text fields are capped at 254 characters — for long descriptions and URLs this can be a problem.

Region with inner rings. The format describes a Region with holes through several consecutive rings. The first ring is the outer contour, subsequent ones are holes. Ring order and direction (clockwise vs counter-clockwise) MapInfo Pro doesn't validate on read, but on export it may generate invalid geometries. After conversion through QGIS run Vector > Geometry Tools > Check Geometries.

Styles in feature blocks. Pen (1, 2, 0), Brush (2, 16777215, 0) — these are MapInfo Pro style strings. On conversion to Shapefile these attributes are lost (Shapefile doesn't store styles). On conversion to GeoPackage or GeoJSON ogr2ogr may preserve them as attributes prefixed with OGR_STYLE.

Large files are slow. MID/MIF is a text format; reading a gigabyte file takes minutes versus seconds for binary Shapefile or GeoPackage. For legacy data this is tolerable; for regular work convert to GeoPackage.

How to do it via osm2cdr.ru

osm2cdr.ru supports OSM data export to MapInfo format (MIF/MID pair). The workflow is as follows. Step 1. On osm2cdr.ru outline the desired area — a city district, a single block, a park. Step 2. In the format dropdown pick MapInfo MIF. Step 3. Optionally pick the CRS (for compatibility with archive data — a state plane or UTM zone; for international interchange — WGS84 / EPSG:4326). Step 4. Download the .zip, extract: you'll get roads.mif + roads.mid + roads.prj (plus separate pairs for buildings, water, surfaces).

Under the hood the pair is built in two steps: each layer is first staged from the render pipeline as GeoJSON, and ogr2ogr (GDAL) then builds a genuine text MIF/MID pair from it — the only verified way to get real text MIF rather than a binary TAB under a .mif name. If a layer's conversion fails, the layer is honestly reported as failed — the format is never silently substituted.

Opening in MapInfo Pro: File > Open → change file type to "MapInfo Interchange (*.mif)" → pick the file. MapInfo Pro will read both files, ask where to save the resulting TAB, and open the layer in a new window.

Opening in QGIS: Layer > Add Vector Layer → Browse → pick .mif. If the encoding of attribute strings looks wrong — in the Add dialog specify Source Encoding windows-1251 or UTF-8.

If you want to further convert to a modern format, for batch processing use ogr2ogr:

# Convert MID/MIF from osm2cdr.ru to GeoPackage
ogr2ogr -f "GPKG" osm_export.gpkg roads.mif
ogr2ogr -f "GPKG" -append -nln buildings osm_export.gpkg buildings.mif
ogr2ogr -f "GPKG" -append -nln water osm_export.gpkg water.mif

# All layers go into one GPKG file

Or via Python and Fiona:

import fiona

with fiona.open('roads.mif', 'r') as src:
    print(f"Features: {len(src)}")
    print(f"CRS: {src.crs}")
    print(f"Schema: {src.schema}")

    with fiona.open('roads.gpkg', 'w',
                    driver='GPKG',
                    crs=src.crs,
                    schema=src.schema) as dst:
        for feature in src:
            dst.write(feature)

End result: in fifteen minutes you get a fresh OSM road network in a format that works in parallel in MapInfo Pro 2025 and QGIS, and which you can lay next to a 1998 archive cadastre for direct comparison.

Related formats and resources

• MapInfo TAB — MapInfo Pro's native binary format
• Shapefile — industrial interchange via DBase
• GeoJSON — modern JSON interchange for the web
• GeoPackage — SQLite alternative to all legacy formats
• DXF — CAD interchange for engineering tasks
• MapInfo landing page on osm2cdr.ru

Sources

• MapInfo Professional User's Guide, Appendix E "MapInfo Interchange Format" — precisely.com
• GDAL MapInfo File driver — gdal.org/drivers/vector/mitab.html
• MITAB Library on GitHub — github.com/MapServer/MITAB
• Precisely MapInfo Pro product page — precisely.com/product/precisely-mapinfo
• "MapInfo Corporation Acquired by Pitney Bowes", press release 2007 — pitneybowes.com
• QGIS MIF Layer Import Documentation — docs.qgis.org
• Open Geospatial Consortium Simple Features Specification — ogc.org/standards/sfa