AOI GeoJSON Subset

For the complete documentation index, see llms.txt.

When you create an Area of Interest by pasting or uploading GeoJSON (see the GeoJSON paste/upload tab in the AOI creation drawer), VALAR accepts a deliberately narrow subset of RFC 7946. This page catalogues what is accepted, what is rejected, what transformations are applied on ingest, and a worked example you can paste verbatim. The page covers both directions. Everything up to Exporting a Boundary is the import contract — the GeoJSON VALAR accepts from you. That final section is the export contract — the GeoJSON VALAR produces from an area you already track. The two are deliberately different, and the export section says where and why.

Supported Types

VALAR accepts these top-level GeoJSON objects:

Type	Constraints
Polygon	Exterior ring only (no holes). Vertex count must be in `[3, 500]` distinct vertices.
MultiPolygon	Between 2 and 50 disjoint single-ring pieces. Each piece must itself satisfy the Polygon rules.
Feature	A Feature wrapper around either of the above geometries. The Feature’s geometry is unwrapped on ingest.
FeatureCollection	A FeatureCollection containing exactly one Feature, whose geometry is one of the above. The wrapper is unwrapped on ingest.

Rejected Types

VALAR rejects every other RFC 7946 type, and refuses any document that declares a coordinate reference system other than WGS 84. The document is checked in your browser as you paste or select it, so a rejection appears immediately and nothing is sent:

Input	Result
Polygon with one or more interior rings (holes)	Rejected — remove the interior ring, or split the area into separate Polygons
`GeometryCollection`	Rejected
`Point` or `MultiPoint`	Rejected
`LineString` or `MultiLineString`	Rejected
`FeatureCollection` of zero or more than one feature	Rejected — unwrap the single Feature you want, or paste its geometry directly
A `crs` member declaring a coordinate reference system other than WGS 84	Rejected — re-export the file in WGS 84 from the tool that produced it

Most rejections in this table show the same helper line beneath the textarea: GeoJSON must be a Polygon, Disk, or MultiPolygon. Two are exceptions, and each carries its own helper line, because in both cases the document really is a Polygon and the general line would send you looking for a type problem you do not have. A Polygon carrying a hole shows Polygons with holes are not supported. A document declaring a non-WGS-84 reference system shows This file declares a coordinate reference system other than WGS 84 — re-export it in WGS 84. Save stays disabled until the document parses to one of the supported types.

RFC 7946 mandates WGS 84 (longitude, latitude in decimal degrees) and removed the crs member entirely, so a conformant file never carries one — VALAR accepts a document with no crs member, and one written "crs": null, exactly as before. Older tools may still stamp a crs on their output. Where that declaration names WGS 84 in any of its usual spellings (EPSG:4326, CRS84, urn:ogc:def:crs:OGC:1.3:CRS84, and the other common forms) the file is accepted unchanged. Where it names anything else, the file is refused rather than reprojected: VALAR never transforms your coordinates, because the area it stores must be the area you supplied. This matters most for a system expressed in degrees — a different datum such as ED50, NAD27 or NAD83 produces values that look like plausible latitudes and longitudes, so without the declaration being read the area would be created silently offset from the ground you selected.

Polygon and MultiPolygon contents are validated against the same geometry rules the structured-coordinate form enforces — see Validation Errors for the full catalogue.

Body Size Cap

The pasted body or uploaded file must be at most 1 MB (1,000,000 bytes). A larger file is rejected with GeoJSON file must be 1 MB or smaller. Simplify the geometry (e.g. Douglas-Peucker reduction at a tolerance appropriate for your AOI) in a desktop GIS tool before retrying.

Ingest Transformations

VALAR applies the following deterministic transformations to the GeoJSON before persisting the AOI:

Transformation	Behaviour
Strip 3rd coordinate	If a coordinate pair carries an altitude (3rd value), it is dropped. AOIs are 2D Earth-surface regions.
Antimeridian crossing	Polygons that cross the antimeridian are accepted directly as spherical polygons — no longitude-domain bookkeeping is required from the operator.
Feature unwrap	A bare `Feature` is unwrapped to its inner geometry; a `FeatureCollection` of exactly one Feature is also unwrapped.
MultiPolygon-of-1 collapse	A `MultiPolygon` with exactly one piece is collapsed to a plain `Polygon`.
Winding-order normalisation	The exterior ring is normalised to counter-clockwise winding. Clockwise input is auto-rewound; the geometry’s footprint is unchanged.

