The API seems to be giving different values to the maps website.
Here is the front-end output for travelling between Manchester Airport and the London Eye.
Here's the API output
As you can see the numbers are close, but since they should both be calling the same thing, I'm confused as to the difference?
I need to use this to work out the time between close proximity places, so a couple of minutes matters here.
This is the api url I'm using:
https://dev.virtualearth.net/REST/v1/Routes/DistanceMatrix?origins=53.361881,-2.270841&destinations=51.49984,-0.124663&travelMode=driving&timeUnit=minute&distanceUnit=mi&key={insertkey}
Does anyone have any ideas what I'm doing wrong?
Related
This seems to be a common enough problem that there are a lot of entries when one googles for help but nothing has helped me yet.
I am finding that the results provided by the REST API for estimated_steps are wildly different from those that appear in the device app.
I am running a fetch task for users via cron job on a PHP/Laravel app.
I'm using this https://developers.google.com/fit/scenarios/read-daily-step-total - estimated_steps to retrieve the step count.
Some days the data is correct. Some days its wildly different. For instance, on one given day, the REST API gives step count of 5661 while the app shows 11,108. Then there are six seven days when the stream is correct.
Has anyone faced this sort of behavior? I've tested for timezone differences, logged and analyzed the response json to see if i'm making some obvious mistake, but nope.
You may check this How do I get the same step count as the Google Fit app? documentation. Be noted that even when using the right data source, your step count may still be different from that of the Google Fit app.
This could be due to one of the following reasons:
On Wear, the Fit MicroApp when connected will display step counts queried on the phone and transferred over via the Wearable APIs. Other MicroApps accessing local-only data will only get watch steps. We are working on making this easier for developers.
Sometimes the step calculation code for the Google Fit app is updated with bug fixes before we are able to release the fixes to developers (which requires a Google Play Services release). We are also working on making it possible for developers to access fixes at the same time.
The Fit app uses a specific data source for steps and it adds some functionality (which can be seen on the documentation) on top of the default merged steps stream.
You can access the "estimated" steps stream as shown here:
derived:com.google.step_count.delta:com.google.android.gms:estimated_steps
Hope this helps!
It seems that the sample code from Google that demonstrates the Google Places API for Android is returning results from outside of the given boundary. (https://github.com/googlesamples/android-play-places/).
Searching for 'hardware' shows most results from Sydney (the hardcoded boundary), but also (occasionally) shows results from as far away as other cities (including Western Australia!). I've implemented GooglePlacesAutocompleteAdapter in my own code and have found similar results. It seems that the Boundary field is only a guideline for the search; can anyone confirm this?
This may or may not be related, but does anyone know also whether the results returned from Places.GeoDataApi.getAutocompletePredictions are the same results that can be expected from a similar call to the Web Services Places API? With a few tests it seems the web services call returns better results (closer to location, more relevant, and overall more results). The API docs do not seem to shed any light on this -- my guess is perhaps the getAutocompletePredictions query is performed on the 'name' of the Place rather than in a 'keyword' search as per the web service API implementation.
Thanks for the help.
As per the developer docs, the bounds is...
for geographically biasing the autocomplete predictions.
This means exactly what you suggested. Results inside are preferred, but not required.
I have an iphone app (iOS 5) that uses a UISearchBar to search an MKMapView. We used JSON queries, and used the fantastic answers from this question as reference (our code is very similar). The process itself works fine now, but we tend to get no results back from Google when we query them, or just get a really far away and incorrect one. Most times we can even search for "McDonald's" or "Subway" at it won't return any results. In general, it rarely gives a good result back unless we're very specific and include city and state and everything.
Is there another better way to go about this? Has something been updated since that answer that we should now take in to account? The problem doesn't seem to be that the code isn't working, but rather that Google just doesn't handle queries well the way we do it. This seems to be a fairly common use for MKMapview so I figured there should be an easier and better-working solution.
Any help would be much appreciated.
Here is a very useful list of the parameters that the Google Maps API supports:
http://querystring.org/google-maps-query-string-parameters/
You have a couple of options:
1) Get the user's location from the app and pass it into the search query with the sll parameter, e.g.
this search doesn't include a location:
https://maps.google.com/?q=starbucks
but this one does (I've used San Francisco in this example):
https://maps.google.com/?q=starbucks&sll=37.776414,-122.437477
Then you'll get results for the user's actual location. You'll also need to do something sensible if the user does not permit the app to access their location (in that case you may want to disable search).
2) If your app is for a specific place, then you can just add that place on the end of your search string. e.g. my Domesday app is only for England, so I include ",England" on the end of all my search requests, and that works nicely for me.
I am new iphone developer,please help to me.how can i find particular shops list in particular Zip Code.. that means i need to place pins in Some shops by searching Zipcode
Thanks in advance
I'm not sure there's a definitive "Right Way" to do what you're asking, but if it were me...
I would probably use Google's Places API to get a list of so-called Places (I gather this includes a fairly comprehensive list of businesses, as well as other points of interest) near the user. The API requires lat/long coordinates to resolve the list, you could either get that data from the user's iOS device (I don't develop for this platform so I can't give specifics) using Apple's location API, or if you really want to do a lookup by zipcode you might want to look at Google's Geocoding API. Keep in mind that Google's services are by no means the only game in town, and there are certainly other ways to do what you ask. But if it was me, this seems like the simplest solution
We need to display meta information (e.g, address, name) on our site for various venues like bars, restaurants, and theaters.
Ideally, users would type in the name of a venue, along with zip code, and we present the closest matches.
Which APIs have people used for similar geolocation purposes? What are the pros and cons of each?
Our basic research yielded a few options (listed in title and below). We're curious to hear how others have deployed these APIs and which ones are ultimately in use.
Fwix API: http://developers.fwix.com/
Zumigo
Does Facebook plan on offering a Places API eventually that could accomplish this?
Thanks!
Facebook Places is based on Factual. You can use Factual's API which is pretty good (and still free, I think?)
http://www.factual.com/topic/local
You can also use unauthenticated Foursquare as a straight places database. The data is of uneven quality since it's crowdsourced, but I find it generally good. It's free to a certain API limit, but I think the paid tier is negotiated.
https://developer.foursquare.com/
I briefly looked at Google Places but didn't like it because of all the restrictions on how you have to display results (Google wants their ad revenue).
It's been a long time since this question was asked but a quick update on answers for other people.
This post, right now at least, will not go into great detail about each service but merely lists them:
http://wiki.developer.factual.com/w/page/12298852/start
http://developer.yp.com
http://www.yelp.com/developers/documentation
https://developer.foursquare.com/
http://code.google.com/apis/maps/documentation/places/
http://developers.facebook.com/docs/reference/api/
https://simplegeo.com/docs/api-endpoints/simplegeo-context
http://www.citygridmedia.com/developer/
http://fwix.com/developer_tools
http://localeze.com/
They each have their pros and cons (i.e. Google Places only allows 20 results per query, Foursquare and Facebook Places have semi-unreliable results) which can be explained a bit more in detail, although not entirely, in the following link. http://www.quora.com/What-are-the-pros-and-cons-of-each-Places-API
For my own project I ended up deciding to go with Factual's API since there are no restrictions on what you do with the data (one of the only ToS' that I've read in its entirety). Factual has a pretty reliable API, which as a user of the API you may update, modify, or flag rows of the data. Facebook Places bases their data on Factual's, just another fact to shed some perspective.
Hope I can be of help to any future searchers.
This is not a complete answer, because I havn't compared the given geolocation API, but there is also the Google Places API, which solves a similiar problem like the other APIs.
One thing about SimpleGeo: The Location API of SimpleGeo supports mainly US (and Canada?) based locations. The last time I checked, my home country Germany doesn't has many known locations.
Comparison between places data APIs is tough to keep up to date, with the fast past of the space, and with acquisitions like SimpleGeo and HyperPublic changing the landscape quickly.
So I'll just throw in CityGrids perspective as of February 2012. CityGrid provides 18M US places, allowing up to 10M requests per month for developers (publishers) at no charge.
You can search using a wide range of "what" and "where" (Cities, Neighborhoods, Zip Codes, Metro Areas, Addresses, Intersections) searches including latlong. We have rich data for each place including images, videos, reviews, offers, etc.
CityGrid also has a developer revenue sharing program where we'll pay you to display some places as well as large mobile and web advertising network.
You can also query Places via the CityGrid API using Factual, Foursquare and other places providers places and venue IDs. We aggregate data from several places data providers through our system.
Website: http://developer.citygridmedia.com/