You can mock me for opening this and close this issue straight away, but before getting your project namespace (and locking into PostGIS), have you thought abstracting the storage out and providing a geo module for D7? This is not a small change, rather it reflects a massive effort to implement.

It would be great to be able to specify (unwisely) pure WKT for a generic db, and also providing a mechanism for enabling MySQL support, internally or via another module. Then there are others: Oracle (Oracle 11G not MySQL), SQL Server, SpatiaLite,... although I do not know what the status of these are in relation to the core db drivers for Drupal.

It appears that the dream of the geo module is almost dead. But this does represent the economics of attempting something on grand scale while being driven by the resources given to a mid-sized project.

Either way, great work in helping to pull Drupal into the 3D world :)

Comments

friedjoff’s picture

friedjoff commented
Status: Active » Postponed

I agree with you that having an abstracted storage layer to provide spatial data functions is a good idea. Seen from an architectural perspective, something similar to the Mapping module would be great. Modules like this one could implement such a module and provide different storage implementations behind a common interface.

The Geo module might be the best place, but you seem to be right with "obscurity ...". We tried to participate in the development with no luck, so we went the whole hog. In the short-term we want to implement a small module that focuses on spatial data storage using the Fields API. An abstracted storage layer and other features might be a good target for a 2.0 release. By than we probably have a clear view on how such an interface should look like. I'll mark this postponed until there is an abstracted storage layer available.

You might also be interested in the GeoServer module. Output of spatial data is mostly handled by GeoServer in our setup.