Issue 60 in ioostech: Representing featureType in a DescribeSensor request

[ioos...@googlecode.com]

Status: Accepted
Owner: wilcox.k...@gmail.com
Labels: Type-Defect Priority-Medium

New issue 60 by wilcox.k...@gmail.com: Representing featureType in a
DescribeSensor request
http://code.google.com/p/ioostech/issues/detail?id=60

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:
```
<!-- CF Feature Type (discrete-sampling-geometry). -->
<gml:metaDataProperty>
<gml:name
codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">timeSeries</gml:name>
</gml:metaDataProperty>
```

I recommend we do this in DescribeSensor on non-network procedures:
```
<sml:classifier name="FeatureType">
<sml:Term definition="http://mmisw.org/ont/ioos/definition/featureType">
<sml:codeSpace
xlink:href="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries"/>
<sml:value>timeSeries (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?

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ioos...@googlecode.com]

Comment #1 on issue 60 by wilcox.k...@gmail.com: Representing featureType

in a DescribeSensor request
http://code.google.com/p/ioostech/issues/detail?id=60

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:classifier name="FeatureType">
<sml:Term definition="http://mmisw.org/ont/ioos/definition/featureType">
<sml:codeSpace
xlink:href="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries"/>

<sml:value>timeSeries</sml:value>
</sml:Term>
</sml:classifier>

<sml:classifier name="FeatureType">
<sml:Term definition="http://mmisw.org/ont/ioos/definition/featureType">
<sml:codeSpace
xlink:href="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries"/>

<sml:value>timeSeriesProfile</sml:value>
</sml:Term>
</sml:classifier>
```

[ioos...@googlecode.com]

Comment #2 on issue 60 by sh...@axiomalaska.com: Representing featureType

in a DescribeSensor request
http://code.google.com/p/ioostech/issues/detail?id=60

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>

[ioos...@googlecode.com]

Comment #3 on issue 60 by sh...@axiomalaska.com: Representing featureType

in a DescribeSensor request
http://code.google.com/p/ioostech/issues/detail?id=60

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>

[ioos...@googlecode.com]

Updates:
Labels: Milestone-Release1.1

Comment #4 on issue 60 by wilcox.k...@gmail.com: Representing featureType

in a DescribeSensor request
http://code.google.com/p/ioostech/issues/detail?id=60

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.

[Derrick Snowden - NOAA Federal]

One limitation to consider is that there is a CF/netCDF limitation that states one netCDF file will have only one featureType.  This has obvious implications for ncSOS.  What are the station instances that you know of now that have more than one featureType?

--
--
You received this message because you are subscribed to the Google
Groups "ioostech_dev" group.
To post to this group, send email to iooste...@googlegroups.com
To unsubscribe from this group, send email to
ioostech_dev+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/ioostech_dev?hl=en

---You received this message because you are subscribed to the Google Groups "ioostech_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ioostech_dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Derrick Snowden
System Architect, US IOOS
1100 Wayne Ave, Suite 1225
Silver Spring, MD 20912
+1 301 427 2464 (o), +1 301 427 2073 (f)

Find us on Facebook