valentinedwv / ioostech

Automatically exported from code.google.com/p/ioostech
0 stars 0 forks source link

Representing featureType in a DescribeSensor request #60

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
As it stands now, you have to make a GetObservation request in order to figure 
out what FeatureType a particular procedure is.  

We do this in the GetObservation:

gml:metaDataProperty

timeSeries/gml:name /gml:metaDataProperty ``` I recommend we do this in DescribeSensor on non-network procedures: ``` sml:valuetimeSeries (or whatever)/sml:value /sml:Term /sml:classifier ``` This may require adding a 'featureType' definintion to MMI, unless there is already an existing one for the CF featuretypes. Comments/Suggestions? ``` Original issue reported on code.google.com by `wilcox.k...@gmail.com` on 27 Jun 2013 at 4:04
GoogleCodeExporter commented 8 years ago
Cheryl just brought to my attention that a single statino procedure can and 
will often have more than one feature type.

Anyone against listing all featuretypes in a DescribeSensor, for both stations 
and networks?  I didn't look into SML to see if there is a better way to list 
multiple values inside of a <sml:classifier>.
sml:valuetimeSeries/sml:value /sml:Term /sml:classifier sml:valuetimeSeriesProfile/sml:value /sml:Term /sml:classifier ``` ``` Original comment by `wilcox.k...@gmail.com` on 27 Jun 2013 at 6:09
GoogleCodeExporter commented 8 years ago
I'm fine with it. Are you proposing that this be an addendum to Milestone 1.0, 
or part of Milestone 1.1? Maybe it could be m1.1 but encouraged to add to m1.0?

Not sure if this should be a classifier or a capabilities element. The SensorML 
spec says that both should be considered metadata for sensor discovery, and 
that classifiers should be used for "rapid discovery" and that capabilities 
should be used for "further filtering." Pretty vague. Here's an example 
capabilities encoding:

<sml:capabilities name="featureTypes">
  <swe:SimpleDataRecord>
    <swe:field name="featureType1">
      <swe:Text definition="http://mmisw.org/ont/ioos/definition/featureType">
        <swe:value>timeSeries</swe:value>
      </swe:Text>
    </swe:field>
    <swe:field name="featureType2">
      <swe:Text definition="http://mmisw.org/ont/ioos/definition/featureType">
        <swe:value>timeSeriesProfile</swe:value>
      </swe:Text>
    </swe:field>
  </swe:SimpleDataRecord>
</sml:capabilities>

Original comment by sh...@axiomalaska.com on 28 Jun 2013 at 1:32

GoogleCodeExporter commented 8 years ago
Also, as a side note, the capabilities encoding I just posted shows the need 
for a AbstractSimpleComponentArrayType or similar in SWE. It would have been 
really helpful in several place to be able to do this instead:

<sml:capabilities name="featureTypes">
  <swe:SimpleDataRecord>
    <swe:field name="featureTypes">
      <swe:TextArray definition="http://mmisw.org/ont/ioos/definition/featureType">
        <swe:value>timeSeries</swe:value>
        <swe:value>timeSeriesProfile</swe:value>
      </swe:Text>
    </swe:field>
  </swe:SimpleDataRecord>
</sml:capabilities>

Original comment by sh...@axiomalaska.com on 28 Jun 2013 at 1:37

GoogleCodeExporter commented 8 years ago
If I had a choice I would keep it in SML, but it doesn't really matter to me.

Tagged as milestone 1.1, not important but will be good to have in the future.

Original comment by wilcox.k...@gmail.com on 10 Jul 2013 at 3:01