Tasking API

The Tasking API provides endpoints to view available capture opportunities and purchase capture capacity with suppliers for imagery to be captured at a future date based on your requirements.

The Tasking API consists of 3 endpoints:

• Search, for obtaining a list of possible capture opportunities for a target location, time period and conditions
• Order, for confirming and booking one of the opportunities obtained from search
• Batch Order, for confirming and booking a set of tasking opportunities in a single operation.

Tasking Search

The tasking search endpoint facilitates searching of Arlula and its supplier’s capturing capacity.

The tasking search can be constrained by a start time, end time, gsd, off nadir, and geometry.

The start and end times will constrain results to any intersecting availability. Where possible results will start at the specified start time and end at the specified end time, however this can be impacted by the following considerations:

• Supplier minimum notice period. Many suppliers have a set minimum time in the future
• Supplier maximum notice period.
• Supplier minimum time span.
• Supplier maximum time span.

The geometry can be provided by one of polygon, boundingBox, or latLong, which respectively detail a polygon, extent, or point of interest.

It will respond with a list of results that coincide with the specified search. Each result is indicative of purchasable capturing capacity with a specific supplier and platform, between the returned start and end date, and at a maximum off nadir.

Interest Area

There are currently three ways of providing a tasking search interest area:

• A point of interest
  Define a point of interest by providing the `latLong` object, including `latitude` and `longitude`. This will be the centre of search.
• A bounding box defining an area of interest.
  Define a bounding box by providing the `boundingBox` object, including `north`, `south`, `east`, and `west`. The centre of this bounding box will be the centre of search.
• A polygon defining an area of interest.
  Define a polygon by providing the `polygon` field on search. This should be a non-self intersecting WGS84 polygon.

Tasking Search Request:

LatLong Object

The LatLong object details a target point.

Example:

BoundingBox Object

Describes an area

Example:

Response Details:

The results of a tasking search will be returned as a Tasking Search Response structure

The full details of this structure are available in the reference section below, but an example response would resemble the following:

Tasking Order

The tasking order endpoint facilitates ordering and paying for tasked imagery from Arlula and it’s suppliers.

It is to be used on results of the Tasking Search endpoint.

Response Details

The /api/tasking/order endpoint returns a JSON encoded response consisting of a Order object, with a structure like the following structure:

A full reference for the structure can be found in the reference section below

Batch Tasking Order

The tasking batch order endpoint facilitates ordering and paying for multiple tasked imagery from Arlula and it’s suppliers at the same time.

It is to be used on results of the Tasking Search endpoint.

Response Details

The /api/tasking/order/batch endpoint returns a JSON encoded response consisting of an array of Order objects, with the following structure:

A full reference for the order object’s structure can be found in the reference section below

Tasking Search Response Object

Tasking results will contain a list of results, and optionally errors returned by suppliers.

This will result in a structure as follows:

Order Request

The /api/tasking/order endpoint requires a JSON object specifying the order details, which resembles the following:

Object Parameters

Webhooks and Emails

Your API can be notified of your order being complete by providing either a webhook and/or email address, to which the order details, and its resource list, will be provided when the order is complete.

Emails will receive a human readable message informing them of the order completion, with the orders details and resource list included.

Webhooks will receive a http POST request which will be sent to the provided address with an event wrapper with the structure of

Where the payload object will be a detailed order object (as returned by this and the Order Get endpoint).

Note: At this time, webhooks provided through the tasking order endpoint itself will only receive "tasking.order.complete" events when the order is complete. Other events will be supported in the future, mostly through the API level webhook configuration rather than per order.

Delivery Configuration

The delivery field allows specifying order delivery behaviour for this order, allowing for delivery to your cloud storage (only AWS S3 is supported at this time), or which dataset collections the order should be added to upon completion.

Order Object

The order object is a JSON object, that resembles:

Order Parameters

NOTE: the resources array will be omitted if there are no resources available for the order yet, or if the order is not complete.

Resource Object

Completed orders will have at least one resource available to download that provides the requested imagery.

Each Resource has structure like the following:

Resource Fields

Common Formats

Imagery and it’s metadata can be delivered in a variety of file formats, with the specific choice of format often varying with supplier.

The resource format field provides details about the format a given resource file is in, in the form of a MIME type.

The following is a summary of the most common formats returned by suppliers (with a few less common but important edge cases):

Legacy Resource Types

The type field is a legacy of past versions of the API.

It is maintained for legacy support, new users are recommended to use the new format and roles fields instead (see below).

The returned legacy types are

NOTE: not all suppliers return data in all types, and a single imagery request may contain multiple files of the same type (i.e. multiple img_tiff resources for different imaging bands on the satellite).

Integrity checking and checksums

Resources downloaded from the API, as with any message over the internet, may be altered or corrupted in transmission.
To aid in detecting such scenarios, a checksum is provided for all resource.

Each resources checksum consists of 2 parts, separated by a colon character (:)
The first part identifies the type of checksum, currently this is either MD5 of SHA1.
The second part is the base64 encoded hash of the resource body.

With this, downloaded resources can be similarly hashed and the value checked against the reported value of the resource.

Resource roles

Roles form a hierarchical tree describing the contents of a given resource

