I started using your module. I am getting some backwards results when using Bing as the provider. I’ve tried this w/ several diff addresses & (consistently) get backwards results.

For instance, using Google to look up Google’s HQ at “1600 Amphitheatre Parkway Mountain View, CA 94043″ will give me:

Longitude: -122.085099
Latitude: 37.422782

However, using Bing will reverse the numbers:

Longitude: 37.423176
Latitude: -122.085962

Seems like it should be an easy fix but what would I change in the module?

If you want to check it out, the current version is here: http://cpan.perl.org/authors/id/D/DA/DANHGN/Geo-Coder-Many-0.12.tar.gz (there are couple of slight problems with the tests/documentation in the previous ones)

We’ve looked a bit as well and wished for the same things you do. Right now, I think we’re using some Roby geocoding backend as part of our infrastructure, but it’s not the fastest and of marginal quality. Ideally we’d like multiple providers, good normalization, sorting based on confidence and/or accuracy, etc.

It doesn’t HAVE to be Perl (though it’d be nice) as long as it could be run as a REST server that returns JSON or something sane.

For example one bit of data that many of them provide but not in a consistent format is “how accurate do we think this was?” which you can use as a primary factor in “should we look further?”. In my experience the “accuracy level” returned is pretty, uh, accurate.

I searched the internet about geocoding with perl there are plenty modules on cpan i don’t know its quality ,also there are zero articles about geocoding with perl , i think it could be intersting if someone publish an article about this subject .

Some geocoders, notably Google, can provide multiple answers (“did you mean”). In our application we’re processing a data feed and there’s no possibility of human interaction. However, the fact that multiple answers have been given implies a lower confidence in the result and thus other geocoders should be tried to gain more confidence.

One common reason for ambiguity is insufficient context, i.e., leaving out the state or city. In our application we know the likely state/city so having some address parsing and processing logic to detect those missing details and provide defaults would help. Some geocoders can return a parsed version of the address which could be useful.