Is there any interest in merging this module with Geofield? As a co-maintainer, I would be very interested in looking at ways to store Geofield's data in something better than textfields when possible. I think working together would us expand the capabilities of Drupal mapping, plus it would have the added benefit of not having duplicated work between the two modules.

CommentFileSizeAuthor
#11 geofield-backend-1436752-11.patch428 bytesBrandonian

Comments

friedjoff’s picture

friedjoff commented

We are definitely interested in working together on a more generic spatial storage module. Right now we need a working implementation, but in the medium term a merged module sounds like the best way forward.

Another option would be an abstracted spatial storage layer, as discussed in http://drupal.org/node/1367432.

How would you tackle this issue?

Brandonian’s picture

Brandonian commented

Very cool. I think Alan D. has the right idea in the other thread. I think we should build on what Geofield current behaviors as the default, but check to see if the server/db is set up to handle anything better (ie, PostGIS, MySQL's geo behaviors, I think CouchDB has some spatial features now, etc).

What I find interesting about your module is the notion of using the spatial db fields if you're using postgres. I had no idea you could do this with Drupal. It seems like once you can store the data in a native format, the only issue left is interacting with it in a meanful manner, no matter the database field type. Seems like we could probably write an interface for that sort of thing, so that we could use the same code for interacting with the data.

phayes’s picture

phayes commented

+1!

It would be cool to see this in the geofield 2.x branch.

phayes’s picture

phayes commented

Just another thought on this:

For geofield 2.x we should remove the wkt column and replace it with a "geom" column which would be a blob / geometry. By default the column would simply store WKB as a binary blob. If postGIS is installed and we are using a geometry column, everything should be transparent as WKB is the format that postGIS uses anyways.

We would also get some speed improvements since geoPHP can parse and write WKB far faster than WKT - and our databases get a little smaller too!

friedjoff’s picture

friedjoff commented

Interesting idea! Storing the geometry as WKB in a blob column sounds especially useful in conjunction with geoPHP. But I wonder if it is possible to avoid the overhead of geoPHP and additional text columns (bbox and lat/lon) in case of a PostGIS database.

How about a backend interface for the geofield module? Besides geoPHP and PostGIS I could think of MongoDB, CouchDB and SpatiaLite. Each backend would implement an abstract class provided by geofield that includes all functions necessary for hook_field_schema, hook_field_is_empty and Co.

phayes’s picture

phayes commented

Hi friedjoff,

I'd certainly support the idea of an advanced pluggable backend system, but am also leary of it. This is the kind of thing that the geo module tried to do, but in the end it never really worked well and was buggy. If we have someone who is a PDO / field-api ninja and is willing to put in the time, then great - but if not then I would rather put our sights on something that seems more achievable, likely simply using WKB / geometry (which will be tricky enough!)

phayes’s picture

phayes commented

Another thought: We should definitely keep the columns no matter what - other modules (like geoRSS) assume that these columns exist and make use of them. It doesn't cost much to store some extra floats in a database. I think the db-size savings we will get from moving from WKT to WKB will be tons and more than makes up for it.

friedjoff’s picture

friedjoff commented

Hi phayes,

to get things started I worked on a proof of concept for a pluggable backend system:

Geofield: http://drupalcode.org/sandbox/friedjoff/1515034.git/tree/refs/heads/7.x-...
PostGIS: http://drupalcode.org/project/postgis.git/shortlog/refs/heads/7.x-1.x-ba...

Using these branches allows you to select a backend for each field instance. Just PostGIS is supported as a backend right now and only the WKT widget and formatter work. But still it wasn't to much of a hassle and I think it should be possible to achieve a stable backend system without to much ninja skills. Implementation details are open for discussion of course.

Regarding the database columns: If we implement a pluggable backend system other modules should only depend on a generic interface provided by the Geofield module or maybe even the Geo module. The db-size savings might be negligible, but having different storage backends with a clean data model available might be worth the effort.

What do you think about this direction after all?

Brandonian’s picture

Brandonian commented

Agree with #7, Having precalculated data should help some of the pain of dealing with different data storages, even if it means we're data heavy.

@friedjoff, I saw your sandbox come up today on my RSS reader. Looks very interesting. I plan on messing around with it a bit this week.

Brandonian’s picture

Brandonian commented

Relevant to this discussion, would love feedback from PostGIS maintainers...

#1728530: Pluggable storage for Geofield for alternative databases

Brandonian’s picture

Brandonian commented
Title: Merge with Geofield? » Implement new Geofield pluggable backend
Status: Active » Needs review
StatusFileSize
new geofield-backend-1436752-11.patch428 bytes

Coming from #1751300: Refactor Geofield into separate fields for different storage purposes to help with db-specific implementations and #1728530: Pluggable storage for Geofield for alternative databases and #1751300: Refactor Geofield into separate fields for different storage purposes to help with db-specific implementations, this is a patch to implement Geofield's new pluggable storage system in the phayes-pluggable-storage branch. There are probably some tweaks that need to happen, but I wanted to go ahead and get this on the PostGIS maintainer's radar.