search

goware / geotools

Geo-location lookup library / service built on Google Maps API
MIT License
2 stars 1 forks source link

Investigation of Google Geocoding APIs #2

Open fergalwalsh opened 8 years ago

fergalwalsh commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.