No extra vertices are inserted. The boundary VALAR stores has exactly the vertices you submitted, in the same order, so a boundary authored in another tool is stored exactly as that tool wrote it.That describes import. It says nothing about the files VALAR exports — those are densified and carry more positions than the stored boundary. See Exporting a Boundary.

Rectangle and the Map Drawing Tool

Rectangles drawn through the Draw on map tab are serialised to a 4-vertex Polygon on the client before submit — VALAR does not accept a bespoke Rectangle type. If you have a bounding box from an external source, hand-craft the corresponding closed Polygon.

Worked Example — Tuscany Coast

Below is a valid Polygon describing a small AOI covering the Tuscany coast near Livorno. It satisfies every rule documented above: a closed ring of 5 coordinate pairs (4 distinct + 1 closing repeat), no altitude component, no hole, no antimeridian crossing.

{
  "type": "Polygon",
  "coordinates": [
    [
      [10.20, 43.80],
      [10.40, 43.80],
      [10.40, 43.60],
      [10.20, 43.60],
      [10.20, 43.80]
    ]
  ]
}

Paste this block into the GeoJSON paste/upload tab of the AOI creation drawer, fill the rest of the Create an AOI form, and Save — the AOI lands in the workspace and an automatic recompute follows.

Worked Example — MultiPolygon

A MultiPolygon must carry at least 2 disjoint pieces:

{
  "type": "MultiPolygon",
  "coordinates": [
    [
      [
        [9.10, 45.50],
        [9.20, 45.50],
        [9.20, 45.40],
        [9.10, 45.40],
        [9.10, 45.50]
      ]
    ],
    [
      [
        [12.45, 41.95],
        [12.55, 41.95],
        [12.55, 41.85],
        [12.45, 41.85],
        [12.45, 41.95]
      ]
    ]
  ]
}

Full specification of the GeoJSON encoding is in RFC 7946 — The GeoJSON Format. VALAR’s subset is documented above; anything outside the subset is rejected with one of the messages listed in the Rejected Types table.

Exporting a Boundary

Everything above is the import contract — what VALAR accepts from you. This section is the export contract — what VALAR produces from an area you already track. Export runs from the area’s own actions menu on the Areas of Interest overview page: choose Export as GeoJSON and the file downloads directly. It is named aoi-<area-name>-<yyyymmdd>.geojson, where the date is the UTC calendar date of the export.

What the File Contains

The document is a single RFC 7946 Feature:

Element	Content
`geometry`	A `Polygon` for a single-piece area, or a `MultiPolygon` for a multi-piece one. Exterior rings only — no interior ring is ever written.
`coordinates`	`[longitude, latitude]` positions in decimal degrees, WGS 84, rounded to 6 decimal places. No altitude component. Every ring is closed and wound counter-clockwise.
`properties.name`	The area’s name, or `null` when it has none.
`properties.description`	The area’s description, or `null` when it has none.
`properties.tags`	The area’s tags as an array of strings, or `[]` when it has none.
`properties.valar`	The provenance block described below.

Nothing else is written. The file carries the boundary and the three identity fields above — never the area’s validity window, colour, active flag, computed overflight events, or any workspace identifier.

Accuracy of the Exported Boundary

VALAR computes overflights against a boundary whose edges are great-circle arcs. GeoJSON has no arc primitive, so every edge in the file is a straight segment, and each one is subdivided until it tracks the arc closely.

Exported area boundaries are densified so that every edge stays within 250 m on the ground of the great-circle boundary VALAR computes overflights against. This is a geometric bound only. It does not guarantee that a third-party tool re-evaluating access against the exported boundary reproduces VALAR’s overflight results: whether a boundary deviation changes an access determination depends on the tasked sensor’s footprint and slew geometry, which is not known when the area is exported.

The 250 m bound holds for absolute latitude up to 89.5°.

The `valar` Provenance Block

properties.valar carries exactly six keys, in this order:

