GeoJSON to GML Converter
The bridge between modern web-mapping pipelines and the GML-first European public-sector data ecosystem.
Common issues converting GeoJSON to GML
- Our writer emits GML 2.x (gml:coordinates), which is the most broadly compatible dialect. GML 3.x (gml:posList) requires consumer-specific schema; producers that need 3.x should post-process.
- GML's strict XML schema validation requires a producer-specific application schema. The output is generic feature wrapping — valid as XML and as GML, but won't pass schema-validation against, say, an INSPIRE Cadastral Parcels XSD without additional metadata.
- Property values carry over as XML element text. Strings with special characters (&, <, >) are escaped automatically; binary or non-UTF8 properties should be base64-encoded before conversion.
- GeoJSON 'id' becomes the gml:Feature fid attribute. Numeric ids are stringified.
Frequently asked questions
Is the output GML 2 or GML 3?
GML 2.x — uses <gml:coordinates>x,y</gml:coordinates> for each geometry. Tooling that requires GML 3 (e.g., some WFS 2.0 endpoints) may need a post-processing step to swap to <gml:posList>.
Will the output validate against an INSPIRE schema?
No — INSPIRE schemas require theme-specific element names and metadata. This output is structurally-valid GML; mapping to an INSPIRE theme is a schema-transformation step downstream.
Are CRS / SRS references included?
Not in the gml:FeatureCollection wrapper by default — the coordinates are emitted in their source CRS without an srsName attribute. Open a follow-up if your consumer requires srsName='EPSG:4326'.
How are GeoJSON properties encoded?
Each property becomes a child element of the <Feature> wrapper, with the property name as the element tag and the value as text content.