[SensorML] Trajectory or BBOX in SensorML?

Mike Botts mike.botts at botts-inc.net
Fri Jul 30 17:16:49 EDT 2010

Jeff and Mike.


Hope you don’t mind that I’ve greatly expanded the discussion participants. J


This leads into an important  discussion that starts with whether a sensor’s trajectory is really metadata or itself observed data from the System (“One man’s metadata is another man’s data, and visa versa”). It can of course be both. For a dynamic sensor system, position (location and orientation and possibly derivatives such as velocity and acceleration) is based on measurements from a GPS and/or IMU within the system; so, it IS observed data. But often we wish to consider it as metadata as well, primarily for the purpose of discover (“what sensors were looking at this location?”).


Anyway, we have certainly supported dynamic platforms such as aircraft (including UAVs), moving ground vehicles, etc. with SensorML and SWE Common. We often support this as data from the System and utilize this data to do geolocation of imagery, video frames, and other measured data along the way. The question and confusion comes when someone wants to use it as “metadata” for discovery or what-not and thus wishes to specify this using the “location” or “position” element for sml:Component or sml:System. 


The idea of saying that a weather station or fixed buoy is at a particular location (always) leads most people to want a location or position (= location and orientation) for the station, and they consider this metadata for the station. Makes sense, so we have the ability to give any Component or System a location (taking gml:Point or a gml:_Curve) or a position (taking either a swe:Vector, swe:Position, or a sml:_process). For static systems, the position is usually a swe:Vector or a swe:Position which typically has two Vector elements (one for location such as lat-lon-alt or ECEF XYZ, and an optional one for orientation). 


For dynamic systems, one could use the “location” element with a gml:_Curve (hopefully a time-tagged one) or they could use the “position” element with a sml:Process. We didn’t allow swe:DataArray for position because we felt that specifying the platform’s position at any time required the discrete measured locations, orientations, and derivatives, along with an interpolation procedure (though I’m not certain that was a great idea). Thus, the process would have time as an input and position as an output. We also have a SensorML process that can be configured to call a specific SOS with a specific time range and receive a positions as output. Thus one could “discover” the sensor’s location for a given time or time range by requesting the data from the SOS.


I would like to hear more open discussion about this for SensorML 2.0 because these different ways of handling things between static and dynamic systems has always been a source of confusion. If they remain different, the approaches should be explicitly illustrated in the SensorML documentation.



Mike Botts


PS. The old SensorML schema browser that was originally on the UAH VAST site, has now been relocated to:





   Mike Botts, Ph.D.                 

   Botts Innovative Research, Inc        

   126 Stoneway Trail                          

   Madison, AL 35758    


  (256) 652-0165 (cell)

  mike.botts at botts-inc.net




From: Jeff.deLaBeaujardiere at noaa.gov [mailto:Jeff.deLaBeaujardiere at noaa.gov] 
Sent: Friday, July 30, 2010 12:53 PM
To: Mike Garcia; Mike Botts
Subject: Re: Trajectory or BBOX in SensorML?


Mike & Mike-

I tried to look at the Sensor ML spec on my cell phone but the experience was more frustrating than informative. There must be a way to specify the trajectory of a moving sensor.  Perhaps Mike Botts (CCed) can point us in the right direction. 

-Jeff DLB via HTC Evo 4G

----- Reply message -----
From: "Mike Garcia" <Mike.Garcia at noaa.gov>
Date: Thu, Jul 29, 2010 11:54
Subject: Trajectory or BBOX in SensorML?
To: "Jeff de La Beaujardiere" <Jeff.deLaBeaujardiere at noaa.gov>


I have not found a proper method for displaying a trajectory or bounding 
box in a SensorML response.  Can you point me in the right direction?  
For now, the glider stations are returning the last known position for 
the DescribeSensor response.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opengeospatial.org/pipermail/sensorml/attachments/20100730/7b714131/attachment.htm 

More information about the SensorML mailing list