search

crim-ca / weaver

Weaver: Workflow Execution Management Service (EMS); Application, Deployment and Execution Service (ADES); OGC API - Processes; WPS; CWL Application Package
https://pavics-weaver.readthedocs.io
Apache License 2.0
24 stars 6 forks source link

[Feature] Support sensor-specific file format #111

Open fmigneault opened 4 years ago

fmigneault commented 4 years ago

GDAL handles by itself BEAM-DIMAP format. Processes could support this format with a twist (ie: zipped variant) if they desire so, but still up to the process to manipulate the data.

A typical BEAM-DIMAP is composed of a <product-id>.dim file and a <product-id>.data directory with many other files under it.

To differentiate from any other zip, we could have application/dim+zip since there isn't any explicit mime-type for it. This would help a process figure out if it should unzip the file first and then change .zip t .dim to find everything where expected.

With BEAM-DIMAP-specific ZIP format, we still have a problem regarding different sensors (Sentinel, RADARSAT, etc.) that employ the same "file format" although very different underlying structure. We need a more accurate method to indicate how to filter inputs/outputs for those specific use cases (eg: Process working only for a given type of sensor).

Relates to https://github.com/opengeospatial/wps-rest-binding/issues/38

smrgeoinfo commented 3 years ago

what about using parameters on the MIME type, e.g. application/zip; type=beam-dimap, application/zip; type=beam-dimap-sentinel, etc. The application/zip registration doesn't specify any parameters; Would adding a parameter would break anything?

fmigneault commented 3 years ago

@smrgeoinfo I don't think that would break anything. Obviously, it would work only within Weaver since it is not standard.