Geo and "field stalking"

I think that one of the reasons there are so many competing / non-collaborating solutions is that it's really hard to see past our own use cases into a more general focus. I think it would be a big mistake to build an ever-expanding collection of fields to input geographic data, and to try to imagine other cases.

It's also trouble to worry too much about street addresses. There's a large - and increasing number of use cases for locative data that have nothing to do with addresses: Point data for a geocoded photo or the presence of a marker (e.g. "landmine"), line data for an uploaded track, an area representing a particular precinct or zipcode, and so-on.

Meanwhile, data entry is in parallel with other types of data entry. Take, for example:

1) I'm a user and I want to upload a photo with geocoded exif data. I'm already familiar with the image upload UI, and there's no compelling reason to duplicate all of that data.

2) I'm a user and I want to update an address. I don't know/care about this geocoding stuff. I also have lots of reasons to enter addresses which are not necessarily on a 1:n node:address relationship. For example, my user profile has an address,

3) I already know coordinates, and I simply want to enter them into decimal fields. Thankfully, CCK already provides me with the capability to enter, validate and store this information. I shouldn't need a parallel UI.

4) I'd like to upload a GPX file from my device's track log. That's just a file, right? I upload files all the time.

5) I'd then like to upload non-encoded images, and set their nodereference back to my GPX-track-enabled node. Based on a little timestamp-alignment, my photo should be geocoded without my lifting a finger.

In all of the above cases, we have preexisting field work: ImageField, Location/Postal/Address/..., CCK's Number field, File API, NodeReference. These are receiving ongoing attention and security/usability improvements, and are already in a site manager's toolbox. We should be able to transparently convert these fields into meaningful GIS data, without messing with the content contributors' existing practices.

Thus, I propose we focus on a) geographic data storage and searching, and b) bridging to existing field types - with one pluggable, field-based module.

The administrative workflow should be subtle - we write connecters to various field types ( e.g. a geocoding bridge for the/a postal field, an exif-reading bridge for image fields, a GPX-parsing bridge for file uploads, and so-on. )

Rather than introducing new chrome to the mix, we can simply add a 'Store geographic data' checkbox on the field-wide settings for any field whose type has an available bridge.

The module then proceeds to stalk the updates/changes to the field it has attached to, making respective changes in its own storage backend.

By "the module", I'm generally referring to Geo, which means that by switching this single module on, you can instantly enable pre-existing fields to begin storing GIS data for Views and output formatters.