So I've seen what the Place module is doing on the WSF2008 website. Looks good, but I was wondering about the implementation steps. Having enabled the taxonomy_location.module myself, am I correct that they are as follows:

1) Create a hierarchical taxonomy vocabulary.
2) Manually assign a latitude/longitude to each of the terms.
3) Assign the terms to nodes.
4) Configure your theme to render a gmap for each of the pages that displays a particular taxonomy term (potentially using panels).

If I'm understanding correctly, I don't see how the module is actually integrating with location at all. What I would like for urbanministry.org (see the volunteer search, accessible from www.urbanministry.org/volunteer) is a way to extract the locative data that we already have in our database (Country, State/Province, City) & map each of those elements to a taxonomy term in a hierarchical vocabulary.

It doesn't matter to me whether the terms themselves have lat/long associated with them. What I want is a hierarchical index of the location-enabled nodes on our site, something like a Yahoo-style directory which shows how many there are in the United States, in Massachusetts, in Boston, etc.

Is this within the scope of the Place/Taxonomy Location module, or is this something different than what you're going for? Also, is there a more recent version of the module?

Finally, if you don't plan to incorporate this functionality into Taxonomy Locations, do you know of any other modules that I should consider? I definitely appreciate your efforts toward improving the state of geolocation in Drupal.

Comments

mlncn’s picture

mlncn commented

When everything with the Place suite, Taxonomy Location, and Location itself is set up correctly it works this way:

When something needing a location is entered, the person types in the city, state/province, country-- if this is already in the system, it autocompletes.

If not in the system, the act of creating a location-enabled node will create the necessary taxonomy term locations. Each taxonomy location automatically queries to get its own latitude and longitude.

The hierarchy is created on the fly. You don't need to find and define East Podunk in advance.

Things can be cleaned up on the admin side with Taxonomy Manager, though the integration could work a lot better. I think I did all I could with form_alter.

Location module is used to store the address, street, and the lat-lon for the node itself, and so maps and all work as always.

As you might gather, it all really needs some funded development or even deployment for smoothing edges, if you're in a position to do so.

For your particular feature request... your data in Location would not have lat-lon for country, state, and town separate from the street location, but as mentioned this can be grabbed automatically. I could certainly see how an import script could be written, and should be made part of this set of modules.

We'd need help, sponsorship or code, to promise anything on any reasonable timeline. Let me know before getting into the code though as I think it may need the latest committed to CVS.

Thanks for your interest in the taxonomy way of doing locations!

benjamin, Agaric Design Collective

EvanDonovan’s picture

EvanDonovan commented

Thanks for the clarification and update on the module's status.

I have looked at the code a bit. The latest commit version is 1.2, but it doesn't look any different from the original commit. If you have a more recent version of the codebase to commit to CVS, that would be greatly appreciated.

From your description, it looks like the custom solution you've implemented for the WSF2008 website is more polished than the Place module version that I'm working with. Either that, or I misconfigured something, since I was basically guessing at what I was supposed to do.

Have you looked at the Google Client Geocoder module at all? That module has pretty much exactly the UI and feature set that UrbanMinistry.org needs (in terms of integrating geolocation data w/taxonomy terms).

However, we can't use it, since we already have all our data in the Location table. That's why your module looked interesting, except that it seems like we'd have to reimport our data to make use of it and writing such an import script would be a non-trivial task. I recently wrote a script to update the geolocation data for all our location nodes; that in itself was not easy.

summit’s picture

summit commented

Subscribing.
greetings,
Martijn