KML to WKB Converter
When features digitised in Google Earth need to land in a spatial database's geometry column as compact binary rather than verbose XML.
Common issues converting KML to WKB
- KML styling, placemark names, and <ExtendedData> attributes are all dropped — WKB encodes geometry only. If you need the name or description columns, export KML→CSV alongside and join by row order.
- The output is binary, not text. Open it in a hex viewer or pipe through ST_AsText(ST_GeomFromWKB(...)) in PostGIS to inspect — a text editor will show garbage.
- WKB carries no SRID. KML is always WGS 84, so wrap with ST_SetSRID(ST_GeomFromWKB($1), 4326) at INSERT time, or reproject before conversion if your target column uses a different CRS.
- MultiGeometry containers become a single MULTIPOINT / MULTILINESTRING / MULTIPOLYGON WKB record; mixed-type containers become a GEOMETRYCOLLECTION record. They aren't split into separate rows.
Frequently asked questions
Is the output EWKB or plain OGC WKB?
Plain OGC WKB, little-endian (the first byte of each record is 0x01). For PostGIS's EWKB form with an embedded SRID, call ST_SetSRID(ST_GeomFromWKB($1), 4326) at INSERT time.
Do placemark names and attributes survive?
No — WKB is a geometry-only encoding with no attribute layer. To keep names, descriptions, or ExtendedData, run KML→CSV in parallel and join the two by row index.
How do I load the result into PostGIS?
Pass each record through ST_GeomFromWKB in a prepared statement, or hex-encode and COPY into a bytea column then convert. The output here is raw binary; encode-to-hex if your tooling expects hex strings.
Is altitude preserved?
Yes. KML coordinates with an altitude triplet produce WKB records with the OGC Z-modifier (POINT Z, LINESTRING Z, etc.). 2D placemarks produce plain 2D geometry.