[Requests] 09-000, Sensor Planning Service Standard 2.0 Comments

Fairgrieve, Scott M (IS) Scott.Fairgrieve at ngc.com
Wed Apr 14 08:46:16 EDT 2010




1. Evaluator:

               Scott Fairgrieve

               Northrop Grumman


               scott.fairgrieve at ngc.com


2. Submission: 09-000, Sensor Planning Service Standard 2.0







1. Requirement: DescribeTasking response/Submit request interaction 



2. Implementation Specification Section number: DescribeTasking (7.3.4),
Submit (7.3.5), and example sections (7.4, Annex F)



3. Criticality: Minor, Editorial



4. Comments/justifications for changes:  


After reading the spec., it's unclear how one would represent sensor
commands as distinct sets of parameters through the current interface.
Many times, the tasking messages that are sent to a sensor are specific
commands that are made up of one or more parameters.  Common Chemical,
Biological, Radiological, and Nuclear (CBRN) Sensor Interface (CCSI)
sensors are one case of this.  There are distinct commands for making
the sensor perform particular functions (e.g. Set_Ccsi_Mode, Silence,
Register, Start_Self_Test, etc.).  In this case, you would never mix and
match parameters from different commands in a single request.  For
instance, using a webcam example, an SPS provider might want to allow
the following commands:  LookAt with parameters for setting a lat, lon,
alt to look at; PTZ with parameters for pan, tilt, and zoom, etc.  With
the current SPS 2.0 setup, it seems (I could be wrong on this) that the
DescribeTasking response would have one taskingParameter element (the
spec. indicates that there can only be one) with a DataRecord with all
parameters beneath it: lat, lon, alt, pan, tilt, zoom or a DataRecord
with nested DataRecord element beneath each field?  This would be
confusing from both the client and server standpoint.  If the client
sets lat, lon, and pan in a single request, those seem to be conflicting
settings and there's nothing that tells the client how the server will
handle such a request.  I guess there is the possibility of using a
DataChoice element with separate DataRecord elements beneath it to
describe different command message options?  If so, I think the current
spec. would benefit greatly from more examples, particularly more
complex examples.  How would a client tell the server in a Submit
request that it is using a particular DataChoice option, particularly
with a TextEncoding based request?  What is the advantage of having the
DescribeTasking response include only one taskingParameter element, why
not allow multiple taskingParameter elements with different ID
attributes/names?  This would allow for the distinct command behavior to
be supported, but would require some additional information in the
Submit request to tell the server what taskingParameter was being used.


The other thing that is unclear is how optional parameters described in
the DescribeTasking response are treated when passed in a Submit request
with TextEncoding.  The optional parameters example in section 7.4 does
not include a corresponding client response like the other examples in
that section do.  Does the sps:values element need to include empty
values for optional components that are not set separated by the
tokenSeparator character (e.g. 2.0,,North,,,,3.0 when the
DescribeTasking response includes parameters 1 - 7 and parameters 2, 4,
5, and 6 are optional)?  


I see that the Submit request can use options other than TextEncoding
(e.g. XMLEncoding), but there aren't examples in the spec. of how these
are used.  For instance, is it possible to issue a Submit request with
the SWE Common option of specifying parameter values in each field
definition of a DataRecord or other data type - could this XML snippet
be passed in a Submit request?


<swe:DataRecord definition="urn:foo:def:CameraTaskingParameters" ...> 

<swe:field name="f_length"> 

<swe:Quantity definition="urn:ogc:def:property:OGC::FocalLength>

<swe:uom code="mm"/> 




<swe:field name="infrared_mode"> 

<swe:Boolean definition="urn:ogc:def:property:OGC::NightMode"> 






If so, then I think it would make sense to include examples of this in
the SPS specification in order to ensure that readers fully understand
the spec.    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opengeospatial.org/pipermail/requests/attachments/20100414/3dc01e3f/attachment.htm 

More information about the Requests mailing list