> Geospatial support is definitely an external project in any case. > As soon as something goes in the core, it's now > linked to our release process, I'm getting the tickets and complaints > personally, etc., theres no way a huge subject like geo support > belongs there.
I agree with you that it has to be an external project. I do not want to bog down SQLAlchemy's release process. > I'm just looking for smooth integration with PostGIS > and other geospatial SQL extensions. If we decide my observation > that GeoDjango has done a lot of work that needs to be re-done isn't > really valid, and everything they've done is only useful for Django > web applications, then that idea should be scrapped, and a simple > library which builds upon SQLAlchemy expression constructs should be > created. We need the SQLAlchemy extension to Spatialite in the lab now, so we'll get to work on that first. 1. As you suggested, we'll first try looking into making GeoDjango work as a plugin, in which case we'll get a lot of stuff for free. 2. Otherwise, we'll write our own stripped-down version for Spatialite and PostGIS. I'm aiming for a release of the plugin or extension by the end of May. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