Key	Example	Meaning
`producer`	`"VALAR"`	The system that wrote the file.
`schemaVersion`	`"1.0"`	Version of the file layout. It changes only when the structure changes in a way a consumer must react to.
`generatedAt`	`"2026-07-22T14:03:11.482Z"`	The instant the file was written, ISO 8601, UTC.
`boundaryOnly`	`true`	Always `true`. States that the file carries the boundary and nothing else — no overflight events and no forecast.
`maxDeviationM`	`4.9`	The largest distance, in metres, between any segment written to the file and the great-circle edge it approximates. Measured from the segments in this specific file — it is not a fixed constant and not the 250 m bound, though it is always at or below that bound.
`deviationModel`	`"great-circle-chord-sagitta"`	Names the quantity `maxDeviationM` measures, so a consumer does not have to infer it.

boundaryOnly sits immediately before maxDeviationM deliberately: the accuracy figure describes the boundary, and the file carries no overflight results for it to describe.

An Exported File Is Not an Import File

A file VALAR exports is not guaranteed to import back into VALAR, and usually will not. The two contracts are deliberately asymmetric, in both directions:

Asymmetry	Why the two differ
Export writes more than import accepts	Densification adds positions. An exported ring routinely carries far more than the 500 distinct vertices per ring the import route accepts, so re-importing it is refused on vertex count. No vertex ceiling is applied on export, because truncating the ring would emit a boundary that is not the one VALAR holds.
Import accepts more than export writes	A circular area, an area crossing the 180° meridian, and an area enclosing a pole can each be created in VALAR, but none of them can be exported. See Export a boundary for the refusal reasons.

Export exists to hand a boundary to another tool — a GIS package, a planning system, your own pipeline — not to move areas between VALAR workspaces. To change an area’s boundary inside VALAR, use Replace from file… on the Areas of Interest overview page.

Worked Example — An Exported File

A small, mid-latitude polygon area exports to a document like this:

{
  "type": "Feature",
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [10.2, 43.6],
        [10.4, 43.6],
        [10.4, 43.8],
        [10.2, 43.8],
        [10.2, 43.6]
      ]
    ]
  },
  "properties": {
    "name": "Tuscany Coast",
    "description": null,
    "tags": [],
    "valar": {
      "producer": "VALAR",
      "schemaVersion": "1.0",
      "generatedAt": "2026-07-22T14:03:11.482Z",
      "boundaryOnly": true,
      "maxDeviationM": 4.9,
      "deviationModel": "great-circle-chord-sagitta"
    }
  }
}

This area’s edges are short enough, and far enough from the poles, that none of them needed subdividing — so the exported ring holds the same positions the area was created with. A wider area, or one nearer a pole, carries many more positions than it was created with, and a correspondingly different maxDeviationM.

Create an AOI — full coverage of the creation drawer, including the GeoJSON paste/upload tab.
Areas of Interest overview — what an AOI is and how the page is laid out.
Overflight events — read predicted overflights against the AOI you just created.

Core Concepts

File Formats

Supported Types

Rejected Types

Body Size Cap

Ingest Transformations

Rectangle and the Map Drawing Tool

Worked Example — Tuscany Coast

Worked Example — MultiPolygon

Exporting a Boundary

What the File Contains

Accuracy of the Exported Boundary

The `valar` Provenance Block

An Exported File Is Not an Import File

Worked Example — An Exported File

​Supported Types

​Rejected Types

​Body Size Cap

​Ingest Transformations

​Rectangle and the Map Drawing Tool

​Worked Example — Tuscany Coast

​Worked Example — MultiPolygon

​Exporting a Boundary

​What the File Contains

​Accuracy of the Exported Boundary

​The valar Provenance Block

​An Exported File Is Not an Import File

​Worked Example — An Exported File

​Related Pages

Supported Types

Rejected Types

Body Size Cap

Ingest Transformations

Rectangle and the Map Drawing Tool

Worked Example — Tuscany Coast

Worked Example — MultiPolygon

Exporting a Boundary

What the File Contains

Accuracy of the Exported Boundary

The `valar` Provenance Block

An Exported File Is Not an Import File

Worked Example — An Exported File

Related Pages