[Pyogclib-developers] WFS Server: Ideas, comments ...

[<Jea...@CC...>]

Gents,

Alright, Sean's comments a while ago (About providing WFS Server
functionality in pyogclib) got me thinking about how one would go about =
this
...

I think I've got an idea down now that shoud work, and I need to put it =
down
before I forget it :) I'm also looking for comments of course!

First of all, I need to support a wide range of datasources. I'm going =
to
start with PostGIS, though I hope to also use the python API to =
shapelib.

The mental strugle I've been going through is how to handle the GML
reading/writing.  I've decided that the GML module will be expanded to
handle WKT and/or WKB as input, as well as DOM nodes (Which it already
supports). This is very OGC'ish, and should provide a broad range of
support.  This will allow the system to instanciate python geometry =
classes
from any data source that can be made to provide WKT/WKB.

THEN, I will also add the functionality for each of the GML geometry =
classes
to be able to write themselves out as xml ( .toxml() ).

And, finaly, I will have some sort of utility method that will wrap a =
python
DB 2.0 record and map it to a GML featureInstance, using the above
functionality.

A side-effect of this work will be the inclusion in this project of =
some
code that will extend psycopg for support of the 'geometry' PostGIS
datatype. I've already done this successfully I'm glad to say! This =
will be
usable outside of PyOGCLib.

Eventually I will have to abstract and separate all this functionality =
into
a sensible API architecture also of course, something I will keep in =
mind as
I go, and that will take form with time.  I will be especially mindful =
of
the necessity to have the ability to write database drivers of some =
form in
order to support a wide range of underlying data sources.

And finally (again), there's the configuration of things that aren't =
from
the datasource itself (server abstract and so on) ... This I wll =
probably
not touch and leave to implementers to handle, providing only utility
functions that would format/dump XML for them or something like that.  =
There
would be no HTTP handling, GET/POST handling, or anything like that, at
least not for now.

Ideas, comments and constrcutive criticism welcome as always!

Cheers, and have a good week-end ...

Jean-Fran=E7ois Doyon
Internet Service Development and Systems Support
GeoAccess Division
Canadian Center for Remote Sensing
Natural Resources Canada
http://atlas.gc.ca
Phone: (613) 992-4902
Fax: (613) 947-2410