My Professional Blog

I have added a few features and made a few bug fixes to GeoKit. These are as follows:

• [FEATURE] Added timeout support for geocoder web service calls
• [FEATURE] Added proxy support for geocoder web service calls
• [FEATURE] Added support for SQL count queries — they work like the finders
• [BUG FIX] Fixed range finders to support exclusive ranges
• [BUG FIX] Fixed configuration to use class accessors instead of constants (that were being reinitialized)
• [BUG FIX] Eliminated bogus IP address returned from IP geocoder when the request IP is 127.0.0.1
• [BUG FIX] Fixed GeoLoc’s hash method and added an alias to_hash
• [REFACTOR] Require statements to be cleaner all the way around

Thanks to the following who reported bugs that got fixed or who submitted patches that were used in part or in their entirety:

• Norbert Crombach
• Justin French
• Hoan Ton-That
• Jason Seifer

Thanks to everyone for your feedback, patches, and compliments. If I didn’t name you explicitly, it means that your thanks by name will come later.

Since I am in a GeoKit development mode right now, let me or Andre know if there are other features, bug fixes, or patches I should be aware of. I know that we had been planning to modify our configuration approach to be compatible with YM4R, but that’s been delayed indefinitely. They use a YAML file and we use the environment configs — and there really wasn’t a compelling reason to mess with it. Also, no UK geocoding yet — didn’t receive too much demand.

Please review the README for updates and take a look at the new environment config template under the plugin’s assets directory to see how you should config GeoKit. And by all means, let me know if there are issues that I’ve inadvertently created for you.

For those of you interested in UK Geocoding, I just saw this post come across the wire.  If you aren’t doing anything of high-volume or with high-availability needs, maybe this is a temporary answer for you.

I’ve received quite a few inquiries on this topic, so apparently there is quite a lot of interest in us doing some of this.  I’m happy to take a shot at this if I can solicit some help from my readership.  I basically need you folks to do some legwork for me.

It would be helpful if I could get the consensus view of the geocoding services that you folks are interested in.  It would also help to know if they have sandbox capabilities so that I don’t have to pay a tremendous amount to work through the development process.  And lastly, I might ask for some suggestions on the GeoLoc data elements front.  Obviously, its quite US-centric, at the moment.

I do reserve the right to use your suggestions selectively based upon time, expense, and convenience, but I think you already knew that.  So let me know your thoughts!

Its been a while since I tinkered with GeoKit, but when I read this post, I thought I’d take a look at a couple of things that were mentioned.

James wrote that it would be nice to be able to reset the default_units value to enable localization.  Well, actually you can.  :default_units is modifiable through a class accessor.  Also, you can pass an optional parameter in your finders called :units which enables you to override whatever default value you’ve set.

While we’re talking about defaults, I applied a patch submitted by Hoan Ton-That which enables you to specify your preferences for units and for the formula from within the environment files.  So these preferences would appear right along side your API keys for GeoKit.  Its a small feature, but you may appreciate it.  Thanks Hoan!

Otherwise, James mentioned that :include support is lacking with GeoKit.  That’s not entirely true.  I added a passing test case which successfully pulls columns from a belongs_to relationship.  I suspect that the has_many relationships are the problem.  But if your case is covered by the belongs_to relationship, then you are covered.

There is a less-used method called distance_sql which enables you to just get the distance calculation in SQL form.  You would use this if you ever found that GeoKit could not support your exact query requirements.  Its less elegant for sure, but saves you the trouble of having to code the distance calculation.

UK geocoding is still in the roadmap, but both Andre and I have a few other projects and side endeavors going on.

We have been asked whether GeoKit could be made to support UK addresses and this is something that we’re interested in doing.  I must admit that I was incompletely uninformed as to how different these addresses really are.  Just have a look at Wikipedia has to say about UK addresses.  In specific, we’ve been asked to support this geocoding service: www.postcodeanywhere.co.uk.

So since we’re looking into this, I thought it might be a good idea to solicit other suggestions for geocoding services and address variants which GeoKit doesn’t already support, but which would be useful to the Rails community.  It appears there will be some refactoring involved, so it makes sense to do a little due diligence by broadening the input process.

So drop me or Andre a note or comment and let us know.

The recent GeoKit publicity has caused an influx of new visitors to this blog. Now that the traffic is subsiding somewhat, I thought I’d take a look at the geography of Rails. It seems an appropriate tangential GeoKit topic.

So have a look at the map. 44% of the traffic came from the United States — looks like the East Coast and West Coast primarily. Next, came Germany at close to 9% — Berlin mostly. Canada came in at 7%. 17% of the traffic came from smaller countries.

I find this pretty fascinating and definitely flattering that such a wide range of people would pay a visit to this blog.

We just checked in code which improves the readability of GeoKit’s finders. Its quite obvious from the code, so just take a look at these examples:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Find the nearest store.
stores = Store.find(:nearest, :origin => an_origin)

# Find the farthest store away.
stores = Store.find(:farthest, :origin => an_origin)

# Find within a radius.
stores = Store.find(:all, :within => 5, :origin => an_origin)

# Find outside a radius.
stores = Store.find(:all, :beyond => 5, :origin => an_origin)

# Find within a range.
stores = Store.find(:all, :range => 5..10, :origin => an_origin)

Over at Earthcode, a request was made to enable the distance_between and distance_to methods to accept physical locations in pre-geocoded string form. I have added this improvement, so you can now do:

1
2
3
4
5
6
7

# Geocode from and to, then calculate the distance
# between them.
dist = Store.distance_between("Irving, TX", 
                              "San Francisco, CA")

# Geocode the to, then calculate the distance to it.
dist = irving.distance_to("San Francisco, CA")

Andre has also added further flexibility to the :origin to include setting it to an array of lat / lng values. Usage looks like:

1
2
3

# Presumably some previous geocoding and then this:
stores = Store.find(:all, :origin => [37.792,-122.393], 
                    :conditions => 'distance < 10') 

Keep the feedback coming!