Download & Extend

Hierarchical Select widget for Geonames

Project:GeoNames
Version:6.x-1.x-dev
Component:User interface
Category:feature request
Priority:normal
Assigned:bangpound
Status:reviewed & tested by the community

Issue Summary

This module implements the Hierarchical Select widget API to provide a widget for selecting a Geoname.

The widget is very demanding on the web service, so it's crucial that you've set up Geonames to cache result data for a good amount of time.

AttachmentSize
hs_geonames.info212 bytes
hs_geonames.module1.48 KB

Comments

#1

unbelivable !!!
I just need this :)
I'll test this out and give feedback here

#2

hmm.. oki. stupid question: how do I test it out ?
Do I have to write some code or it should be somewhere in the UI ?

#3

It's a HS widget, so you need to create a form that wants a Geonames ID.

#4

Thanks bangpound, that did the trick. It is my first time I'm trying out HS or Goenames modules.
The module itself works great. I also tested the '#default_value' option and works like a charm.

I only had a small issue: the 'max_allowed_packet' property from my.cnf that was set too low - but of course this is a server issue.

I have one question, maybe you can give me some advice: what would be the best way to store the selected data from the created form element ?
Right now I'm using a hook_form_alter to inject this hs element into the node edit form and in a validate function I assign the selected geonameid to a CCK text field. Is there another better solution ?

Thanks for your time.

#5

CCK may raise issues that I've not encountered yet. I'm using the element on a custom form which has a custom submit handler for capturing and storing the value. I'm not using it on nodes or with CCK.

Hierarchical Select doesn't have any modules that work with CCK, does it? I think any limitations about this module would be common to HS.

If you're working only with a single valued field, you might try replacing the element type in hook_form_alter, but you'd be experimenting in ways I've not!

#6

Status:needs review» reviewed & tested by the community

Thanks for the info. I think it is worth researching some more about HS with CCK but I'm sure I'll find a lot info in the issue queue.

About this little but very nice module (I'm still playing with it, no problem so far): will you make a separate project for it or maybe try to see if the maintainers of Geonames adopt it ? It would be a pity if it would remain just here as an attachment to this issue.

#7

Right now, I think it belongs with Geonames. I have a module in development that depends on HS, Geonames and Location_Taxonomy. The developer of HS said that my work on this widget belongs with Geonames.

#8

Just bumping this so maybe a Geo maintainer sees it.

#9

had to read this discussion here for several times till i got it that this modulish thing will only work in some kind of self-fabricated forms?

i hoped that this would had to do sth with taxonomies and stuff.
i was eagerly looking for some way to create a vocabulary with country names and their subdivisions and that perfectly sounded like a solution.

have been looking for any kind of prefabricated xml files of countries with their subdivisions and cities before, but that does not seem to exist. the only thing i found was that huuuge 170mb allcountries file from geonames.org, but i see no way to make use of that.

as HS is able to work with cck and with content taxonomy, i wonder if there is any kind of way to provide nodes with the geonames data and store the selected terms hierarchically in a vocabulary for georeferenciation of nodes via taxonomy

sorry for my stupid questions
bernd

#10

I was thinking about something like that and found this module http://drupal.org/project/nat

So you'd have to have content types: country, state, city, zip code (have them reference each other via http://drupal.org/project/hs_nodereference) and then establish relationship to taxonomy terms.

Now the question is how to import all those massive data files into CCK nodes.

#11

@bernadotte and @skolesnyk:
I would suggest storing location data as nodes. You can have node types like Continent, Country, City, etc and have relationships between them with nodereferences. We(the company for which I work) are currently doing this for a travel website and everything is working nice. And because locations are nodes you have a lot more flexibility than with taxonomy.
Importing is quite easy: just manually create a few locations and also the relationships between them (CCK nodereferences) and then use Devel module to see how they are structured. Then you can create a small script that parses the xml/text files and creates nodes with the correct references between the nodes.
Hope this helped a bit.

#12

Subscribing....

#13

Ok, I've been trying to figure out how to use this, but can't see how.

I have nodereference fields set up - first ones are regular select, last one is hierarchial. But how do I bring in the Geonames data? I don't see anywhere for doing it.

Thanks.

#14

@andreiashu

Could you post the code you are using to test #4??

Thanks :)

#15

@fp sorry I don't really remember that much. It was more than 1 year ago and my memory sucks.

#16

Soooo... this looks cool. Anyone planning to add this to the Geonames package, or should it be its own project?

#17

can it be ported to d7?

nobody click here