Skip to main content
GeoPilot

How to convert ED-269 and ED-318 geozones to GeoJSON or KML

Updated

UAS geographical zones are published in ED-269 or ED-318, but web maps want GeoJSON and Google Earth wants KML. The GeoPilot API converts between all four in any direction with one call: POST /api/v1/public/convert/:from-:to, with the source document in a document field. The response holds the converted document, plus a list of any features that could not be converted and warnings about anything the target format cannot express.

Formats and scopes

FormatIn the URLSent asScope
ED-269ed269JSON objectCONVERT_ED269
ED-318ed318JSON objectCONVERT_ED318
KMLkmlXML text, as a JSON stringCONVERT_KML
GeoJSONgeojsonJSON objectnone

A conversion needs the scope of both its formats: kml-ed318 needs CONVERT_KML and CONVERT_ED318, while ed269-geojson needs only CONVERT_ED269. GeoJSON needs none. That makes twelve directed pairs; the API reference lists every one.

Convert in three steps

  1. Create an API key with the scopes for your formats — see getting started with the API.
  2. POST the source document as document: the parsed JSON for ED-269, ED-318 or GeoJSON, or the XML text as a string for KML.
  3. Read document from the response, then check errors and warnings before you publish the result.
curl -X POST "https://geopilot.space/api/v1/public/convert/ed269-kml" \
  -H "Authorization: Bearer $GEOPILOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'JSON'
{ "document": { "title": "Zones", "features": [ { "identifier": "ROU-001",
  "name": "Example zone", "restriction": "PROHIBITED", "geometry": [ {
  "uomDimensions": "M", "horizontalProjection": { "type": "Polygon",
  "coordinates": [[[26.05,44.40],[26.15,44.40],[26.15,44.47],[26.05,44.47],[26.05,44.40]]] } } ] } ] } }
JSON
{
  "document": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><kml …>…</kml>",
  "totalFeatures": 1,
  "errors": [],
  "warnings": []
}

Reading errors and warnings

  • totalFeatures — how many features the source held.
  • errors — features that could not be converted, each with its index, identifier and reason. The rest of the document still converts: one bad feature costs no other.
  • warnings — places where the target format has no way to say what the source said, such as an effect ED-269 has no word for, or an altitude datum it cannot reference. Each says what was written instead.

One case fails the whole request instead: converting to ED-269 a document that mixes areas with lines or points, because an ED-269 zone can only hold areas. It is refused with a 400 in the RFC 9457 error shape — send the areas only, or pick another target format.

Which format for which job

  • ED-269 — the EUROCAE standard many national authorities publish and accept zones in.
  • ED-318 — its successor, a GeoJSON-based specification now appearing in national feeds.
  • KML — for Google Earth and pilots’ mapping apps; a zone’s altitude limits are carried as heights where it has them.
  • GeoJSON — the neutral format for web maps and GIS pipelines, and the side every conversion reads or writes through.

How ED-269 and ED-318 differ field by field, and the traps found in real national feeds, is in ED-269 vs ED-318.

A conversion changes the format, not the facts. It does not check the zones against any official source, and a converted file is only as current as the one you sent.

Frequently asked questions

Can I convert without an API key?
No. Every conversion needs a key carrying the scopes of both formats.
Why is a feature missing from my output?
Look in errors: it lists every feature that could not be converted and why, while the others converted normally.
Is anything lost between formats?
Sometimes — each format can express things the others cannot. Every such case is reported in warnings, with what was written in its place.

Related guides

Sources

  • EUROCAE ED-269 — Minimum Operational Standard for UAS Geographical Zones
  • EUROCAE ED-318 — Technical Specification for UAS Geographical Zone Data
  • The KML reference (Open Geospatial Consortium, KML 2.2)
  • RFC 7946 — The GeoJSON Format
GeoPilot

An independent drone-planning tool, built on the airspace restrictions national authorities publish, for the European countries it covers and the United States.

Data

  • Airspace data is published by the national authorities of each country covered. GeoPilot is not affiliated with or endorsed by any of them.
  • View sources and freshness

GeoPilot is an independent planning tool and is not affiliated with or endorsed by any aviation authority. It shows data published by national authorities, which may be incomplete, out of date or simplified in processing, and it does not authorize any flight. Always check the authority's own publication and current NOTAMs before flying.