Open GoogleCodeExporter opened 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>.
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
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
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
gml:metaDataProperty