[OSGeodata] WFS-basic and geometadata exchange

Wed Oct 25 09:14:23 EDT 2006

GeoRSS/Atom output is falling under use case i) "WFS as a data access point
which delivers simple XML-encoded geospatial vector data" but not with GML
as mandatory WFS output.

I understand this thread to fall under use case ii) which discusses
geo-*meta*-data exchange. This does not mean that its worthwhile to discuss
GeoRSS output out of WFS-basic - but I think this should be held in another
thread.

-- Stefan

2006/10/25, Pat Cappelaere <pat at cappelaere.com>:
>
> 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;><http://example.com/osgeocat?service=WFSBASIC&version=1.0.0&>
> 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/eea0b387/attachment.html