KML to GeoParquet Converter
Moving features digitised in Google Earth into a cloud data warehouse, where Parquet's columnar layout makes spatial joins and filtered scans far cheaper than XML.
Common issues converting KML to GeoParquet
- GeoParquet is a Pro-tier output format — KML to GeoParquet conversions require a paid Pro plan. The free and Starter tiers don't write GeoParquet.
- KML styling (icons, colours, line widths) has no GeoParquet equivalent and is dropped. Placemark <ExtendedData> fields survive as columns; the name and description become string columns.
- Geometry is encoded as WKB in a single non-nullable `geometry` column with the GeoParquet `geo` metadata. KML placemarks without geometry are dropped, since the spec requires the primary geometry column to be non-nullable.
- Parquet's schema is rigid: every feature needs the same property keys and types. KML files where placemarks carry different ExtendedData fields get the union of keys, with missing values written as null.
Frequently asked questions
Do I need a paid plan for this conversion?
Yes. GeoParquet is a Pro-tier output format, so KML to GeoParquet requires a paid Pro plan. Reading KML is free, but writing GeoParquet is gated to Pro.
What CRS does the output use?
OGC:CRS84 (longitude/latitude WGS 84), the GeoParquet spec default. KML is always WGS 84, so coordinates pass through without reprojection and the `geo` metadata records CRS84.
Which tools can read the result?
Anything that reads Parquet sees the columns; tools that understand the `geo` metadata key — BigQuery, Carto, Apache Sedona, Wherobots, DuckDB's spatial extension, OGR/GDAL ≥ 3.5, GeoPandas — materialise geometry from the WKB column directly.
Do placemark names and ExtendedData carry over?
Yes. The placemark name and description become string columns, and each <Data name='...'> ExtendedData element becomes its own column. Styling is the only thing dropped.