Shapefile to GML Converter
When a European public-sector data partner wants GML and you have Shapefile — the typical INSPIRE-prep step.
Common issues converting Shapefile to GML
- Output is GML 2.x with gml:coordinates. Consumers requiring GML 3 (gml:posList) need a post-processing pass.
- The output is structurally-valid GML but doesn't carry an INSPIRE application schema — mapping shapefile fields to INSPIRE element names is a separate transformation step.
- DBF attribute names are uppercased and 10-char-capped by ESRI convention; they survive into GML element names verbatim. Rename pre-conversion if you need long descriptive XML tags.
- GML's verbosity means output is typically 5–10× larger than the source shapefile. Gzip compression on transit recovers most of that.
Frequently asked questions
Will the output validate against an INSPIRE schema?
Not against a theme-specific schema — that requires mapping shapefile fields to INSPIRE element names. The output is generic GML and validates as XML and as base GML.
Are CRS / SRS references preserved?
The .prj is read for CRS detection but the GML wrapper doesn't emit srsName on each geometry by default. Reproject to your target CRS pre-conversion if needed.
How are DBF dates handled?
DBF D-type (YYYYMMDD) becomes an ISO-8601 date string in the GML attribute. Numeric and Character types pass through as-is.
Why is the output file so large?
GML's XML structure is inherently verbose. For data interchange where size matters, send gzipped — or use FlatGeobuf / GeoParquet if your consumer accepts those.