Roles should be read from start to end as being from least to most specific descriptor

The following details the common hierarchies of roles for most order resources:

“data”

Main product data for order.
Resources with this role are often the largest, and contain the primary data sources.

Data generally comes in 3 types

1. “raster” resources are traditional pixel images
2. “vector” resources are geographic features like points, polygons and features
3. “structured” resources are information in machine readable data formats like JSON

At this time, primary data is only returned with the raster, however vector and structured are reserved for future use.

> “raster”

Raster data is the primary deliverable for satellite imagery orders at this time.
These roles describe the type of raster data a given resource is.

>> “reflectance”

reflectance data is light reflected from the observed surface in the relevant band

Below this level roles become less hierarchical.

First describing the band(s) present in the file. If the file is a single band, the next role will be the common name for that band. If instead the resource contains multiple bands, it will have the multi-band role, followed by the list of band common names, in the order they appear in the resource/

Using the band common name the corresponding band information can be found in the metadata file with the bands role.

Some special case “pseudo” bands exist which may be found here in custom orders. These generally correspond to some standard processed raster band such as ndvi and similar. Despite being processing, they are included before other processing roles as they occupy a band in the file

Lastly, if there is processing of the imagery that may affect selection between several similar/related files, it is included as the final set of roles. This is generally large processing jobs which produce distinct artifacts, such as the following:

• • pansharpened for pansharpened imagery
  • orthorectified for orthorectified imagery
  • radiometrically-corrected for imagery that has undergone radiometric correction
  • mosaic for cases where a mosaic has been produced from multiple source images

Example: [“data”, “raster”, “reflectance”, “multi-band”, “red”, “green”, “blue”, “nir”, “pansharpened”]

>> “temperature”

Thermal reflectance data from a thermal sensor like landsat-8’s TIRS sensor.

Example: [“data”, “raster”, “temperature”]

>> “overview”

If the primary data format does not support internal overviews, they may be provided as a separate file identified by this role.

Example: [“data”, “raster”, “overview”]

>> “browse”

A full resolution image of the scene in a more compact format such as JPEG or PNG. These files may have lossy compression and/or compression artifacts and not represent the true data. They are intended as summary data when needed.

Example: [“data”, “raster”, “browse”]

>> “thumbnail”

A low resolution overview of the whole area of interest, generally “true color” or RGB if the image is has the relevant bands.

Example: [“data”, “raster”, “thumbnail”] > “vector”

Not supported at this time, but reserved for future use.

> “structured”

Not supported at this time, but reserved for future use

“metadata”

Descriptive metadata that provides information about the primary data.

Metadata generally comes in 3 types

1. “raster” resources are traditional pixel images, describing a value at each pixel location
2. “vector” resources are geographic features such as the polygon within which is valid data, or where the seams of adjacent tiles are
3. “structured” resources are information in machine readable data formats like JSON, such as general information about a capture; such as the date of capture, or how the scene was processed

> “raster”

Raster metadata often describes values for a scene that correspond to each pixel in the primary data.
such as whether each pixel is classified as being cloud cover, or the azimuth angle for each pixel.

Raster metadata files often fill multiple roles, with each band being a different piece of metadata.
As such, the subsequent roles form a list of what metadata is found in the file
i.e. a single resource may have the cloud, cloud-shadow and water-mask roles for a roles array of ["metadata", "raster", "cloud", "cloud-shadow", "water-mask"]

Note: effort is made to ensure that the role order matches a files band order, however this may not always be the case. Please let us know if you find any discrepancies

The descriptions below describe the meaning of each role for a given pixel in this metadata file

Example: [“metadata”, “raster”, “land-water”, “cloud”, “cloud-shadow”, “snow-ice”]

> “vector”

Vector metadata often describes details about the imagery, such as a summary of its location, or that of the larger scene it belongs to, how the imagery was built from tiled captures, or how the delivery files themselves are tiled.

>> “reference”

Reference vectors describe details about data location

It is followed by a role identifying what it is a reference for

Currently it may be a reference for either:

• • scene in which case it is the boundary for the whole source scene of the imagery, or
  • aoi to identify the location boundary of the delivered Area Of Interest

Example: [“metadata”, “vector”, “reference”, “aoi”]

>> “tiling”

Tiling metadata files describe how multiple data files in an order relate to each other in space

If present, these are often the preferred way to load the imagery, we they can provide metadata about the scene which prevents artifacts such as color balance issues.

These will often be found as GDAL Virtual Raster Table (.vrt) files, or TILE files (.til)

Example: [“metadata”, “vector”, “tiling”]

>> “scene-tiles”

Scene tiles describe the boundaries and tiling of source imagery that makes up a scene (such as when a satellite has multiple overlapping CCD’s)

Example: [“metadata”, “vector”, “scene-tiles”] > “structured”

Structured metadata files provide information about an order and its source scene
This information can provide more context for a scene, or information necessary to process it.

Example: [“metadata”, “structured”, “general”, “lineage”, “platform”, “bands”]

“license”

“license” is a special type, used exclusively for resources that provide either the license for data itself, or information about it.
The most common licenses are either text/plain or application/pdf files.

“custom”

“custom” is a special type, used exclusively for resources that are part of a custom order, for resources which do not fall into other established roles