[georss] Design consideration in incorprating georss gml into environmental data schema

[Joshua Lieberman]

On Apr 13, 2008, at 7:55 PM, Andrew Turner wrote:

> On Sun, Apr 13, 2008 at 4:51 PM, Louis Sweeny
> <louis.sweeny at ross-assoc.com> wrote:
>> I work with www.exchangenetwork.net basically a partnership for
>> environmental data web services. We have COI's who develop complex  
>> rich
>> sets of schema for the hard core data (like water quality)
>>
>> Members have experimented with GML, but it turns out that 90% of our
>> services can get by with the georss gml subset so we are moving  
>> forward
>> with recommendations that our mish-mash of ad hoc tags for lat/long
>> points and line/areas be replaced with georss tags as people rev  
>> their
>> schema.
>>
>> I'm scratching my head about a few design issues (some of which the  
>> list
>> has already kicked around):
>>
>> 1) Is there any benefit to adoption of the "where" construct in  
>> complex
>> data schema? For example are there now or are there likely to be
>> services out there that would be able to scan a big file, with 7  
>> levels
>> of hierarchy, find some "where" tags and take a guess as to what to  
>> do
>> with them? Or is the where construct envisioned just for rss feeds.
>
> I know someone else more GML-happy will pipe-in on this with talk of
> Schemas & XSD's. So I'll leave that to them.
>
> However to simply answer your question: yes. People are using
> GeoRSS-Simple and -GML in a number of their own XML schemas and using
> GeoRSS as the location markup. (see ObsRSS for one example that may
> interest you).

To be brief, and not too "schematic", the georss:where tag serves as  
the geometry property. It is what connects the geometry such as  
gml:Point to something else (e.g. whatever the GeoRSS entry is  
pointing at). If you are already using a data schema with a geometry  
property and just want to limit the geometry it contains to those  
valid for GeoRSS,then just use the GML profile geometries. If the  
information doesn't already have a geometry property, then you need  
one to be consistent with virtually every standard for feature geodata  
and georss:where is about as simple as you can get.

>
>
>>
>> 2) We are trying to make our data services (e.g. GetWaterQualityData)
>> play well with geo services like wfs, wms and geo-rss services, so  
>> that,
>> for example, one could find a monitoring station via an rss or wms
>> service and then use our data service to drill down to the rich data.
>> That is making us realize that we want to complement our data  
>> services
>> with wfs/wms and rss feeds, so that folk can get to the data however
>> they want.  Anything anybody can think of, re the WAY we incorprate  
>> gml
>> tags into these data services that would make this easier or harder?
>
> The simplest would be to publish a GeoRSS feed of all the monitoring
> station locations (and make it searchable by BBOX). And each Entry
> would link to the the GeoRSS feed of that particular station that
> would include the individual measurements as individual entries and
> some sort of Obs XML for actually marking up the measurements.
>
> I would suggest offering, in addition to a WFS, this very simple
> solution of a hierarchy of linked GeoRSS feeds (Atom) of stations and
> then observations. That will greatly aid in understanding of potential
> users of the service.

Many WFS implementations, e.g. Geoserver, can actually output features  
as a feed, each entry of which contains (if I recall) a link back to  
the full GML feature which is being represented. That's probably the  
best approach for jumping from a GeoRSS "summary" to detail information.

>
>
> at least, those are just my thoughts. Definitely interested to hear
> what you develop in the end.
> Andrew
>
>
>
>
> -- 
> Andrew Turner
> andrew at mapufacture.com
> http://mapufacture.com - Helping build the Geospatial Web
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss