Ursa Space's analytics have a standardized GeoJSON format by default.
Ursa Analytic GeoJSON Product Formats
Ursa analytic products that contain vector data will use a GeoJSON file format by default. Some details of the products will vary between product types, but some information that is commonly used across products will be contained in fields with standard names and formatting. This page describes this standardized Ursa Analytic GeoJSON product format.
FeatureCollection
Ursa Analytic GeoJSON products will consist of a GeoJSON file that describes a FeatureCollection. According to the GeoJSON specification, the FeatureCollection object has two required members: type, which is always set to ‘FeatureCollection’; and features, which is a list of Feature objects (whose length can be zero). In addition to these required members, the Ursa Analytic GeoJSON product will contain additional members, referred to in the GeoJSON specification as “foreign members.” These additional members contained in the FeatureCollection object are product, processor, and sensorData.
The top-level FeatureCollection object is summarized in the table below.
|
Member Name |
Type |
Description |
|
type |
string |
Always equal to ‘FeatureCollection’ |
|
features |
list |
A list of Feature objects. The list can have a length of 0. |
|
product |
object |
A description of the product being provided in this file. See the Product description in its section on this page. |
|
processors |
list |
A list of the processing components used to generate the results in this file. See the Processor description in its section on this page. |
|
sensorData |
list |
A list of the source sensor data that was processed to generate the results in this file. Members of this list are SensorData objects. See the SensorData description in its section on this page. |
Product
A summary of the Product object and its members is provided in the table below.
|
Member Name |
Type |
Description |
|
productType |
string |
Name of the Ursa product type contained in this file, e.g., “Change Detection”, “Vessel Detection”. |
|
documentVersion |
string |
Version of the product contained in this file. |
Processor
For workflows or analytics that that are run on Patricia, the processors member of the FeatureCollection should be a list with:
- a single member representing the Patricia workflow.
- one or more members representing each of the analytics that comprise the Patricia workflow.
- For products that are generated by non-Patricia processing, the users may use their discretion to compile a list of the modular components that were used to generate the product (e.g., CFAR, detection clustering, false alarm filter, etc., in the case of vessel detection).
A summary of the Processor object and its members is provided in the table below.
|
Member Name |
Type |
Description |
|
processorName |
string |
Name of the processor. For workflows or analytics that that are run on Patricia, this should be a unique identifier for that processor. For products that are generated by non-Patricia processing, these may be the names of modular components of a script used to generate the product. |
|
version |
string |
Version of the processing component. For workflows or analytics that that are run on Patricia, this should be a the workflow/analytic version. For products that are generated by non-Patricia processing, this should be the version of the package from which these components were imported. |
|
parameters |
object |
Dictionary of processor parameters used to create the product. For workflows or analytics that that are run on Patricia, the members of this object should be members of the user_data object that is associated with the workflow/analytic. For products that are generated by non-Patricia processing, this should be any relevant keyword arguments used in this processing component. |
SensorData
A summary of the SensorData object and its members is provided in the table below.
|
Member Name |
Type |
Description |
|
sensorDataIndex |
number |
A unique index into the sensor data list to which detections and measurements can be traced. |
|
sensorName |
string |
Sensor name, which should be a member of a list of acceptable values to avoid inconsistent naming, e.g.,:
|
|
sensorType |
string |
Sensor type, which may be one of:
|
|
sensorMode |
string |
Sensor mode, e.g.,:
|
|
productType |
string |
Product type, e.g.,:
|
|
ursaId |
string |
Ursa internal PSDM assigned ID. |
|
vendorId |
string |
Vendor specific product name, e.g. ICEYE_X4_SLC_SLH_26732_20200409T221209 S1B_IW_GRDH_1SDV_20211120T035045_202 11120T035110_029666_038A61_E865 K5_20210408151505_000010_41890_D_ES19_ HH_SCS_B_L1A |
|
startTimeUTC |
string |
Collection start time, described in ISO 8601 format using the following format: YYYY-MM-DDThh:mm:ss.sss e.g. ‘2021-04-08T15:15:05.089’ |
|
geometryReference |
string |
WKT representing the geodetic coordinates of the location where the azimuth and incidence angles are specified. |
|
azimuthAngle |
number |
Angle from scene to sensor in degrees, clockwise relative to true North, defined at scene center. |
|
incidenceAngle |
number |
Local incidence angle in degrees, defined at scene center. |
|
polarization |
string |
For SAR data, this is a two-character string indicating send and receive polarization. For RF data, this may be a single character indicating the receive polarization. |
|
footprint |
string |
WKT describing the perimeter of the collection footprint, in WGS-84 coordinates |
Feature
Feature objects and its fields is provided in the table below.
|
Member Name |
Type |
Description |
|
type |
string |
Always equal to ‘Feature’. |
|
geometry |
string |
May be any of the GeoJSON geometry types ('Point', ‘LineString’, ‘MultiPoint’, ‘Polygon’, ‘MultiLineString’, ‘MultiPolygon'). The most commonly used types in Ursa analytic products are likely to be ‘Point’, 'Polygon', and 'MultiPolygon’. |
|
properties |
object |
Contents of this section will be product-specific (e.g., NCD products will include change type; vessel detection products will include vessel size and orientation). |