Introduction OGC® Sensor Planning Service Implementation Standard

12 Co Example: Consider the webcam again. Authorized users may change the looking angle and the zoom value, whereas non-authorized users can only chose between three pre-defined settings. This concept of abstraction levels is described in more detail in section 6.5.

6.2 Client Server Interaction

This section explains the typical interaction between an SPS client and service. The interaction starts with the GetCapabilities request to explore what the service can offer. If additional information about a sensor is required, the DescribeSensor operation is used to retrieve all available information about the sensor see Figure 3. Figure 3 — client server interaction part 1 Next, the client needs to learn which parameters have to be set in order to task the sensor. The client sends a DescribeTasking request and receives a DescribeTaskingResponse, which defines syntax and semantic of each tasking parameter, including choices between different parameter settings, default values, and value ranges. Note: For complex missions, a huge number of parameters might need to be set by clients. Alternatively, the service might only provide a choice between five preconfigured missions, and then there might only be a single parameter to be set by clients, even though the missions are very complex in nature. It fully depends on the service provider to define the parameters the client shall or may set. The definition of tasking profiles is encouraged to reflect the specific requirements of different communities in a consistent way. Nevertheless, tasking parameters are encoded using SWE Common and the SPS provider should add semantic annotation to them. This allows generic SPS clients to display more specific parameter descriptions including their semantic annotations so that a client can still meaningfully task an asset even if the client software does not provide any other support for this activity which client software that was specifically developed to support certain tasking profiles will most probably do. pyright © 2011 Open Geospatial Consortium Co After the client learned about the tasking parameters, it can choose to either submit a tasking request Submit operation or to perform a feasibility check GetFeasibility operation – see Figure 4. Both operations create – if valid and accepted – a SPS assigment called task. Other operations allow to reserve and update a task, which will be discussed later on. Figure 4 — client server interaction part 2 Note: Before being accepted, each tasking request is checked for feasibility by the service. Even though a tasking request has been reported previously as feasible, it does not mean that this task is still feasible at the time of submitting the task. The façaded asset might have been tasked by someone else in the meantime or became unavailable see clause 6.3.4 for further details. The GetFeasibilityResponse contains a StatusReport, which indicates that the tasking request is or is not feasible. Optionally, the report lists alternative sets of tasking parameters that might help the client in formulating a tasking request that is feasible and that satisfies his information needs. pyright © 2011 Open Geospatial Consortium 13