SPS Application Profile for EO Sensors OGC 07-018r2
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
10
5.3. XML notation
Most diagrams that appear in this document are presented using an XML schema notation defined by the XMLSpy tool and described in this subclause.
Hereafter the symbols defined in the XML schema notation are described:
Optional single element without child elements
Optional single element with child elements
Mandatory single element.
Mandatory multiple element containing child elements. This element must occur at least once Minimum Occurrence = 1 and may occur as often as desired Maximum Occurrence =
unbounded.
Mandatory single element with containing simple content e.g. text or mixed complex content e.g. text with xhtml markup.
A sequence of elements. The elements must appear exactly in the sequence in which they appear in the schema diagram.
A choice of elements. Only a single element from those in the choice may appear at this position.
Types. If an element refers to a complex global type, the type is shown with a border and yellow background.
SPS Application Profile for EO Sensors OGC 07-018r2
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
11 Complex Type. The following figure illustrates the use of a complex type for defining an
XML element
5.4. Document terms and definitions
This document uses the specification terms defined in Subclause 5.3 of [OGC 05-008c1].
SPS Application Profile for EO Sensors OGC 07-018r2
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
12
6. System context
This section focuses on the purpose, scope and policies of Programming services that comply with this document. It documents special requirements and describes the context of use.
6.1. Application domain
The programming service described in this document has the objective of supporting the following 2 types of requests:
Order of precisely identified typically specifying the sensing start and stop times future
products. This type of orders are referenced as Acquisition Orders in this document;
Order asking the coverage of a specified area in a specified time window. This type of
orders are referenced as Coverage Orders in this document; In this document, these orders will be referred to as Programming Requests.
Each requested item in the Programming Request will be referred to as Task.
For the first type of programming requests the process is very similar to the one described in [NR12] for ordering products:
The client identifies i.e. calculate the sensing start stop times the products to be acquired. This step is not covered by this document.
Next, for each product going to be ordered, the list of tasking parameters is required. Next an order for future acquisitions is built on the client selecting the needed tasking
parameters for each item to be ordered. When the programming request is prepared, the client can ask the feasibility analysis. The
result of the analysis can be returned sync async depending on its complexity, the technical financial proposal is returned as a document sent by mail e-mail.
If the result of the previous step is successful, then the client can submit the programming request. In case of unfeasibility of the request, the service can suggest possible alternative
parameters. The progress of the programming request can be actively monitored by the client or can be
notified to it. If necessary the programming request can be cancelled.
For the second type of programming request the process is the same apart from the first step: the client does not have to identify the products, but has to specify only the time window of interest
and the geographical area to cover.
SPS Application Profile for EO Sensors OGC 07-018r2
Copyright © 2008 Open Geospatial Consortium, Inc. All Rights Reserved.
13
6.2. Reference scenarios
Kategori