GDALVector Processing

ogrtindex

What is ogrtindex?

ogrtindex scans a set of vector files and produces a new vector dataset where each feature is the bounding footprint of one input, with an attribute recording the path to the source. The result is a tile index for vectors — the analogue of gdaltindex for rasters — letting MapServer and other consumers treat a directory of Shapefiles or GeoPackages as a single logical layer.

Shell
ogrtindex [options] <output_dataset> <source_1> [<source_2>...]

Commonly used options:

  • -f <format> — output OGR driver
  • -tileindex <field> — attribute holding the source path (default LOCATION)
  • -write_absolute_path — record absolute paths
  • -skip_different_projection — skip sources whose CRS does not match
  • -t_srs <CRS> — reproject footprints into this CRS; use -src_srs_name to record per-source CRS
  • -src_srs_name <field> / -src_srs_format <format> — record each source's native CRS
  • -lyr_name <name> — output layer name
  • -accept_different_schemas — allow inputs with different attribute schemas

When would you use ogrtindex?

Use ogrtindex whenever you have many vector files that together form a logical dataset and you want a catalog over them. Typical jobs: building a MapServer tile index over a directory of parcel Shapefiles delivered by county (ogrtindex -f "ESRI Shapefile" parcels_tindex.shp parcels/*.shp), or maintaining a lightweight index over a set of GeoPackage deliveries so a downstream viewer can request only the files touching a given extent.

In practice, ogrtindex sees less use than its raster sibling because many modern workflows either consolidate vectors into one PostGIS or GeoPackage (where a tile index is unnecessary) or use systems like PMTiles and FlatGeobuf that natively index spatially. Still, for legacy MapServer deployments and catalog-style datasets it remains the right tool.

FAQs

How is ogrtindex different from ogrmerge?

ogrtindex creates a catalog of footprints pointing at the original files — no feature-level merge occurs. ogrmerge.py actually combines features into one output dataset. Pick tindex when you want consumers to fetch individual source files on demand; pick ogrmerge when you want one consolidated file.

What if my inputs have different attribute schemas?

Pass -accept_different_schemas to suppress the schema-mismatch warning. The tile index itself only stores bounding boxes and the path attribute, so source schemas are not persisted in the index — consumers read the original files to access attributes.

Can I mix CRSes in one tile index?

Yes, with care. Use -t_srs to normalise all footprints to one CRS for the index, and add -src_srs_name source_srs so each row records its original CRS. Consumers like MapServer use those recorded CRSes to reproject features on the fly.

Do I still need ogrtindex with modern tools?

Rarely. Consolidating into a single GeoPackage or PostGIS with a spatial index usually beats maintaining a file-level tile index. Use it when integrating with older servers or when contract requirements mandate that sources remain unmerged.