This page last changed on Feb 25, 2005 by dblasby.

I've been talking to people about using Hybernate (or some other object-relational mapper) and Dave Z's fancy GML parser to allow geoserver to handle complex database schemas as complex object and have them available to and from GML.


> My point about WFS's also relates to the idea of supporting more than
> flat-table geo-objects through PostGIS. Is this practical, or should
> the overlying WFS / CSW engine be re-assembling tables into other
> schema's, or is "Spatial DB in a box" the way to go (similar to what any
> Hibernate-based approaches would have to utilize, for example)?

I've been thinking about ways of allowing much "richer" GML support in
Geoserver (more generally, but starting in geoserver). Most systems
out there only support very simple GML - a geometry and a set of
simple attributes - much like you get out of a single DB table or a
shapefile. GML's much more expressive than this.

I was thinking about this more abstractly - if you look at what the
non-spatial DB people have been doing over the last dozen years, you
can see that spatial data users a bit behind the times.

Geoserver/Geotools have done an excellent job of abstracting data
access behind the DataStore abstraction. In the generic view, this is
much like being able to have your generic application talk to any sort
of database and read in a table.

Later people wanted to abstract this even more and started using
object-relational mappers (like Hybernate and TopLink) that allowed
the application to ignore the fact that it was talking to a database
(or whatever the persistence layer is) and just send and receive nice
objects. This allowed the database to change how the tables were laid
out, and how the relationships (like 1:many) were actually handled
without having to modify the application. The application programmer
is happy because he/she only deals with these nice objects while the
mapper takes care of all the gory details and bookkeeping.

Geotools/Geoserver does most of this right now because it hand back a
generic Feature (something like a JDO) from the Datastore.

The WFS is very much like an abstract object store - it accepts
request in an object query language (OGC Filters), goes to the
persistence layer to grab objects, then describes the response with a
GML schema and the actual content/objects in a GML file.

I was thinking of trying to combine all of these ideas by sticking an
object-mapper (most likely to be Hybernate initially) inside a
datastore so it sits between geotools/geoserver and the actual
database. The next step is to integrate the Hybernate configuration
with a GML schema. The end result is a data layer thats like this:

a) Database (in some table structure) with your actual data in it
b) Hybernate configuration that maps your database tables to complex,
but nice, objects
c) GML schema for the hybernate JDO objects

In this way, you can have your WFS serve up much more complex GML
objects (for example, with nested objects and 1:many relationships)
plus you should just be able to just attach your WFS to an already
existing very rich data model - for reading and writing.

I, unfortunately, havent yet had time to deeply think this through,
but it is quite interesting...

dave blasby

A similar capability has been prototyped using a ISO feature model and the ability to map "in process" SQL views via a grouping function to create objects with a simple repetition of elements, with arbitrary deep element nesting in the GML application schema.

This handles some pretty complex GML application schemas, and draws on the wonderful work by Justin Deoliviera on the WFS 1.1 bracnh, including the ability to parse real-world (i.e. very hairy) GML application schemas that use ISO19115 metadata (using the ISO 19139 schemas)

see Observations and Measurements

Posted by rob_cto_sco at Jul 05, 2007 12:50
Document generated by Confluence on May 14, 2014 22:59