Loading...
 
ESA > Join & Share > Forums > HMA Forum > Extension of "processing/ProcessingInformation/processingMode"

HMA Forum

Help

Show posts:
Jump to forum:

Extension of "processing/ProcessingInformation/processingMode"

In the standard EO metadata profile described in OGC 10-157 "Earth Observation Metadata profile of Observations & Measurements", the "processing/ProcessingInformation/processingMode" attribute is described as follow (in the xsd): "Processing mode. Often referred to as Real Time, Near Real Time etc. Should be a value from ProcessingModeValue. As the precise definitions of these terms vary, this enumeration uses more generic terms.".
Current possible values are enumerated in ProcessingModeValue and are: DATA_DRIVEN_PER_ACQUISITION, DATA_DRIVEN_DAILY, OFFLINE, OTHER, MULTI_MISSION.
In the case of Sentinel-1, there's a need to better qualify the timeliness with values: NRT-10m, NRT-1h, NRT-3h, Fast-24h, Arch-6h, ArchRush, ArchNormal.

What is the recommendation/suggestion of this forum ?:
1- to extend the list of values for "Processing mode" -> change of the spec
2- to use a vendor specific local attribute


Re: Extension of "processing/ProcessingInformation/processingMode"

Unfortunately there is no data dictionary for the processingMode valids in OGC 10-157 and I also don't know who the originator is.
What I found is the following XML-schema with a bit of documentation in the ProcessingModeValueType definition
https://svn.opengeospatial.org/ogc-projects/cite/scripts/wcseo/1.0/trunk/resources/omeo/eop.xsd
where I don't see how the Sentinel-1 timeliness valids could map.

However, the Sentinel-1 valids are specified in the sen1:timeliness element in the Sentinel-1 extension of the SAR schema in OGC 10-157r3 last page (but a data dictionary is also missing). See
https://portal.opengeospatial.org/files/?artifact_id=47040

There the problem is that these valids can only be used for Sentinel-1, although they could in principle be applicable for other missions also, but platform and instrument are fixed as Sentinel-1 and SAR in the sen1:EarthObservationEquipment element. So to speak a vendor specific parameter.

Therefore I opt to
a) ignore the processingMode element and
b) move the sen1:timeliness element to the eop namespace even if this takes some time for the OGC standardisation process and the discussion if other valids should also be included. For the time being the sen1 namespace could be used and after standardisation of eop:timeliness only the namespace would have to be changed while the XML structure remains the same.


Re: Re: Extension of "processing/ProcessingInformation/processingMode"

> Unfortunately there is no data dictionary for the processingMode valids in OGC 10-157 and I also don't know who the originator is.
> What I found is the following XML-schema with a bit of documentation in the ProcessingModeValueType definition
> https://svn.opengeospatial.org/ogc-projects/cite/scripts/wcseo/1.0/trunk/resources/omeo/eop.xsd
> where I don't see how the Sentinel-1 timeliness valids could map.
>
> However, the Sentinel-1 valids are specified in the sen1:timeliness element in the Sentinel-1 extension of the SAR schema in OGC 10-157r3 last page (but a data dictionary is also missing). See
> https://portal.opengeospatial.org/files/?artifact_id=47040
>
> There the problem is that these valids can only be used for Sentinel-1, although they could in principle be applicable for other missions also, but platform and instrument are fixed as Sentinel-1 and SAR in the sen1:EarthObservationEquipment element. So to speak a vendor specific parameter.
>
> Therefore I opt to
> a) ignore the processingMode element and
> b) move the sen1:timeliness element to the eop namespace even if this takes some time for the OGC standardisation process and the discussion if other valids should also be included. For the time being the sen1 namespace could be used and after standardisation of eop:timeliness only the namespace would have to be changed while the XML structure remains the same.



the fact is that the sen1 namespace is actually not used anymore by ESA. In the design consolidation phase of ngEO, it was decided to not use any mission extension of the thematic layers and therefore to ignore the sen1 namespace. This is why there was this attempt to re-use the eop:ProcessingMode to substitute the formerly defined sen1:timeliness attribute.

The proposal to promote the timeliness attribute to the eop namespace is therefore most welcomed.


Re: Re: Extension of "processing/ProcessingInformation/processingMode"

