Investigation of Google Geocoding APIs

[fergalwalsh]

@pkieltyka Some findings from my reading & experiments with Googles APIs..

Google has multiple APIs related to places/geocoding.

Geocoding web service
Geocoding JS API

Places web service
Places JS API

and also android & iOS libraries for each..

The Places apis seem the most useful for what we need. Rather than geocoding to specific addresses it returns 'places' which are cities, localities, neighborhoods etc and also 'establishments' if requested. If the place is an area rather than a specific point then it includes a viewport which is basically a bounding box of the area.

We could directly wrap the Autocomplete API of the web service to build a service around this but actually the recommended approach is to use the platform specific apis on the client side if possible. The advantage of this is that all the user interaction of autocomplete is handled by the library (e.g. https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete). The client would then just return the place_id to the backend which would fetch the details and use the appropriate fields. The other advantage of this is the client side autocomplete can easily be made location biased by the device geolocation api which removes the need to deal with ip lookups or reverse geocoding in the backend.

What do you think of this approach?

[pkieltyka]

The places API looks cool, so does the geocoding API. I was looking at these the other day as well.

I do agree our service should offer something like the autocomplete field, however.. consider, how will that work in our native mobile app? so, perhaps we should just implement the service to provide an autocomplete endpoint that queries for a place name.. what do you think?

[fergalwalsh]

Sorry I should have made it clearer in the description, there are the same apis for iOS and Android too:

https://developers.google.com/places/ios-api/
https://developers.google.com/places/android-api/

I think using these prebuilt sdks makes more sense than rolling our own service and developing a UI. It's a simple and familiar interface too.

[pkieltyka]

okay, fair enough. That makes sense. We do use React Native for our apps, but we can wrap native components anyways. Once we get there we can tackle the autocomplete.

[pkieltyka]

btw, I started the beginnings of the spec -- I think this is enough to go off to build a basic prototype.

https://github.com/pressly/geoy/blob/master/README.md

I showed the basic data model at the bottom of the readme, perhaps you can start modeling something? We are open to using Postgres or ElasticSearch for querying (or both?). We use ElasticSearch for full-text search, but perhaps we should use Postgres to find near-by hubs, users, or even points.. and search can use the same data for other kinds of searches to match tags too etc.. I think the details will come out in the implementation.