[Requests] SensorML (RFPC 31) Response

Mike Botts mike.botts at nsstc.uah.edu
Thu Apr 13 15:17:18 EDT 2006

Part A is to be completed once per evaluator per comment submission.  Please
iterate over Part B as needed. 


Dr. Mike Botts
Principal Research Scientist
University of Alabama in Huntsville
mike.botts at uah.edu

 2. Submission: OGC Request 31: OpenGIS® Sensor Model Language (SensorML):
Request for Public Comments  

 1. Specification Section number: [GENERAL, #] : General

 2. Criticality: [MAJOR, MINOR, EDITORIAL, ETC.] : MINOR Revision/Extension

 3. Comments/justifications for changes: [COMMENTS, SUGGESTIONS] : Add

Currently, most simple physical sensor components (e.g. detectors,
actuators, filters, etc) are modelled in SensorML as a <ProcessModel>.
Therefore, ProcessModel provides an optional <referenceFrame> property for
associating a <ProcessModel> with the real world.

We recommend:

(a) that referenceFrame be removed from ProcessModelType (and ProcessModel)
so that a ProcessModel represents a "pure" process without a relationship to
geospatial/temporal domain (e.g. a process model to calculate wind chill
factor or a process model for histogram equalization). ProcessType would
include metadata group, inputs, outputs, parameters, and method properties,
but not referenceFrame.

(b) that the concept of a sml:Component be re-introduced; however, rather
than a Component containing processes, as was modelled in previous schema, a
Component would instead associate an atomic process to the real world
through referenceFrame and position properties. Thus, sml:Component would
derive from sml:ProcessType by extension and would have referenceFrame and
position properties in addition to the existing metadatagroup, inputs,
outputs, parameters, and method properties. Component would be used for
sensor components where position in the real world are important.

(c) referenceFrame would be removed from ProcessChain as well, providing a
"pure" process chain definition. As it is currently designed, sml:System
would relate a process to the real world by providing referenceFrame,
positions, etc.

These changes do not change the existing functionality at all, but merely
make a cleaner break between "pure" processes and those processes that are
related to the real world by geospatial position, physical interfaces, etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/requests/attachments/20060413/5b107664/attachment.html

More information about the Requests mailing list