[SensorML] how to specify that sensor is mobile in SensorML language, SensorML Digest, Vol 40, Issue 2
John Graybeal
graybeal at mbari.org
Wed Jun 11 19:13:45 EDT 2008
Pratik,
I'm sorry this took so long, I was hoping someone else would rescue me, but no. So I started to look up some of the information to answer this question, but got a bit slowed up by the not-quite-finished SensorML and OOSTethys web sites. I think this answer is reasonably likely to be correct and current at this point -- well, as correct and current as possible. (See conclusions at the end.)
First I want to describe this in an XML that describes the sensor system. Then I talk about what this means in the context of a GetResponse. I didn't have a single SML 1.0.1 XML document in hand that described an entire system just like yours, though there might be one at the SensorML examples page -- the aircraft/satellite examples should be instructive, at any rate.
Your email says you can not have a SensorML file for the Field Server. So the information for the Field Server will have to be in each file for each sensor, so the platform will be redundantly described; or you could reference a single higher-level description of the platform, that is kept off the platform (if your system is not internet-connected, this would preclude on-board processing using the SensorML description, though).
I went to the VAST site and eventually found their weather station example:
http://vast.uah.edu/downloads/sensorML/v1.0/examples/sensors/DavisWeather/DavisWeatherStation.xml
I wanted this because I knew it was a system, and I see it is updated to SensorML 1.0.1 (thanks are due to the SensorML team for producing an up-to-date version!).
You will see here a general outline that shows the station as a whole, with its coordinate frame described (sml:spatialReferenceFrame). Then the rest of the sensor positions are described within that same file.
The location of that coordinate frame is given in sml:Position (sml:PositionList); in their case it is hard-coded, in a Vector as it happens. But you want that coordinate frame to be variable. In that case, there is presumably a data stream that describes where the FIeld Station is, right? So what we do is describe that data stream, and everything that looks at your XML file will understand that the Field station is mobile. For an example of this, I turn to the camera system example, thankfully also 1.0.1:
http://vast.uah.edu/downloads/sensorML/v1.0/examples/sensors/Axis213PTZ/Axis213PTZ.xml
Here we have a spatial reference frame:
<gml:EngineeringCRS gml:id="SYSTEM_CRS">
and further down a definition to describe the coordinates (is there a bug in the systemCRS ID, maybe?):
<sml:output name="Gimbal Settings">
<swe:Vector localFrame="#cameraCRS" referenceFrame="#systemCRS">
<swe:coordinate name="Time">
<swe:Time referenceFrame="#systemClockCRS"/>
</swe:coordinate>
and so on, with various attitude coordinates. If you take the location vector from the weather station example, and specify it as part of these outputs, in the same way the camera example specifies its attitude values, I think you pretty much have what you want as far as the fundamental XML description is concerned. Pardon the arm-waving, I haven't done this myself yet but am about to do so in another context....
Now, as to the DescribeSensor request, the closest activity I know of to actually implementing this is OOSTethys (oostethys.org), though likely there are others. Searching Google for 'describeSensor example', the second link is http://www.oostethys.org/downloads/sos-cookbook-perl/sos-perl-cookbook, and the next to last link on that page is for a DescribeSensor call. In that case OOSTethys just returns the XML for the requested sensorID (hence my emphasis on the XML earlier). Alas, there are only two terms that might define the device type as mobile: the Identification.IdentifierList.identifer.Term for the W3C ID is urn:gomoos.org:source.mooring#A01 (this is also what gets returned as part of the <Procedure> in a GetObservation request), and the classification.classifier.Term for the MMI platform is .. empty. If you know a gomoos.org:source.mooring is mobile, you're set. Otherwise you might want to know of a good term in a more well known vocabulary.
As I may have mentioned before, as MMI cleans up its platform ontology (and finishes its ontology registry, and gets a URN prefix) this item will get filled out. In your case, as I look at the existing ontology, I see in MMI's platform ontology the term LandCrawler (subclass of Crawler that has EarthRealmBase . EarthLandSurface, and is an EarthSurfaceBasedPlatform). So I think in your case you could have a section that says something like
<classification>
<ClassifierList>
<classifier>
<Term definition="urn:mmisw:org:platform">
<value>LandCrawler</value>
</Term>
</classifier>
</ClassifierList>
</classification>
Obviously, big picture, this whole scene is not Totally Ready For Prime Time. I think we see how to do most things, but can not yet do all things operationally. If you can manage it, you are welcome to participate in the OGC, OOSTethys, and/or MMI activities to help bring into existence the things you need.
John
At 2:03 AM -0700 6/6/08, pratik shrestha wrote:
>Dear John,
>
>Thank you for your reply.
>
>As you had asked for my platform, it is land vehicle. Actually I have multiple sensors connected to a Field Server (<http://model.job.affrc.go.jp/FieldServer/Data-Storage_Us.html>http://model.job.affrc.go.jp/FieldServer/Data-Storage_Us.html).
>
>This Field Server I will keep in one of the land vehicle and move around. Each sensor in Field Server has its own sensorML file(And Field Server cannot have sensorML file) .Through DescribeSensor I have to reflect the application or human that my Field Server is mobile.
>
>So, can you help me for a sensorML file that describes about sensor and the platform that sensor resides in. Can you give a simple example. And if possible can you give me a hint to show this information from DescribeSensor operation of OGC-SWE.
>
>
>
>Thank you.
>
>Best Regards
>
>Pratik
>
>--- On Thu, 6/5/08, sensorml-request at lists.opengeospatial.org <sensorml-request at lists.opengeospatial.org> wrote:
>
>From: sensorml-request at lists.opengeospatial.org <sensorml-request at lists.opengeospatial.org>
>Subject: SensorML Digest, Vol 40, Issue 2
>To: sensorml at lists.opengeospatial.org
>Date: Thursday, June 5, 2008, 9:00 AM
>
>Send SensorML mailing list submissions to
> sensorml at lists.opengeospatial.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.opengeospatial.org/mailman/listinfo/sensorml
>or, via email, send a message with subject or body 'help' to
> sensorml-request at lists.opengeospatial.org
>
>You can reach the person managing the list at
> sensorml-owner at lists.opengeospatial.org
>
>When replying, please edit your Subject line so it is more
> specific
>than "Re: Contents of SensorML digest..."
>
>
>Today's Topics:
>
> 1. Re: how to specify that sensor is mobile in SensorML language
> (John Graybeal)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 4 Jun 2008 09:05:36 -0700
>From: John Graybeal <graybeal at mbari.org>
>Subject: Re: [SensorML] how to specify that sensor is mobile in
> SensorML language
>To: pratik shrestha <pratik_dbl at yahoo.com>
>Cc: sensorml at lists.opengeospatial.org
>Message-ID: <p06240818c46c6aad16e4@[192.168.1.101]>
>Content-Type: text/plain; charset="us-ascii"
>
>A few quick thoughts, that I'm sure someone else can improve upon. I
>don't have time to look up the details this morning, but this may put you
>on your way, and should provoke someone else into providing a fully accurate
>answer.
>
>SensorML has the concept of sensor systems, which can
> be platforms. You
>describe the sensor system in a way that meets your needs.
>
>If the sensor position is not defined, that can imply that it is mobile, but
>this is not rigorous.
>
>If the sensor type is provided, it can be a term that reflects its mobility.
>Example: using GCMD platform terms
>
>(http://gcmd.nasa.gov/KeywordSearch/Keywords.do?Portal=GCMD&KeywordPath=Platforms)
>you can drill down a layer to find (for example, in the In Situe Ocean-Based
>Platforms) AUV, Ship, and ROV. These are all inherently mobile. So if you use
>a term like that for your sensor type, people (and maybe even computers) will
>understand it is mobile. (The MMI Platform Ontology, currently undergoing an
>update, includes more comprehensive platform types. If you send me a
>description of your platform I can give you the term that fits.)
>
>You could also define your own terms for sensor system type, that just
> indicate
>that the sensor system is a mobile platform. This is less interoperable but
>perhaps most useful for you.
>
>Finally, I *think* you can create your own tag that addresses whether the
>platform is mobile, but I am a little unclear on this, and it will be less
>interoperable than using a sensor system type term.
>
>John
>
>
>
>At 3:42 AM -0700 6/4/08, pratik shrestha wrote:
>>Dear all,
>>I want to implement mobile sensor. In sensorML specification document that
>was published in 2002, I saw one term called "platform". But in new
>specification document I didn't see this term. Is this term
>"platform" still implemented in sensorML document. If yes, how to
>implement it. Can anyone send me one example document using this term
>"platform". If no, how to specify that my sensor (platform) is mobile
>in sensorML language.
>>
>>Thank you
>>Best
> Regards,
>>Pratik
>>
>>
>>_______________________________________________
>>SensorML mailing list
>>SensorML at lists.opengeospatial.org
>>https://lists.opengeospatial.org/mailman/listinfo/sensorml
>
>
>--
>----------
>John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
>Monterey Bay Aquarium Research Institute
>Marine Metadata Interoperability Project: http://marinemetadata.org
>Shore Side Data System: http://www.mbari.org/ssds
>
>
>------------------------------
>
>_______________________________________________
>SensorML mailing list
>SensorML at lists.opengeospatial.org
>https://lists.opengeospatial.org/mailman/listinfo/sensorml
>
>
>End of SensorML Digest, Vol 40, Issue 2
>***************************************
>
>
>
>_______________________________________________
>SensorML mailing list
>SensorML at lists.opengeospatial.org
>https://lists.opengeospatial.org/mailman/listinfo/sensorml
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
Shore Side Data System: http://www.mbari.org/ssds
More information about the SensorML
mailing list