[OSGeodata] geodata schema

Stefan F. Keller sfkeller at gmail.com
Wed Aug 2 20:51:36 EDT 2006


Tom, you wrote Wed, 2 Aug 2006 11:31:43 -0400:

> I see two levels of decision here:

>

> 1./ RESTful interface

> 2./ underlying information model

> 2./ output content model


 With 'underlying information model' do you mean that information that can
be taken for requests?

> I would go with a WFS as the interface standard (flexible API).  In our

> experiences with owscat, we found WFS to be flexible, and can already be

> integrated with WFS client tools, as well as the option of going with

> open source WFS servers out-of-the-box (MapServer, GeoServer, deegree).



Don't take me wrong WMS and WFS are good specs. But WFS make reference to
Filter. And for a simple protocol I'd like to have a simple query language,
mainly to boolean and perhaps wildcard matches. So IMHO WFS query should be
really profiled and constrained to REST (no SOAP).



The fact that open source WFS exist out-of-the-box is a plus. But what about
repositories in other languages like C or C# (as many commercial desktop
GIS)?



What I have in mind is that even pure data file provides (like KML, Shape,
DXF, GeoTIFF, etc.) can participate - without a database and without SQL
engine.



OAI-PMH offers a spec. and implementations - as well as services and
gateways - called static repository:
http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm .



Forgive me when I mentioned that spec. again. I think code first, think
later will allow for several approaches here.



> For an information model, I would envision a model (or db tables) like:

>

> service_endpoints

> service_resources

> data_resources

>

> Where service_endpoints and service_resources are basically a split of

> an OGC Capabilities XML document (service vs. layer metadata) with

> foreign key refs associating them.


Don't understand this yet, have to think about this again.


Is'nt something like those 6 queries from OAI-PMH enough combined with the
minimally extended Dublin Core (including coverage as spatial constraints
(bbox)) as output content model enough whereas every attribute from the
extended Dublin Core can be queried? From the response the harvester/crawler
can see that its a file (protocol value = 'file:') or a service and - if
service - make a subsequent GetCapabilities request which contains all
further information?


> For an output content model, as a WFS, we can offer a multitude of

> output formats:

>

> Data: OWSCommon (which is based on ISO19115/9), FGDC, DC

> Services: OWSCommon (which is based on ISO19115/9)



Is there an UML diagram for both OWSCommon for data and services?



> We can also provide an operation to a GeoRSS feed for 'most recent'

> entries.



Yes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20060803/8a8624ad/attachment.html


More information about the Geodata mailing list