When using the Google Places API, what is the difference between "using the JavaScript library" and "calling the API directly"? - google-maps

I have seen the two forms of reference to the Google Places Library/Service, using JavaScript vs calling the API directly, a number of times, but I don't understand the difference. The Google Docs don't describe anything about two methods of accessing the API.
For example, this question talks about 2 ways of accessing the API: OVER_QUERY_LIMIT in a loop
And it appears that there is some type of direct web access taking place in this question: Querying Google Places API using jQuery
Is this something where there was an old way that involved formatting URL parameters and the new way is by utilizing the JavaScript library calls?
FINAL SUMMARY EDIT: There are two distinct ways of requesting data from Google, as described in #Dan Nissenbaum's answer below. And since my original question, the QUERY_LIMIT question referenced above has been edited to also include more information about the two options.

Perhaps you are referring to the distinction between the Google Places API that is intended for use on the SERVER (i.e., utilizing PHP to call the Google Places API directly), and using the completely different approach of the Google Places Javascript Library in which the BROWSER executes Javascript using the Javascript library provided by Google (that internally wraps calls to the Google Places API, so that you, as a Javascript programmer, only need to understand the Javascript library provided by Google, and use that)?
Here are the two scenarios.
Scenario #1: Use the API directly. For this method, you must refer to Google's API documentation for the Google Places API: https://developers.google.com/maps/documentation/places/.
Using this API works as follows (giving a simple example only). Say you want to retrieve places within 1000 meters of latitude=-27.2531166, longitude=138.8655664. You need to hit a URL as described by the API documentation: https://developers.google.com/maps/documentation/places/#PlaceSearchRequests.
In this example, the URL looks like this (it's long):
https://maps.googleapis.com/maps/api/place/search/json?location=-27.2531166,138.8655664&radius=1000&sensor=false&key=AddYourOwnKeyHere
You need a key for your personal use, which I assume you have. There are other options you can specify, such as limiting the results to restaurants, etc.
When you hit this URL, the data will be returned in either JSON, or XML format, as specified by the text json in the URL above (use the text xml for xml). This data is returned exactly like data is returned from any URL call when you hit a URL in your browser.
You can test this by simply typing the URL directly in your browser, and see the results.
To use the API directly from code, you will need to use code that hits the external URL above within code and retrieves the results within code (for example, using the PHP CURL library, or using AJAX in Javascript).
Scenario #2: You use the Javascript library that Google provides that wraps the API, so you don't need to deal with it. I'll update the answer with more details about this, if you don't know what this is.

The docs do discuss the two different approaches. The Places Library utilizes the Google Places services from within the JavaScript Google Maps API. If you are using the Google Maps API in a browser, this is probably the approach for you:
https://developers.google.com/maps/documentation/javascript/places
There is also a web service, which allows you to query directly from your application. You query it using direct http calls to Google services. If you need access to the data on your server or a mobile device, this is the approach you want to take:
https://developers.google.com/maps/documentation/places

Related

Why are some Google Sheets API v4 functions not documented?

I'm trying to understand how the Google Sheet API v4 works, so I check the sample codes provided by Google for the API methods. When looking at the examples for Google Apps Script (e.g. batchUpdate), I find this method, Sheets.newUpdateSpreadsheetPropertiesRequest(), and many more - all beginning with the prefix new. I've searched, but I can't find these methods described anywhere in the documentation.
This is for me not as clear as the behavior of the Spreadsheet Service (SpreadsheetApp).
Have I missed something, or is the REST API not well-documented?
The Advanced Service APIs are wrappers for their corresponding REST APIs. Methods prefixed with new are constructors for the corresponding resource object in the respective API (used mainly for auto-completion).
For example Sheets.newUpdateSpreadsheetPropertiesRequest() is equivalent to the UpdateSpreadsheetPropertiesRequest object. It takes a bit of getting used to, but spend some time navigating the documentation. It will begin to make sense eventually.

Is it possible to avoid tolls in Google Maps URLs latest version?

In the old Maps URLs API, you could add "&dirflg=dt" in the URL.
Here's an example URL using the new API taken from Google's official pages here:
https://www.google.com/maps/dir/?api=1&origin=Google+Pyrmont+NSW&destination=QVB&destination_place_id=ChIJISz8NjyuEmsRFTQ9Iw7Ear8&travelmode=driving
In the Google official pages, I was unable to find anything related to sending it flags to avoid tolls so I'm not even sure if it is possible with the new API.
Does someone have any info to enlighten me with? Thanks for reading.
:)
This is not possible with the Maps URL in this version, but you can do this manually after loading the directions.
You can try this:
Load the URL. (eg.:
https://www.google.com/maps/dir/?api=1&origin=Google+Pyrmont+NSW&destination=QVB&destination_place_id=ChIJISz8NjyuEmsRFTQ9Iw7Ear8&travelmode=driving)
On the left part of the screen, click OPTIONS.
Under Avoid, check Tolls.
However, if you want this functionality to be in the parameters, you can send your ideas by going in the Maps URLs Documentation and click SEND FEEDBACK. Or you can submit this as a Feature Request in Google Issue Tracker
Hope this helps!
This is possible, but you have to use "undocumented" features.
Warning: Since these are not documented features, they probably aren't official and likely subject to change without notice. Use in production at your own risk.
tldr:
https://www.google.com/maps/dir/{origin}/{destination}/data=!4m3!4m2!2m1!2b1
Plug in origin and destination and it should load directions, avoiding toll roads.
Explanation:
Here, we are using Google's own data/options string (see: "data=") to get the desired functionality. It is meant to be used by the Google Map's web app itself to communicate options selected on the page. This article (and the ones following it) explain how to create your own "data=" strings to customize how the map is configured. It's quite comprehensive, but like I said above, its not an official feature.

google places JS API localized place type

I am currently working on a project using the google maps JS API. i would like to display the place type in a similar fashion to how a google search would result (example below).
Using the getDetails method in PlacesService (as show here), i can receive an array of types for a place, yet they are not descriptive as what a google search shows, and are not localized. is it possible to achieve using the API?
Currently, the API doesn't provide this information.
There are a couple of feature requests in the Google issue tracker that might match your requirement:
https://issuetracker.google.com/issues/35822953
https://issuetracker.google.com/issues/35827225
You can star these feature requests to add your vote and subscribe to further notifications.

How can I use Google Maps with Processing?

I want to use Google Maps API with Processing. Until now I was just able to get Google Places data, but I'm struggling with the map itself. I know about other map options, like unfold or modestMaps, but I need Google. In particular because of the directions API in further progress. I've searched this forum and the web, without any help. I thought it should be quite
easy.
How can I use Google Maps with Processing?
I'm not sure about getting a full featured, dynamic Google Maps within your Processing app, but you might be able to modify the Processing library for the Google Weather API to instead use the Directions or Static Maps APIs. http://www.onformative.com/lab/google-weather-library-for-processing/
If you download the source and check out GoogleWeather.java you can see the constructor is calling the WeatherAPI and getting back the XML result. I think you could do the same thing except use the Directions API in it's place.
Here's a post on a Java blog about showing Static Maps API results in Java, which might be translatable into Processing: http://weblogs.java.net/blog/cajo/archive/2010/10/16/adding-google-maps-your-java-application
For something more dynamic, you might be able to adapt JXMapViewer, check out this article: http://today.java.net/pub/a/today/2007/10/30/building-maps-into-swing-app-with-jxmapviewer.html

Is it possible to get Google Maps Directions using HTTP requests?

Is it possible to use the Google Maps API router just using HTTP? Something like http://maps.google.com?from=blah?to=blah
And have it return some sort of XML or JSON representing the directions?
If you want Google to allow legal access to driving directions via HTTP you might consider voting for the enhancement request: Issue 235. Theoretically, the more people that vote for an enhancement request, the more attention Google give to it.
However, I strongly suspect that there might be contractual issues with the organisations that supply the data. Organisations like TeleAtlas impose restrictions about how Google can use their data. TeleAtlas probably don't want Google to make it legal for people to use their data to create apps for free that directly compete with their own commercial apps and devices.
There is no documented and approved method to access driving directions via an HTTP API request.
This makes it difficult to get driving directions on the server-side, which I assume is your intention.
Not only it is undocumented and difficult to achieve, but it would also violate the restrictions 10.1 and 10.5 of the Google Maps API Terms and Conditions.
However, if you don't mind the challenge, and you believe that rules are there to be broken, you may want to check these articles:
Calculate driving directions using PHP?
Retrieve driving directions from google maps with server-side HTTP calls and show results with static maps for WAP
Actually yes, and they do it themselves
The REST format is like:
http://maps.google.com/maps/nav?output=js&q=from:%20Montreal%20to:%20Toronto&key=apikey
Where q should have the form: "from: x to: y" (url encoded).
Some of the parameters are similar to the HTTP Geocoding service: http://code.google.com/apis/maps/documentation/geocoding/index.html
Mike
As of May, 2010, directions are available via web services:
http://code.google.com/apis/maps/documentation/directions/
Directions are returned in XML or JSON format:
http://maps.google.com/maps/api/directions/json?origin=Boston,MA&destination=Concord,MA&waypoints=Charlestown,MA|Lexington,MA&sensor=false
http://maps.google.com/maps/api/directions/xml?origin=Boston,MA&destination=Concord,MA&waypoints=Charlestown,MA|Lexington,MA&sensor=false
It's pretty danged easy to use.
Here you can find a list of parameters you can pass to the maps.google.com URL. Maybe you'll be able to get the information you need. I don't know what the returned output contains. At least you are able to define different output types.
I have already used this library with python and it works well, although it's against Google Maps API Terms.
API v3 (made the official version in the last six months), does:
http://code.google.com/apis/maps/documentation/directions/
Also note that most of the competing services (Bing Maps, Yahoo, MapQuest, CloudMade, etc) also support RESTful web services along these lines.
As always with these services, check the Terms & Conditions.
I've never used the API but it is pretty easy to get the structured directions data from a google maps page using JS to access the gmap page's DOM.