MIF/MID (MapInfo Interchange) format: ASCII exchange since 1990 — OSM export for legacy GIS

2026-05-0511 min read

gismapinfolegacyasciiinterchange

Export formats: MIF

MIF/MID is the "text half" of the MapInfo ecosystem. If binary TAB is the native working format for MapInfo Professional, then MIF/MID is the official ASCII format for exchanging data between MapInfo and any other system, born alongside TAB in the early 1990s. MIF stands for MapInfo Interchange Format and holds the table description plus geometry in a text file; MID — MapInfo Data — keeps matching attributes as CSV-like rows. Unlike the closed TAB specification, MIF was openly documented in the MapInfo Pro manual from the start, which made it the universal exchange language for every GIS app of the 1990s. On osm2cdr.ru the mapinfo_exporter.py uses the GDAL/OGR "MapInfo File" driver via ogr2ogr -f "MapInfo File" -dsco FORMAT=MIF, producing a .mif + .mid pair for each OSM layer.

Map generation of Tokyo city center

History: MapInfo Corp 1986, MIF as an ASCII pair from 1990

MapInfo Corporation was founded in 1986 in Albany, New York, by Mike Marvin, Andrew Dressner, and Sean O'Sullivan — Troy, NY. The first DOS release of MapInfo shipped in 1986, but it was MapInfo for Windows 1.0 (1990) that introduced the format pair: binary TAB as the native working format and text MIF/MID as the interchange format. The logic mirrored what Esri had done a decade earlier with Shapefile/ArcInfo Coverage: one format for internal work, another for handoff to third-party systems.

Unlike TAB's closed spec, MIF was fully documented in MapInfo Professional manuals from the very first release. That made MIF a convenient integration point: ETL converters, awk/sed scriptable workflows, and early geodata BBS forums all relied on MIF because you could read it in a text editor and patch it by hand.

In 1999 Canadian developer Daniel Morissette, mentored by Frank Warmerdam (founder of GDAL/OGR), wrote MITAB — a TAB and MIF/MID implementation for OGR. Since then MITAB has shipped inside GDAL as the "MapInfo File" driver, and through it QGIS, ogr2ogr, GeoServer, Global Mapper, and FME all read and write MIF/MID.

In 2007 Pitney Bowes acquired MapInfo Corporation for 408 million USD. By 2019 Pitney Bowes Software spun off as Syncsort, renamed Precisely in 2020. Today Precisely continues maintaining MapInfo Pro (current version 2023, build 17.0), and MIF/MID remains an officially documented exchange format.

Anatomy of the file pair

A MIF/MID dataset is always two files sitting side by side with different extensions:

.mif — text file with header and geometry. The header describes the version (Version 300/450/650/1000), charset (Charset "Neutral"/"WindowsCyrillic"/"WindowsLatin1"), MID delimiter (Delimiter ","), coordinate system in MapInfo notation (CoordSys), table column list (Columns N + per-column types). After the header — the Data section with per-record geometry: POINT, LINE, PLINE, REGION, ARC, TEXT, RECT, ROUNDRECT, ELLIPSE, MULTIPOINT, COLLECTION.
.mid — text file with attributes in CSV format (default delimiter — comma). One .mid row maps to one geometry in .mif; row order is strictly synchronized.

For a buildings layer, a typical .mif starts like this:

Version 450
Charset "WindowsCyrillic"
Delimiter ","
CoordSys Earth Projection 1, 104
Columns 3
  osm_id Integer
  building Char(50)
  height Float
Data

Region 1
  5
  37.6173 55.7558
  37.6175 55.7558
  37.6175 55.7560
  37.6173 55.7560
  37.6173 55.7558

And the matching .mid:

12345,"yes",15.5
12346,"residential",24.0

MIF geometry is readable text. PLINE (polyline) stores a point count followed by the coordinates in sequence. REGION (polygon) supports multipart geometry and rings with holes. ARC gives a native arc via bounding box + start/end angles. This is the format an analyst can open in Notepad++ and read with their eyes — which is what makes it indispensable for debugging.

Map generation of Sochi city center

MIF vs TAB: text exchange vs binary work

The first question anyone hitting the MapInfo ecosystem asks — why two formats? The answer is simple: different jobs want different priorities.

TAB is binary and native. It's fast, indexed, supports in-place editing (open-edit-save), holds a spatial index, raster companion files, and hidden system tables. Any "open a layer in MapInfo Pro and draw on it" operation uses TAB. It's the working format for everyday GIS labor.

