Hey All,

Great work on the module. I have created and attached a Geo Taxonomy Geocoder module. Its a first draft but everything seems to be working fine. Obviously the use case is to allow people to have geo coded terms with out having to manually enter (or map) each term. It has the following features:

* Ctools pluggable geocoder plugins (default is using Googles geocoding API)
* On creation and update of terms, geocodes the taxonomy name and sets geo term data
* Bulk update of vocabularies
* Drush command to perform bulk update

It seems sort of appropriate to have this within the Geo Taxonomy module itself, so I wanted to check with you first; its nice to have consolidation of modules. If you feel its out of scope, that is totally cool too, and I'll be happy to start a new project.

Thanks.

Comments

ademarco’s picture

Following.

alex_b’s picture

zzolo:

I love the feature of making geocoding really easy on geotaxonomy terms.

What was the rationale to make such a powerful module only integrate with geotaxonomy rather than a more general Geocoder module that loosely couples with geotaxonomy but would just as well geocode for instance plain text?

*Still thinking about this*

zzolo’s picture

Hey @alex_b. Good question. This is definitely more of the direction I would like to see, but here is my current reasoning for this.

* There technically already is the Geocode module which does this in practice but architecturally and maintenance-wise is not in the same direction that I, or probably you, would want. So, I just wasn't sure what to do as far as trying to communicate with Allie about changing that module or just create a new one. Basically the politics of the module soup. I am afraid the only real way to go is to create a new module (geocoder is still open) due to the state of that module.
* I was thinking of maybe using Geonames instead of Google API for geocoding and wanted to make it easy to switch out and have exportable code, but the Geocode module sort of rewrites the Ctools plugin architecture, so I wrote my own.
* Limited resource, time, and scope to what I am doing to address the full issue here.

Overall, I don't think it would be too hard to take out what I have done for the geocoding plugins and put it into another module. I'd be happy to move towards this, but think it will take some time to make happen due to my own time restraints and having to first discuss with Allie about her direction with Geocode, as it would just be rude to make another module that does the same thing without some sort of discussion.

ademarco’s picture

A module that would expose to third-parties geocoding capabilities would be really useful. As far as I know there are already three modules that use the same kind of logic:

  1. Alan's Geo Taxonomy Geocoder
  2. OpenLayers Geocoder: provides OpenLayers CCK input widget allowing to mark a location on the map by simply providing its address (Using Google Map APIs);
  3. OpenLayers Proximity: enables geographical proximity search for the OpenLayers module by exposing Views filters where users can specify starting point and radius of the proximity search; it uses Google Map API to geocode locations provided as input;

I actually would like to turn the geocoding part of 2. and 3. in something like 1. has: a pluggable geocoding system that could go behind Google Map APIs. Making it as a separate project, say "Geocoders", could be a real benefit for the aforementioned modules. I'm just free-thinking now: our clients feel comfortable with inputting locations using the Geocoder widget but they keep on asking why when they write "Georgia" the first option is US State of Georgia and not the Country of Georgia, between Eastern Europe and Western Asia. Having pluggable and configurable geocoders could help these kind of situations, which now affect all our three modules (one geocoder could, for example, filter results in some way).

@zzolo: I'm interested in such a development, I could give my contribution to such a project.

zzolo’s picture

@antoniodemarco, thanks for the thoughts. I think we all agree on having an abstracted Geocoder module. I think the major issue here is approaching this responsibly, meaning discussing with the maintainer(s) of the Geocode module, as this is the goal of that module as well.

The best approach may be to just write a modified version of geocode that utilizes ctools and then present it to Geocode, and if it is not accepted, start a new module. This is kind of what happened with OpenLayers module.

Also, this may be way out of the scope of this ticket. :)

zzolo’s picture

I have started an issue in the Geocode queue: #876558: Utilize CTools

If anyone can add more/better reasons to switch to a Ctools architecture, please feel free to add. I will try to talk with Allie in Copenhagen about this, then make some moves in the appropriate direction afterwards.

floretan’s picture

Also see #795066: Geocode terms based on term name which integrates geotaxonomy with the existing geocode module.

drupalinside’s picture

Subscribe

kndr’s picture

StatusFileSize
new653 bytes

@zzolo, nice module. Thanks! I've found a little bug in the variable name. I'm attaching the patch.

jcnventura’s picture

StatusFileSize
new8.06 KB

I've integrated the original patch with #9, and updated the bulk update to work with the latest 2.0-beta3.. For anyone who's interested..

João Ventura

YK85’s picture

Hi, I was wondering how this works. Does it check the term name and guess which one is the correct longitude and latitude for it? Sometimes there are multiple places with the same name so I was wondering how it knows which location is correct. Many thanks!

mqx66’s picture

Would you please provide details about how to use it? I have installed the Geo Taxonomy Geocoder, but I have no clue to use it and get the terms of vocabulary to the map.

Many thanks.

zzolo’s picture

Status: Active » Postponed

Just an update.

This is code attached to an issue. I cannot and will not support it. Use it at your own risk.

Also, it does not integrate with the new geotaxonomy that supports features/exportable taxonomies. Though this integration would only affect excluding terms.

Overall, my direction of this would be to put it in another module/project, but my time right now is very limited to do that.