The HMA-S task 3 project is currently preparing a revision of OGC 10-157.
The change requests are summarised within https://wiki.services.eoportal.org/tiki-download_wiki_attachment.php?attId=2602&page=HMA-S%20Task%203&download=y .
There is already one change request that is asking for the addition of a timeliness element at product/ProductInformation level within the eop schema.
This corresponds to the proposed sen1:timeliness element in table 28. Contrary to the definition of the sen1:timeliness element, the proposed change request however does not fix the values to a fixed enumeration but allows to use a mission specific code list where a codeSpace attribute can be used to identify the specific codelist.
The advantage of this approach is obviously the extensibility. An alternative could be to work with a type that is defined a union of an enumeration and a string type. This allows to define a number of preferred values but also allows to define other values when required. An example of an element using this construct already in OGC10-157 is sensorType: enumerated values are RADAR, LIMB, ... but in addition values like "other: XXX" are allowed.

Questions:

1/ Should we define the timeliness element as having a mission specific code list (free for each mission) or as "extensible enumeration" based on the sentinel-1 values but allowing other values to be freely added.
2/ In case an "extensible enumeration" is chosen, are there modifications/additions to the Sentinel-1 list?
3/ If it is felt that the processing/ProcessingInformation/processingMode enumeration does not make too much sense, now is also the moment to change this provided that we stay backwards compatible. Backwards compatible changes could be to extend the enumeration with new fixed values and "other:" values and/or setting some of the existing values to deprecated. An alternative could be to turn it a mission specific code list.


Re: Re: Re: Extension of "processing/ProcessingInformation/processingMode"

ad 1) As timeliness means different time ranges defined for different missions, coupled with orbit quality and other processing quality aspects this suggests the per mission with codeList approach.

Maybe a structured element would be reasonable:
In addition to the above a time range value with the sematics of time passed from sensing or catalogue search to delivery could be added as a subelement of timeliness:

timeliness
|--missionSpecific
|--timePassed

where the mission specific valid partially determines the meaning of time passed e.g. ArchRush includes archive retrieval time but no downlink time.

ad 3) currently I cannot tell if the processingMode valids make sense since they are semantically undefined. But I also think that non-mission-specific valids we know, like NRT, NOMINAL, REPROCESSED etc. should be added (together with their definition). Any other?



Re: Extension of "processing/ProcessingInformation/processingMode"

Glad to see that EUMETSAT somehow faced a similar issue. Did they opt for using a local attribute instead ?


It would be interesting to know/understand:
1- who sponsored the current code list (DATA_DRIVEN_PER_ACQUISITION, DATA_DRIVEN_DAILY, OFFLINE, OTHER, MULTI_MISSION) ?
2- If there is any shared understanding of the meaning of the current values (e.g. the specification does not explain what OTHER or MULTI-MISSION is supposed to mean, leaving room for different interpretations to the detriment of interoperability)
3- what is the logic of this code list ? (e.g. MULTI-MISSION does not seem to be exclusive to the other values)



Re: Extension of "processing/ProcessingInformation/processingMode"

> In the standard EO metadata profile described in OGC 10-157 "Earth Observation Metadata profile of Observations & Measurements", the "processing/ProcessingInformation/processingMode" attribute is described as follow (in the xsd): "Processing mode. Often referred to as Real Time, Near Real Time etc. Should be a value from ProcessingModeValue. As the precise definitions of these terms vary, this enumeration uses more generic terms.".
> Current possible values are enumerated in ProcessingModeValue and are: DATA_DRIVEN_PER_ACQUISITION, DATA_DRIVEN_DAILY, OFFLINE, OTHER, MULTI_MISSION.
> In the case of Sentinel-1, there's a need to better qualify the timeliness with values: NRT-10m, NRT-1h, NRT-3h, Fast-24h, Arch-6h, ArchRush, ArchNormal.
>
> What is the recommendation/suggestion of this forum ?:
> 1- to extend the list of values for "Processing mode" -> change of the spec
> 2- to use a vendor specific local attribute

EUMETSAT doesn't fill the present attribute, since the values given don't to what we understand about processing mode value. We have values like Normal, BackLogged, Reprocessed, Validate and I believe the S-1 are closed to my understanding a processing mode.



Show posts:
Jump to forum: