[OSGeodata] WFS-basic and geometadata exchange

[Pat Cappelaere]

Stefan,

I am missing something:  Why do you want to have this implemented by
WFS-Basic?
I do not see how the output can be used by following WFS-Basic calls for
data especially if we focus on GeoRSS/Atom output.
Please, enlighten me :)
Thanks,
Pat.


From: "Stefan F. Keller" <sfkeller at gmail.com>
Reply-To: <geodata at geodata.osgeo.org>
Date: Wed, 25 Oct 2006 11:18:48 +0200
To: <geodata at geodata.osgeo.org>
Subject: Re: [OSGeodata] WFS-basic and geometadata exchange

Tom, Raj,
 
I like this proposition. Sorry for my silence, I was busy implementing a
directory which builds on the vision of a geometadata network :->.
It seems to me, that there are at least to different main scenarios for such
a WFS-basic around: i) WFS as a data access point which delivers simple
XML-encoded geospatial vector data (with GML as mandatory output) and ii)
WFS-basic for geometadata exchange within a geometadata network.
 
According to the thread this is my sketch of a geometadata network: A
catalog (or repository or registry) is a collection of geospatial resource
descriptions, like descriptions of datasets (html/ftp) or WMS/WFS services
which in turn point to (= hasPart) dataset descriptions they are
'responsible' of. There exist also filter service descriptions which are
responsible for processing feature types, not datasets. A catalog is tightly
coupled with geospatial resource descriptions (= datasets, WMS/WFS and
filter services) and can be searched by humans and/or machines. Geospatial
resource owners register to catalogs (in OAI-PMH lingo catalogs are called
(meta-)data providers). Sophisticated protocols - like WFS or SRU - allow
interoperation of federated catalogs in real-time, with the advantage of
complex queries but with the prize of dependency on common protocol versions
and non-scalability.
To lower barriers, catalogs should have simple interfaces to other catalogs
or to directories or to general search engines. Such collections of
structured metadata are called (metadata) service provider in OAI-PMH lingo.
Sophisticated web mapping applications or desktop GIS' could hook to these
metadata service providers. Metadata service providers are loosely coupled
among each other as well as to registered catalogs they are 'harvesting'
periodically - and they may be greedy, i.e. looking actively for new
catalogs.

This is where WFS basic or OAI-PMH comes in. The operations needed are
GetCapabilities (OAI: Identify), GetFeatureType (OAI: ListMetadataFormats )
and GetFeatures (OAI: ListRecords). What's crucial there is the query
language and the response output.

Query/protocol: In order to manage large catalogs, incremental harvesting
comes in; thus the bounding box and a date start/end range. So far,
compatibility with WFS seems maintained. As I said at FOSS4G I don't mind
something like 'WFS-simple' although this is 'GIS-centric'. From a
neogeographers perspective it seems to me unanswered, what's the value of
compatibility to Google, which reads OAI-PMH already.

Output/model: GML is a just an XML encoding specialized to geospatial types.
A minimal geometadata model still remains to receive consensus. DClite4G
could be such an information model.

 -- Stefan

2006/10/23, Kralidis,Tom [Burlington] <Tom.Kralidis at ec.gc.ca>:
> 
>> > dear all,
>> >
>> > I have not been thinking very hard about simple geometadata
>> > exchange interfaces recently  but every time i hear someone
>> > mention Raj's WFS-basic effort I jump a bit. You look at the
>> > query interface to it and it is very simplified - no Filters,
>> > just a bounding box and date start and end range. There is a
>> > DescribeFeatureType function which right now is returning a
>> > pile of XMLSchema description verbiage.
>> > I see a big place for dclite4g / GeoRSS in here - i would
>> > like to see Tom's OWSCat done over WFSBasic. One could even
>> > add in OAI-PMH functions like ListRecordTypes [sic?] as well,
>> > if needed. Am i making sense?
>> >
>> > http://www.ogcnetwork.net/wfsbasic
>> >
> 
> I like WFS basic, as it lowers the barrier / buy-in cost for the
> general.  Although, from the OGC point of view, this may be confusing
> (WFS-basic has always meant a non-transactional WFS, as opposed to this
> new thing).
> 
> The big advantage, IMHO, would be the easier filters.  Building OGC
> Filters, while not a huge huge job, may be cumbersome for the
> non-converted.
> 
> http://example.com/osgeocat?service=WFSBASIC&version=1.0.0&
> <http://example.com/osgeocat?service=WFSBASIC&amp;version=1.0.0&amp;>
> request=GetFeature&outputformat=dclite4g&typename=services&keyword=*road
> s*
> 
> ...would search all Services whose keyword metadata matches roads.
> 
> In either case, a client must do a DescribeFeatureType to see what's
> going on under the hood of the typename.
> 
> Note that something like owscat already does this, but the client has to
> setup the <Filter> constructs.
> 
> For me, I don't mind either interface for discovery.
> 
> 
> ..Tom
> 
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20061025/ceea56c5/attachment.html