MIF/MID is a text interchange format. It's slow to read (text parsing required), has no index, doesn't support in-place edits, but in return it's fully human-readable, vendor-neutral, Git-versionable, and runs through awk/sed/grep/Python scripts without special libraries. It's the format for moving data between systems, for recovery (when binary TAB corrupts and the only restore path is export-to-MIF), and for long-term archival.

The analogy: TAB is to MapInfo what File Geodatabase is to ArcGIS. MIF/MID is to MapInfo what Shapefile is to ArcGIS in the interchange role. With one critical difference: the MIF spec is fully open and trivially regex-parseable — something you cannot say about SHP with its 4-7 files and dBASE attribute table.

MIF geometry types

Unlike Shapefile (Point/Polyline/Polygon — three types) or GeoJSON (Point/LineString/Polygon/Multi* — seven types), MIF supports a rich primitive set inherited from 1980s cartographic apps:

POINT — a single point with coordinates and Symbol style.
MULTIPOINT — a set of points as one feature.
LINE — a segment between two points.
PLINE — a polyline of multiple segments; PLINE MULTIPLE — a multiline.
REGION — a polygon, possibly multipart (multipolygon) with holes.
ARC — an arc described by bounding box + start/end angles. A native type, not approximated through PLINE.
ELLIPSE — an ellipse described by bounding box. A native type.
RECT — a rectangle by bounding box.
ROUNDRECT — a rectangle with rounded corners and a given radius.
TEXT — a text annotation with coordinates, angular size, font style.
COLLECTION — a heterogeneous collection of mixed-type geometries in one feature.

ARC and ELLIPSE are MapInfo trademarks: when exporting to Shapefile or GeoJSON they get approximated as PLINE (segment chains), losing mathematical precision. When exporting OSM to MIF we write everything as POINT / PLINE / REGION — native arcs and ellipses essentially don't appear in OSM data.

Where MIF/MID is actually needed

Legacy GIS archive recovery. The most common 2020s scenario: a customer has an archive of binary TAB files from 2005-2015, some of which corrupt when opening in modern MapInfo Pro. MIF/MID is the only reliable recovery path: TAB first converts to MIF/MID through MapInfo Pro or MITAB, then the text pair is eyeballed and glued back into a working table.

Russian cadastral workflow. Regional cadastral chambers across Kaliningrad-Kaluga-Samara regions until 2018 handed survey plans and urban-planning regulations to municipalities exactly in MIF/MID (not TAB), because the text format passed through any ETL converter without loss and allowed script-based validity checks. By 2026 the archives of regional property ministries and design institutes hold hundreds of GB of MIF/MID files.

Utility networks (gas, electric, water). "Gazprom Mezhregiongaz", water utilities, regional grid companies use MapInfo Pro for cabinet GIS — tracking networks, drawing new branches on basemaps. When exporting data for contractor-designers who don't have a MapInfo Pro license, MIF/MID becomes a cheap universal interface.

ETL converters in awk/sed/Python. MIF's text structure makes it ideal for script-based transformations: rename an attribute, fix encoding, reproject coordinates — all doable with sed or a short Python script without libraries.

Git delivery. Binary TAB lives in Git as a black box: diff shows nothing, merge is impossible. MIF/MID versions like a regular text file, line-by-line changes are visible, and attribute edits can flow through pull requests.

Software for MIF/MID

MapInfo Pro. Paid subscription from 1300 USD/year. The reference implementation — what MapInfo Pro writes to MIF is by definition canonical. Officially unavailable for purchase in Russia since 2022, but used through parallel imports.

QGIS. Free, reads and writes MIF/MID through the MITAB driver out of the box. Layer → Add Layer → Add Vector Layer → pick the .mif file. Writing via Layer → Export → Save Features As → "MapInfo MIF" format.

GDAL / ogr2ogr. Free CLI tool. Read command: ogrinfo -al input.mif. Conversion: ogr2ogr -f "MapInfo File" -dsco FORMAT=MIF output.mif input.shp. The -dsco FORMAT=MIF parameter is critical — without it the driver defaults to TAB.

Global Mapper. Paid (about 600 USD perpetual license), Windows. Supports MIF/MID among dozens of formats.

FME (Safe Software). Paid (from 3000 USD/year), enterprise ETL tool. Handles every MIF/MID variant including rare 300/650/1000 versions.

Any text editor. Notepad++, Sublime Text, VS Code open MIF/MID as plain text files. Handy for debugging, regex search, manual coordinate fixes.

