Skip to content

Processing data using a process graph

Process graphs can be executed in three different ways.

Results can be pre-computed by creating a batch job using POST /jobs. They are submitted to the back office's processing system, but will remain inactive until POST /jobs/{job_id}/results has been called. They will run only once and store results after execution. Results can be downloaded. Batch jobs are typically time consuming such that user interaction is not possible.

Another way of processing and accessing data are secondary web services. They allow web-based access using different protocols such as OGC WMS, OGC WCS or XYZ tiles. These protocols usually allow users to change the viewing extent or level of detail (zoom level). Therefore, computations may run on demand, i.e. the requested data is calculated during the request. Back-ends should make sure to cache processed data to avoid additional/high costs and waiting times for the user.

Process graphs can also be executed synchronously (POST /jobs/previews). Results are delivered with the request itself and no job is created. Only lightweight computations, for example small previews, should be executed using this approach as timeouts are to be expected for long-polling HTTP requests.

Data processing details

Heterogeneous datasets are unified by the back-ends based on the processes in the process graphs. For instance, the difference between a PROBA-V image and a Sentinel image, which have e a different projection and resolution, are automatically resampled and projected by the back-ends as soon as it is required to do so. Clients are not responsible to ensure that the data matches by first applying resampling or projections processes.

Temporal references are always specified on the basis of the Gregorian calendar.

Examples

Synchronously executed jobs

Retrieval of a GeoTIFF

Request

POST /preview HTTP/1.1
Content-Type: application/json; charset=utf-8

{
  "process_graph":{
    "process_id":"min_time",
    "imagery":{
      "process_id":"NDVI",
      "imagery":{
        "process_id":"filter_daterange",
        "imagery":{
          "process_id":"filter_bbox",
          "imagery":{
            "process_id":"get_collection",
            "name":"S2_L2A_T32TPS_20M"
          },
          "east":652000,
          "west":672000,
          "north":5161000,
          "south":5181000,
          "srs":"EPSG:32632"
        },
        "extent":[
          "2017-01-01T00:00:00Z",
          "2017-01-31T23:59:59Z"
        ]
      },
      "red":"B04",
      "nir":"B8A"
    }
  },
  "output":{
    "format":"GTiff",
    "args":{
      "tiled":true,
      "compress":"jpeg",
      "photometric":"YCBCR",
      "jpeg_quality":80
    }
  }
}

Response

HTTP/1.1 200 OK
Content-Type: image/tiff
Access-Control-Allow-Origin: <Origin>

omitted (the GeoTiff file contents)

Retrieval of time series

Request

POST /preview HTTP/1.1
Content-Type: application/json; charset=utf-8

{
  "process_graph":{
    "process_id":"zonal_statistics",
    "imagery":{
      "process_id":"filter_daterange",
      "imagery":{
        "process_id":"filter_bbox",
        "imagery":{
          "process_id":"filter_bands",
          "imagery":{
            "process_id":"get_collection",
            "name":"Sentinel2-L1C"
          },
          "bands":8
        },
        "west":16.1,
        "east":16.6,
        "north":48.6,
        "south":47.2
      },
      "extent":[
        "2017-01-01T00:00:00Z",
        null
      ]
    },
    "regions":"/users/me/files/",
    "func":"avg"
  },
  "output":{
    "format":"GPKG"
  }
}

Response

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Access-Control-Allow-Origin: <Origin>

omitted (the GeoPackage file contents)