GC: What goes into the featureOfInterest tag?

[GoogleCodeExporter]

I assume we shouldn't be implementing:

<sos:featureOfInterest xlink:href="FEATURE"/>

Original issue reported on code.google.com by wilcox.k...@gmail.com on 10 Oct 2012 at 4:05

[GoogleCodeExporter]

Just the id of the foi, right?

<sos:featureOfInterest xlink:href="foi-prudhoe-bay"/>
<sos:featureOfInterest xlink:href="foi-bligh-reef"/>

Original comment by sh...@axiomalaska.com on 10 Oct 2012 at 4:15

[GoogleCodeExporter]

xlink:href?

Original comment by wilcox.k...@gmail.com on 10 Oct 2012 at 4:35

[GoogleCodeExporter]

Yeah, seems weird, but CO-OPS, NDBC, and stock 52n all do it. Same with 
procedure and observed property.

Original comment by sh...@axiomalaska.com on 10 Oct 2012 at 4:41

[GoogleCodeExporter]

It looks like NDBC and COOPS just use a static:
<featureOfInterest xlink:href="urn:cgi:feature:CGI:EarthOcean"/>

The only exception is NDBC's network-all offering, which lists a bunch of 
things (like urn:ioos:event:tsunami::false:20080827103645_51406) that don't 
xlink to anything.

Should NcSOS just list:
<featureOfInterest xlink:href="urn:cgi:feature:CGI:EarthOcean"/>
for all offerings and call it done?

Original comment by wilcox.k...@gmail.com on 10 Oct 2012 at 4:51

[GoogleCodeExporter]

Hmm, well the 52n SOS stores location in the feature of interest, so each 
station needs to have a unique foi. This seems to be the classic "is the 
feature of interest the entire domain being sampled (EarthOcean), the site at 
which sampling occurred (Pilot Station), or some subset of the entire domain 
(Bering Sea)?" I'll selfishly advocate for the most specific station level foi, 
since that's the only place the observations are actually valid.

Original comment by sh...@axiomalaska.com on 11 Oct 2012 at 7:01

[GoogleCodeExporter]

If I recall correctly, the EarthOcean FOI was only a placeholder until the 
group could decide what really went there.  But that decision has been put off 
-- at least until now.  NDBC does list tsunami event FOIs in the network-all 
offering.  But the EarthOcean is used everywhere else and really has no meaning 
in the query.

Original comment by mike.gar...@gmail.com on 11 Oct 2012 at 7:14

[GoogleCodeExporter]

Like Mike said, I think the use of urn:cgi:feature:CGI:EarthOcean as FOI was an 
earlier recommendation in the absence of clearer guidelines. While we may not 
have talked a lot about <sos:featureOfInterest> in GetCapabilities, at the 
February workshop or afterwards, we've definitely discussed GetObservation's 
om:ObservationCollection/om:member/om:Observation/om:featureOfInterest
ad-nauseum. We're now taking full advantage of it in the GO response, whereas 
previously it was also just the EarthOcean placeholder.

Check out the GO Milestone 1.0 template for more details:
http://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/GO-
Station-SingleFT-timeSeries-MultiSensor.xml

So, everything points in the direction of dumping EarthOcean and using the 
offering's (procedure) id as the FOI. Is there a need for an foi id naming 
convention? Is an "foi" prefix required in the name, or should we use the 
station urn w/o any qualifiers? Does this mean a compliant SOS server *must* 
support a FeatureOfInterest request? I think we should be lenient, specially 
with ncSOS, and not require support for FeatureOfInterest requests just yet...

I don't think the use of foi=station doesn't preclude having additional, 
custom-defined foi's. So NDBC's practice of having tsunami-event foi's seems ok 
and not inconsistent.

Original comment by emilioma...@gmail.com on 11 Oct 2012 at 10:44

[GoogleCodeExporter]

Any additional comments on this issue?

Original comment by emilioma...@gmail.com on 17 Oct 2012 at 7:21

[GoogleCodeExporter]

Original comment by emilioma...@gmail.com on 17 Oct 2012 at 7:24

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

so use the offering id?

Original comment by wilcox.k...@gmail.com on 17 Oct 2012 at 7:29

[GoogleCodeExporter]

I think the guidance would be to use the procedure id (station id), which also 
happens to be used for per-station offerings.

So, proposed guidance:
* Use station procedure id for FOI id
* FOIs other than procedure ids can be used (e.g. tsunami FOIs)
* Don't require servers to support GetFeatureOfInterest at this point

Original comment by sh...@axiomalaska.com on 23 Oct 2012 at 10:55

[GoogleCodeExporter]

Going once...

Original comment by sh...@axiomalaska.com on 26 Oct 2012 at 9:54

[GoogleCodeExporter]

+1 for Shane's summary recommendations in Comment 11. I would just add:
- the recommendation for station procedure id's also applies to network 
procedure id/urn
- for other FOI types like NDBC's tsunami FOI's, should a prefix be added for 
clarification? say "foi-tsunami1234"? Or given that NDBC is already using a urn 
scheme for those events, maybe that urn is fine as is?

Original comment by emilioma...@gmail.com on 27 Oct 2012 at 10:20

[GoogleCodeExporter]

Any last comments before adopting this?

If the feature is a network, use the network's procedure ID
If the feature is a station, use the station's procedure ID
You can use other FOIs like for tsunamis

Original comment by wilcox.k...@gmail.com on 19 Dec 2012 at 8:45

[GoogleCodeExporter]

I think this is ready to close, but I can't think of an instance where you 
would want to use a network procedure id as the foi. I think the rule should 
just be:

For observations at stations, use the station's procedure URN id for the foi id.
Other arbitrary FOI ids can be used for special purposes.

Original comment by sh...@axiomalaska.com on 29 Dec 2012 at 12:10

[GoogleCodeExporter]

I think the tag is required.

If it is a network offering, use <featureOfInterest 
xlink:href="urn:cgi:feature:CGI:EarthOcean"/> as the FOI?

Original comment by wilcox.k...@gmail.com on 2 Jan 2013 at 8:49

[GoogleCodeExporter]

For networks, wouldn't you include all the fois of the contained stations?

Original comment by srstcl...@gmail.com on 2 Jan 2013 at 8:59

[GoogleCodeExporter]

i was afraid that would be the answer.

Original comment by wilcox.k...@gmail.com on 2 Jan 2013 at 9:02

[GoogleCodeExporter]

Hehe...are you concerned with the size of the GC response?

Original comment by srstcl...@gmail.com on 2 Jan 2013 at 9:16

[GoogleCodeExporter]

yeah.  we always hit some scalability issue... the problem lies in SOS not our 
implementation.  I guess this is good to close.

Original comment by wilcox.k...@gmail.com on 2 Jan 2013 at 9:48

[GoogleCodeExporter]

Original comment by wilcox.k...@gmail.com on 3 Jan 2013 at 3:00

• Changed state: Fixed