Strengths and weaknesses

Strengths. Fully open documented spec. ASCII format — eye-readable, regex-parseable, Git-versionable. Vendor-neutral — supported by every GIS app through MITAB. No binary corruption — text files can always be partially recovered. Rich geometry primitive set (ARC, ELLIPSE, ROUNDRECT natively). Cyrillic support via Charset "WindowsCyrillic".

Weaknesses. File size 5-10x larger than equivalent TAB or Shapefile due to text representation of coordinates. Reading is slow — ASCII parsing required. No spatial index — large files (>500 MB) lag on spatial queries. Not for editing inside MapInfo Pro — the app always converts MIF to TAB first on open. Coordinate system in MapInfo CoordSys notation, not EPSG WKT — MITAB lookup conversion can drop for Russian MSK zones.

MIF/MID vs alternatives

MIF/MID vs Shapefile — both formats roughly the same generation (1990 vs 1998), both for interchange. Shapefile is more globally widespread, but binary (geometry in .shp, attributes in .dbf). MIF/MID is text — better for debugging and Git. Shapefile has hard limits (2 GB, 10-char field names), MIF/MID has none.
MIF/MID vs GeoJSON — GeoJSON is modern (RFC 7946, 2016), the apex of text formats: read universally by JS/Python/any language. MIF/MID is pre-JSON era, syntax specific to MapInfo. For modern web workflows — GeoJSON; for legacy MapInfo — MIF/MID.
MIF/MID vs TAB — TAB is binary, native to MapInfo Pro, fast. MIF/MID is text, interchange-oriented, slow, but human-readable.
MIF/MID vs GeoPackage — GeoPackage (2014) is a modern single-file SQLite-based open OGC standard. Supported by the entire GIS stack. For new projects, pick GeoPackage; MIF/MID only if the recipient runs MapInfo Pro.

Pipeline in OSM2CDR

Our mapinfo_exporter.py uses the GDAL/OGR "MapInfo File" driver through ogr2ogr with -dsco FORMAT=MIF. OSM layers from PostGIS (buildings, roads, water, green areas, POIs) flow into the pipeline through the WKB fast-path: geometry is read straight from planet_osm_* tables, passed to OGR as WKB, and OGR writes it out in MIF format as text.

The output is a ZIP archive with a .mif + .mid pair per layer. For example, a buildings layer: buildings.mif (header + REGION geometries) and buildings.mid (osm_id, building, height attributes in CSV).

The coordinate system is picked by the user from our 165-strong CRS picker. MITAB converts the EPSG code to MapInfo CoordSys notation automatically — for most national and UTM zones it works correctly. For Russian MSK zones (MSK-50, MSK-77 etc.) the MITAB lookup may drop; in that case load into QGIS and override the CRS manually.

Default encoding is UTF-8 (Charset "Neutral"), but for compatibility with older MapInfo Pro you can pick WindowsCyrillic. Default MIF version — 450 (MapInfo Pro 4.5+) — is supported by all modern releases.

Map generation of Samara city center

FAQ

Is this two files or one? Always a pair — .mif and .mid with the same name must sit in the same folder. Without .mid, no attributes; without .mif, no geometry. They only work as a pair.

Can I open MIF in QGIS? Yes, through the MITAB driver out of the box. Layer → Add Vector Layer → pick .mif. QGIS automatically finds the companion .mid in the same folder.

How is MIF different from TAB? TAB is the binary native working format of MapInfo Pro — 4-5 files, fast. MIF/MID is the text interchange format — 2 files, slow, but human-readable. For everyday work — TAB; for data handoff and version control — MIF.

Which encoding for Russian text? Charset "WindowsCyrillic" in the .mif header (codepage 1251) for compatibility with older MapInfo Pro (before version 11, 2011). For modern releases — Charset "Neutral" (UTF-8).

Why won't my .mif open? Most often: either the companion .mid is missing from the same folder (both required), or the header is broken (Version, Charset, CoordSys, Columns must appear in the right order). Open the file in a text editor and check the first 10 lines.

Sources

MITAB on GitHub — github.com/Toblerity/mitab
GDAL MapInfo MIF/MID driver — gdal.org/drivers/vector/mitab.html
Precisely MapInfo Pro — precisely.com/product/precisely-mapinfo/mapinfo-pro
Wikipedia, MapInfo Professional — en.wikipedia.org/wiki/MapInfo_Professional