Hi folks, I started coding an API for Mapstraction for geocoding place names (as opposed to addresses). For Google Maps I''ll call the Places API https://developers.google.com/places/documentation/ and for Bing I''ll call the Location API http://msdn.microsoft.com/en-us/library/ff701711.aspx (in a different manner than how the current geocoder does, which assumes an address was passed in). I''d like to get your opinion on whether this API should be implemented: a) Inside the existing Geocoder.geocode() API by allowing the query parameter to communicate not just lat/long or address data, but also a place name or non-structured query b) Alongside the Geocoder.geocode() in that same modele, perhaps a new Geocoder.geocodePlace() API? c) In a new module alongside Geocoder, called perhaps Places. The first option is more suitable if we believe that we can''t support this API across all providers. In that case Geocoder.geocode() would have the meaning "try to the best of this provider''s ability to get a lat/long from whatever was passed in". Thoughts? Thanks, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20121124/5a691656/attachment.htm>
Hi Stefan, It''s great to see that you''re working on this. I''ve been talking to the other Mapstraction committers off-list on this topic so it''s fantastic that you''ve gone one step further and actually started work on this. There is a subtle overlap between geocoding APIs and places APIs. It''s true that some (but not all) geocoders will be capable of taking a place name as input in addition to the usual forward and reverse geocoding operations. But places APIs also return a lot more information than a typical geocoder would, including category/place type, richer content such as ratings, reviews and photos and a whole lot more. They also take a unique place identifier and expand that identifier to the representation of the place. For this reason, I think that places support in Mapstraction needs to be a separate module rather than an addition to the geocoder module. So taking your starting point with the Google and Bing Places APIs, you''d need the following 1. mxn.(provider).places.js 2. mxn.googlev3.places.js 3. mxn.microsoft7.places.js Plus an addition to mxn.js to allow the Places API code to be loaded in the same way as geocoding support currently is. The challenge here will be to ensure that there''s a sufficiently robust Mapstraction place class that can hold and represent the differing data structures returned by the places APIs. I''d suggest you also look at the APIs from Nokia as they also have a Places API. If your code can support 3 differing Places APIs then that will be a good start in representing all the different ways in which these APIs represent a place. Keep in touch and let us know how you get on. If there''s any questions or problems you run across feel free to get in touch either on this mailing list or off-list. All the best -Gary -- gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | www.garygale.com On 24 Nov 2012, at 03:55, Stefan Negritoiu wrote:> Hi folks, > > I started coding an API for Mapstraction for geocoding place names (as opposed to addresses). For Google Maps I?ll call the Places API https://developers.google.com/places/documentation/ and for Bing I?ll call the Location APIhttp://msdn.microsoft.com/en-us/library/ff701711.aspx (in a different manner than how the current geocoder does, which assumes an address was passed in). > > I?d like to get your opinion on whether this API should be implemented: > a) Inside the existing Geocoder.geocode() API by allowing the query parameter to communicate not just lat/long or address data, but also a place name or non-structured query > b) Alongside the Geocoder.geocode() in that same modele, perhaps a new Geocoder.geocodePlace() API? > c) In a new module alongside Geocoder, called perhaps Places. > > The first option is more suitable if we believe that we can?t support this API across all providers. In that case Geocoder.geocode() would have the meaning ?try to the best of this provider?s ability to get a lat/long from whatever was passed in?. Thoughts? Thanks, > > Stefan > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20121124/54357d0d/attachment.htm>
Hi Stefan, Sounds great. My preferance would strongly for a) Kind regards, Neil Briscombe, Expedient Technology Solutions Ltd., UK On Nov 24, 2012 3:56 AM, "Stefan Negritoiu" <stefann at stefann.com> wrote:> Hi folks,**** > > ** ** > > I started coding an API for Mapstraction for geocoding place names (as > opposed to addresses). For Google Maps I?ll call the Places API > https://developers.google.com/places/documentation/ and for Bing I?ll > call the Location API > http://msdn.microsoft.com/en-us/library/ff701711.aspx (in a different > manner than how the current geocoder does, which assumes an address was > passed in).**** > > ** ** > > I?d like to get your opinion on whether this API should be implemented:*** > * > > **a) **Inside the existing Geocoder.geocode() API by allowing the > query parameter to communicate not just lat/long or address data, but also > a place name or non-structured query**** > > **b) **Alongside the Geocoder.geocode() in that same modele, perhaps > a new Geocoder.geocodePlace() API?**** > > **c) **In a new module alongside Geocoder, called perhaps Places.*** > * > > ** ** > > The first option is more suitable if we believe that we can?t support this > API across all providers. In that case Geocoder.geocode() would have the > meaning ?try to the best of this provider?s ability to get a lat/long from > whatever was passed in?. Thoughts? Thanks,**** > > ** ** > > Stefan**** > > ** ** > > ** ** > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20121124/734f1177/attachment-0001.htm>
Hi Neil, I think we need to be clear about the distinction between what a geocoding API does and what a places API does. A geocoder takes a street address or a point of interest and returns address components, coordinates and geometry (this is a generalisation). It also takes a coordinate and returns the address components and geometry. These are commonly known as (forward) geocoding and reverse geocoding. A places API returns information about places, points of interest, businesses, locations and so on and returns coordinates, address components, ratings, reviews and other content related to the place. A places API also enables local search as well as a reverse place lookup based on an identifier. Whilst some but not all geocoders recognise prominent points of interest, such as the Tower Of London or the Empire State Building, they will probably not recognise the coffee shop at the end of the road where I live. Place APIs will (or should) recognise all of these. If Stefan is talking about merely enabling prominent POI lookup in the existing Mapstraction geocoder support then this either is, or should be, already supported. But there''s a distinct difference between, say, the Google Geocoder API and the Google Places API, both in the semantics of what you would query from these APIs and in what you would get returned. To put it another way, a geocoder may recognise some prominent POIs but it is not a Places API. Conversely a Places API is not a geocoder. Adding Places support to the existing Mapstraction geocoder support is not something I''d support or would want to see implemented in Mapstraction. Adding Places support to Mapstraction as a new feature which sets along side our geocoder support is something I''d strongly support. Apologies if this sounds like a lecture but in my experience when we start talking about geocoders and places APIs we need to be very clear about what each sort of API is and is not. -Gary -- gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | www.garygale.com On 24 Nov 2012, at 10:06, neil briscombe wrote:> Hi Stefan, > > Sounds great. My preferance would strongly for a) > > Kind regards, > > Neil Briscombe, > Expedient Technology Solutions Ltd., UK > On Nov 24, 2012 3:56 AM, "Stefan Negritoiu" <stefann at stefann.com> wrote: > Hi folks, > > > > I started coding an API for Mapstraction for geocoding place names (as opposed to addresses). For Google Maps I?ll call the Places API https://developers.google.com/places/documentation/ and for Bing I?ll call the Location API http://msdn.microsoft.com/en-us/library/ff701711.aspx (in a different manner than how the current geocoder does, which assumes an address was passed in). > > > > I?d like to get your opinion on whether this API should be implemented: > > a) Inside the existing Geocoder.geocode() API by allowing the query parameter to communicate not just lat/long or address data, but also a place name or non-structured query > > b) Alongside the Geocoder.geocode() in that same modele, perhaps a new Geocoder.geocodePlace() API? > > c) In a new module alongside Geocoder, called perhaps Places. > > > > The first option is more suitable if we believe that we can?t support this API across all providers. In that case Geocoder.geocode() would have the meaning ?try to the best of this provider?s ability to get a lat/long from whatever was passed in?. Thoughts? Thanks, > > > > Stefan > > > > > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20121124/bee75e25/attachment.htm>