Andrea Aime wrote:
Ch
It would have to be possible to add the schema defined be the WFS-G "spec" to the list of schema base from which one could choose. It also might be necessary, depending on the data source for the feature type and the definition of the schema, to be able to map the attribute/column names in the data source to different names in the featureType schema - basically because the exact details of those names is more important when you are trying to match a predefined schema, and being forced to rename the columns in your data source just to match the schema is a bit onerous.
I haven't yet looked to carefully at the other aspects of the WFS-G "spec" yet, but it seems like providing WFS access to features in the correct schema is the minimum/first step. I'll be looking more into the details, but I was hoping someone might be able to point in the right direction.
WFS-G was very carefully designed to be supportable by a minimal "sensible" WFS - its perfectly legal to have an implementation that is limited to the GML Level 0 profile by igniring some of the optional, (but intrinsically useful) possible attributes. All you have to do is to serve two feature types - SI_Gazetteer and something derived from SI_LocationInstance.
For example, you siumply dont need to create or allow query across parent/child relationships - these are optional. But if you have them, the spec tells you exaclty what they must look like.
The issue with off-the-shelf legacy systems is they insist on owning the namespaces, feature type names and attribute names, binding them to the persistence layer (eg database tables, columns) not to the "contract" between the server and the client (the target schema).
The "community schema" extension support we are working on addresses this, as well as the ability to support complex data types and Feature types. A Gazetteer profile is in my roadplan to implement and bundle with geoserver, but its behind a number of more challenging but funded, and slightly overdue, activities to support time-series and Observations patterns.
I'm cc'ing Rob Atkinson since he's one of the spec authors.
Anyways, from my first cursory look at the spec I gather the following:
* GML3 output is required (we have this in Geoserver trunk)
yep - pretty much any real world requirement will be GML 3.1 or 3.2 from now on.
* complex feature support is required
partially, but I think the per-attribute namespace support will be the issue here.
The latter is a problem, since we don't have any complex feature support
at the moment, and this limitation will stand for another few months.
Also, it does not seem possible to handle the complex nature in the
output format only (and have a flattened out data storage) since
LocationInstance has a tree structure (parent, children).
Yet, I may be wrong, Rob?
We should be OK in a limited implementation.
Also, Rob and Gabriel are working on a complex feature prototype,
don't know if that one has better luck of satisfying your needs.
We have this close to ready - I've just loaded a test case for TimeSeries data that the underlying Geotools community-schema datastore works with.
The main issue is getting this extension module into mainstream releases, and fixing the need to clone most of geoserver while the main bits avoid the feature model upgrades.
Still, we'll get something working ready for Geoserver 1.6 release as an optional extension.
Rob Atkinson