Posted by Summit on March 16, 2011 at 8:26am
15 followers
Jump to:
| Project: | Location |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Hi,
I see that issue http://drupal.org/node/260726 is closed, but I do not agree location/taxonomy integration is finished. I think with enabling the location fields country, province, city in their own vocabulary, and hierarchy in this vocabulary, controlled by location, would benefit a lot! Because then the whole taxonomy range of modules comes into location scope!
See also other users in favor of this implementation:
http://drupal.org/node/260726#comment-4215530
http://drupal.org/node/260726#comment-1554206
Thanks a lot for considering this!
Greetings, Martijn
Comments
#1
+1
#2
+1
#3
+1
#4
+1
What are you using a work around for now?
I want user to be able to input a location using the location module so it can be geocoded and shown on a map.
Then I want people to be able to search by region, say Central America and the node geocoded with Brazil will come up.
Thanks,
Lauren
#5
@lauren - yes typical scenario ... it would interest me too ...
#6
Hi,
My workaround is AND, AND. I have a taxonomy with all geo, and use location with all geo locations. It is double work to insert, and not efficient.
Would love to see the location geo be 100% connected to the taxonomy system!
greetings,
Martijn
#7
I only want to do this with the location country field. Is there a work around for that? Any way to pull from the location field into a taxonomy field automatically? I don't want the user to have to input twice.
#8
+1
#9
subscribing
#10
I have a question about implementing this. This is functionality that I need for a site I'm making. I'd like to confirm that other people on this issue are having similar ideas about this implementation, and ask a question about the implementation. I'm by no means a Drupal expert, so input would be highly appreciated!
The reason I need something like this is that I'd like to have users submit nodes with locations, and then be able to:
In order to do both of the above I need to maintain a list of submitted cities, and the states for which they were submitted. It seems that a logical way to implement this is using the Taxonomy system, with the Taxonomy hierarchy mirroring the Country -> State/Province -> City hierarchy. This is, as I understand it, what is being requested in this issue. Does this sound like what everyone else on here is interested in? I just want to make sure.
If so, I have a question. I am trying to decide how exactly to store the location info in the taxonomy. I've considered the obvious structure, where all locations are stored in the same "Locations" vocabulary, structured like:
-Country
--State/Province
---City
Of course, continent or region could be added too as a level above Country. But I've also considered storing smaller vocabularies for the cities of each state. You would then have a bunch of vocabularies which might be named us_ca_cities (for all cities submitted in California), and so forth. States could also be saved in vocabularies like us_states, etc. It seems to me somehow that this would achieve the same functionality (the right vocabulary would just have to be selected), while avoiding the need to handle a huge "Locations" vocabulary and dealing with child/parent relations when doing things like retrieving terms for use in an autocomplete widget.
Is this a valid concern? A valid solution? Or is the one big Locations vocab the way to go?
Thoughts? I would love to implement this in a way that would allow me to contribute it back to the community.
#11
+ 100
I have been looking for this too, for years. Additionally the country/region/city hierarchy structure should at the same time be the base of Taxonomy, Menu, Path and Breadcrumb. And translatable. Frankly I think it's basic for any worldwide, multilanguage focussed website.
Still haven't found the answer.
Of course (re)creating country/region/city under taxonomy (duplicating info in the database, additional manual input) is an option. But I am also trying with combinations of modules like Taxonomy-Menu or Adv-Taxonomy-Menu, Taxonomy-breadcrumb or one of the many others. I find it to be an everlasting investigation.
By the way, I think the structure should be a little more extensive, and with a small additional possiblity:
Structure: Country/Region/City/District(!)
Region should not just be state or province (those politically determined boundaries as someone correctly mentions in some post), but also any other possible region like coasts (Costa del Sol), nature parks, mountain ranges and such. If state/province-lists already exists, great! but leave the possibility to introduce those other regions. This would of course be particulary useful for sites that cover more than one country and may not want to be limited to that ever state/province focus.
"District" for webs that want to narrow in on more specific parts within a city (Manhattan as most obvious example... but also red light district in Amsterdam, Quartier Latin in Paris, Brera in Milan...)
The additional (complicated?) possiblity would be for cities to be able to belong to more than one region: for example Malaga belongs to the province of Malaga, the Autonomous community of Andalusia and the Costa del Sol. This goes in fact for all cities and town that are part of a coast or nature park, belonging both to that park and it's political region (province, state, county, comarque...)
But well.... just dreaming and sharing thoughts.
#12
+1
#13
+1
#14
I've continued to look for a way to do this, complicating myself even a bit more by including the option to have users add more regions, cities or districts....
And I figured this actually can be achieved simply with Taxonomy + Hierarchical select. Although there is one problem: The Hierarchical Select module doesn't work properly (http://drupal.org/node/778472 and http://drupal.org/node/1123296).
If HA would do as it's said to do then you could forget about locations (for Geo Hierarchy that it, but still keeping it fot lat/long and address)
The configuration:
- Save term lineage
- Allow the user to choose a term from any level
- Allow creation of new terms
- Allow creation of new levels (3 - for example)
should allow you and your visitors to start from a (your) country (if you could get it in to start with..) go to (or add) a region, go to (or add) a city and go to (or add) a district. This way your geo database would fill up little by little with each item you add to your content. In fact there is no real need to have countries, regions or cities in your database you actually have no content for, right?
And if you allow multiple selections, cities could even belong to several regions.
Don't forget to select "Use the Hierarchical Select form element for this vocabulary." (it's put in such a way you can easily oversee it).
So in my understanding the hypothetic solution is there, it's just a question of HA being fixed to try out.
By the way, tired of waiting I just enabled access to tryout.onamap.org so anyone can check the HA problem for him/herself in some future.
user: keep
password: dreaming? (yes, it includes the question mark)
#15
@suffering drupal:
I think the issue here is automatic integration between the Location module and the Taxonomy module. That is to say: Take location information (city, province, country, etc), which was input through the Location module, and store it (duplicate it) in a hierarchical taxonomy. Automatically.
The HS module, as you describe, facilitates using and adding to this taxonomy. But it doesn't provide a solution for the automatic integration I just described.
#16
I fully agree with you Goron. This is first thing I expected when I started with Drupal, and ever since. In fact it's part of my suffering.
If Drupal is supposed to be so socially and multi-everything focussed, how come this did not come as an integrated part since Drupal 0.x??
Location + category (yah, taxonomy) integration is one of the key starting points for any international oriented website. However, in the end, it seems Drupal is actually used very little in this sense. (And I have the feeling this is still not considered in D7 or 8)
I don't know anything about PHP, hooks, tokens or any of that kind of insider knowledge, so everything I ever have tried to set up with Drupal always has required some workaround. And so I ended up (stuck) with only 1 working comercial/live site and have long decided to just go back to plain HTML if ever I get my hands free from Drupal to start up something new.
Anyway, even if copying (even if it's automatic) the same information from one table to another appears to me as far from elegant, I definitely would consider this as a 0-option. Absolutely a better workaround than what I am trying now. But even so, but I am afraid I lack the knowledge to work out that automation process. And it seems most people since this is an issue that exists since I started with Drupal (2007) and has never been solved, while it sounds so simple: allow Location to be a Vocabulary...
So that's why I decided to forget about Location as a whole and started to try with Hierarchical select to manually build this Geo-vocabulary. How unfortunate that HS now turns out NOT to work with the core module it seems to have been created for. The suffering is not over yet.
In any case, thank you for your suggestion Goron.
#17
Hi,
Newest location patches integrate the google api (http://drupal.org/node/826656 and http://drupal.org/node/839412), so you can chooses country, city from the api.
It would be great if this info only for the places in the site, should also be considered as categories/taxonomy.
Then without double work, and without single work in your own site, you can start building a geographical categorizing in your site easy.
Would a programmer consider building this for drupal using may be HS? I think it would benefit the whole community a lot!
Greetings, Martijn
#18
I'm interested in trying to develop something for this functionality in the next few months. I will start to look into it, and post the plan I come up with for implementing this here, so I can get feedback from those interested in this. @suffering and @Summit, thanks for your input so far.
#19
Hi Goron, Great!
Will test for you of course. Hopefully development for D6, and to use in future for D7.
greetings, Martijn
#20
Hello,
As I see it, there are two distinct options for how to implement this:
The benefit of using option (1) is that it avoids duplicating data as well as reduces work - each location only needs to be saved in one place. The big drawback to (1) is that it would be a lot harder to implement, as far as I can tell. Locations are saved in the database in a very different way than taxonomies, and that would have to change. Changing Location this deeply would be challenging. Also, I'm not sure what it would take, if this was implemented, to integrate it with all the things Taxonomy is integrated with. Data in the Location tables would need to be 'recognized' as a Taxonomy, and I'm not sure how that would happen.
The main benefit of option (2) is that it's a lot easier to implement. Another benefit is that having a Location taxonomy would allow you to have items in there that you don't have in Location. For instance, you may want to list Cities, where some cities have content associated with them and others don't. The Location module currently requires locations to be associated with entities. But with a separate taxonomy this would be easy. The drawback to (2) is that it duplicates data and is less elegant and takes more work.
I haven't decided which of these options to implement, so I'd be happy to hear what you all think. I believe that the "right way" to do it is (1), but it may not even be possible without rewriting parts of Location, and certainly would take a lot more time. So I'm leaning towards option (2).
#21
Summit, I'm planning to develop for D7 actually. I know a D6 module may be more useful to the community, and Location for D7 is still in dev, but the site that I'm developing this for will be on D7.
I will definitely try to backport if possible after it's done.
#22
Hi, I am not a programmer, but more ICT-architect.
I am looking into D7 now, and see it is more based on fields than on nodes or terms. The basis is fields.
For Location D7.4 I also see the way to go is to build location on the fields (current Location D7.3 is not the way Location should be implemented in the D7 field way).
You are saying you will first build for D7, and then may be backport to D6, then the (2) Duplication option is the right one I think.
But when you are building on top of/or join development of Location D7.4 I do not think backporting without massive recoding for D6 is possible, then (1) Direct integration in Location D7.4 is the way to go I think.
Does this help you to decide? Looking forward to test for you in D7, and in D6 if possible.
Greetings, Martijn
#23
Hello Martijn and everyone,
I have a working first version of this module. It's for Drupal 7 and is compatible only with Location 7.x-3.x. I went with 3.x because it is the version that is the most stable and usable right now for D7. When 4.x comes out, I will create a new version of my module for it. I don't think it'll be too difficult.
The module is called Location Taxonomize. I know it's really similar to the "Location Taxonomy" module, but I couldn't think of a better name. Suggestions welcome.
The basic functionality works, and there are a few cool features, and more coming. Testing and any input on all aspects of the module would be highly appreciated. And if anyone here is qualified to review modules, you could help by reviewing it on the issue queue.
It's my first contrib module, so I have to wait for the review process before I have a full project page and can make releases, and this could take a while. If you want to start testing already, you can get the code using git. The module page is here: http://drupal.org/sandbox/goron/1234754
I will be continuing to develop in the next weeks, so look for new changes if you do get it using git.
#24
thanks goron
i think it will also solve my purpose
#25
Babbar - I'm glad to hear that.
Have you downloaded and tried the module? I'm still waiting for the approval process (which could take a few weeks), but as soon as it's done there will be an official release on the project page.
If you can test at all, that would be great.
#26
subscribing
#27
Will gladly help testing a D6 backport, in case it happens ;)
#28
Thanks @asb. A D6 backport is definitely planned, though it might take me a bit of time to get to it.
#29
Goron, I would love to see a D6 backport if this functionality. Great work on the module though.
#30
I've finally been approved and have released an initial version of this module. It's only for D7 with Location 7.x-3.x right now. A backport is planned but will take time.
http://drupal.org/project/location_taxonomize
#31
subscribe
#32
Goron. The module looks excellent. As I believe this a great module for a lot of people running existing sites on 6 the backport would be awesome. If I can assist with testing please let me know.