GSC Sentinel-2 PDGS OCD - Emits - ESA
GSC Sentinel-2 PDGS OCD - Emits - ESA
GSC Sentinel-2 PDGS OCD - Emits - ESA
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>GSC</strong> <strong>Sentinel</strong>-2 <strong>PDGS</strong> <strong>OCD</strong><br />
Issue 1 Revision 2 (draft) - 25.07.2010<br />
GMES-GSEG-EOPG-TN-09-0008<br />
page 109 of 350<br />
Although not generalised in all <strong>PDGS</strong> systems, hardware redundancy will be ensured on<br />
critical items such as the front-end processors (hot redundant) and will be embedded in the<br />
processing infrastructures through the management of a large number of compatible<br />
processing nodes. Archive redundancy will be ensured through a multi-site approach<br />
provisioning for at least dual redundancy on the overall mission archive.<br />
In complement, contingency operations will be provisioned for throughout the dataelaboration<br />
processes including data-reception, data processing and archive-to-archive<br />
circulation.<br />
4.5.2 DATA ACCESS CONCEPTS<br />
4.5.2.1 Product Data Handling and Data-Access Strategy<br />
Throughout the <strong>PDGS</strong>, the MSI product data will be managed as a set of physical product<br />
components hereafter referred to as Product Data Items (PDI). Referring to the Product<br />
Definition Document [RD-07], each PDI will be a set or excerpt of the following type of data:<br />
○ Image data<br />
○ Image metadata<br />
○ Image quality indicators<br />
○ Ancillary data (satellite orbit position, velocity, time, attitude)<br />
○ Orbit metadata<br />
○ Auxiliary data (GIPP, etc.)<br />
Each PDI will be self-standing as a physical item e.g. a GIPP file, the reflectance image of<br />
one band covering one tile, a quicklook image, the ancillary data covering a specific orbit, etc.<br />
On the other hand, all PDIs will be organised and referenced within a logical product<br />
hierarchy by implementing basic cross-PDI relationships. Examples of such embedded<br />
relationships are common in many EO products such as the auxiliary data used for<br />
processing, the mission orbit, geo-referencing information on an image subset (e.g. a tie-point<br />
grid), summary quality indicators on a set of along-track measurements, etc.<br />
Managing PDIs separately brings the immediate benefit of avoiding duplication of information<br />
(e.g. global ancillary data usage over an orbit, auxiliary data validity over long periods, etc)<br />
wile providing for flexibility in a distributed environment (the data composing one product may<br />
be scattered geographically in several remote archives).<br />
In the <strong>Sentinel</strong>-2 <strong>PDGS</strong>, this concept will be used substantially as an effective answer to the<br />
data-access challenge for the seamless provision of data products geographically scattered,<br />
with large volumes, and required by the users under stiff constraints for wide ranging<br />
applications of regional to continental scale.<br />
Based on the federation concept outlined in section 4.5.1.4, the PDIs generated and archived<br />
in each <strong>PDGS</strong> centre as well as circulated between centres will be globally federated allowing<br />
the overall PDI hierarchy to be maintained and redundancy to be managed consistently. In<br />
counterpart, data-circulation mechanisms between centres will be coordinated ensuring that<br />
<strong>ESA</strong> UNCLASSIFIED – For Official Use<br />
© <strong>ESA</strong><br />
The copyright of this document is the property of <strong>ESA</strong>. It is supplied in confidence and shall not be reproduced, copied or<br />
communicated to any third party without written permission from <strong>ESA</strong>.