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

[Sean G. <sgi...@fr...>]

Cool ideas, J.F., I'm going to re-read this tomorrow and try to post
something constructive.

You've seen the other psycopg geometry thing mentioned on the
postgis-users list?

cheers,
Sean

On Friday, October 10, 2003, at 04:57  PM,=20
Jea...@CC... wrote:

> Gents,
>
> Alright, Sean's comments a while ago (About providing WFS Server
> functionality in pyogclib) got me thinking about how one would go=20
> about this
> ....
>
> I think I've got an idea down now that shoud work, and I need to put=20=

> 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=20=

> to
> start with PostGIS, though I hope to also use the python API to=20
> 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=20
> 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=20=

> 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=20=

> 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=20
> 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=20
> will be
> usable outside of PyOGCLib.
>
> Eventually I will have to abstract and separate all this functionality=20=

> into
> a sensible API architecture also of course, something I will keep in=20=

> mind as
> I go, and that will take form with time.  I will be especially mindful=20=

> of
> the necessity to have the ability to write database drivers of some=20
> form in
> order to support a wide range of underlying data sources.
>
> And finally (again), there's the configuration of things that aren't=20=

> from
> the datasource itself (server abstract and so on) ... This I wll=20
> probably
> not touch and leave to implementers to handle, providing only utility
> functions that would format/dump XML for them or something like that. =20=

> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Pyogclib-developers mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyogclib-developers
>