Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Google Maps? #34

Closed
stevenprimeaux opened this issue Jul 17, 2020 · 8 comments
Closed

Support for Google Maps? #34

stevenprimeaux opened this issue Jul 17, 2020 · 8 comments
Labels
help wanted Extra attention is needed

Comments

@stevenprimeaux
Copy link

Are there plans in the works to add support for Google Maps? The ggmap package could provide a model for those wrappers.

@jessecambon
Copy link
Owner

I'm open to adding the Google geocoder in the future, but I'm not currently working on it. If anyone is up for taking this on, here are some general instructions on how support for a geocoder service can be added to the package.

  1. Update the api_parameter_reference dataset to include the geocoder service. Each service is referred to by a short name in the method field (which is how the service is specified in the geo() and geocode() functions). The api_name field should reflect the specific parameter names of the geocoder service.
  2. Update the extract_results() function which is used for parsing single addresses (ie. not batch geocoding). You can see examples of how I've tested out parsing the results of geocoder services here.
  3. If the service supports batch geocoding, add a function for this capability to R/batch_geocoding.R. These functions are called from geo().
  4. If the service requires an API key, update the get_key() function which loads the API key from an environmental variable.
  5. Add a function for obtaining the API URL to R/query_factory.R.
  6. Make relevant updates to the geo() function. In particular look at the if clauses that reference the method (ie. usage limits are specifically applied to the "osm" and "iq" methods). Also, if batch geocoding is supported then the call to the new batch geocoding function will need to be added.
  7. Add a new geo_<method>() conveniance function to R/geo_methods.R.

Happy to provide additional guidance and give credit for code contributions in the DESCRIPTION file.

@chris31415926535
Copy link
Contributor

I might be able to help here: I've written a tidy interface to Google's geocoder service to help with some not-for-profit work (you can see the source code here, or install the dev package here ).

Of course I did it in my own idiosyncratic way, so over the next while I'll look and see how much work it would be to bring it into the tidygeocoder framework.

@chris31415926535
Copy link
Contributor

I've got a basic implementation working locally. I like your approach and I've learned a few things.

Question: are the parameters city, street, country, etc. always passed as individual elements of API queries, or is there a function (that I'm missing) that ever collapses them into a single string?

I ask because (from my read of the docs) Google accepts four main parameters: a mandatory single address and api_key, with optional language and region. But then my new entry in api_reference.R is only four lines long, which looks empty compared to the others :)

@jessecambon
Copy link
Owner

@chris31415926535 Thanks for submitting the PR. I haven't had a chance to review it in detail yet, but it looks good from skimming through it.

Also, it looks like you figured out the answer to your question already, but the address field is the one to use for the combined address while the other arguments like street and city are for breaking the address out into components. This reminds me that I should revisit the idea of throwing the user an error if they use an argument that is not compatible with the service that they have chosen (ie. using the street argument with the Google geocoder).

@jessecambon
Copy link
Owner

@chris31415926535 I've pulled in your PR to the google-geocoder branch. Good work on this - it worked well for me in the testing I did. One addition I made was to extract error messages from the google geocoder so that they can be displayed to the user (#54).

I also added your name to the DESCRIPTION file as a package author. Feel free to add an email address if you would like (or email/message it to me and I can add it). I'll plan on looking at addressing #53, doing some more testing, and pushing this up to the master branch so it will be included in the next CRAN release.

@chris31415926535
Copy link
Contributor

@jessecambon Thanks for the kind words, and I'm glad I could help! If you don't mind, I'm still getting the hang of git so it's probably easier for you to add my email address: christopher.a.belanger@gmail.com

@jessecambon
Copy link
Owner

@chris31415926535 You're welcome, I added your email to the DESCRIPTION file. Also, your code is now in the master branch along with a few other enhancements and bug fixes I'm looking to roll out for the next CRAN release. Feel free to test it out:

devtools::install_github("jessecambon/tidygeocoder")

@chris31415926535
Copy link
Contributor

@jessecambon I installed the GitHub version to test it out and it works like a charm. And good call on parsing the Google-specific errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants