I am using a HERE maps HTTP request in the following format:
https://router.hereapi.com/v8/routes?origin=42.55009,-83.11662&destination=42.55277,-83.11675&transportMode=car&return=polyline&apikey=[api-key]
This returns a polyline encoding "BG00hlxCrkhx-E0oBzB82C3DgoBpC". I am able to decode the coordinates using the Python API. However, the default precision is only 5 decimal places (~meters resolution) in the decoded list.
Documentation of flexible-polyline mentions possible higher precisions (~microns) defined by the header-content. I would like atleast 6-7 decimal places of resolution for the returned polyline. How can I configure this through the HTTP request?
In the past the HERE platform data extension had 5 digit after decimal point for coordinates.
Therefore by default is 5 digits. It will be increased to 7 digits.
I created for you issue report on github
Related
I have mp3 files, and I have the time in seconds.milliseconds of the part I want
how can I get that using Range header in HTTP call ?
this is the file
https://mirrors.quranicaudio.com/muqri/alghamidi/mp3/001.mp3
and the time I want is from the second: 3.500 until 6.526
You can't with the only interoperable range unit, which is "bytes".
That said, if the MP3 has a fixed encoding rate you might be able to compute an approximation of the byte offset.
I read many questions about the limit of the URL in HTTP still not able to find the answer to how many parameters are maximum supported in HTTP
What is the maximum number of parameters supported in HTTP by parameters i mean:
https://www.google.com/search?q=cookies&ie=utf-8&oe=utf-8
Here there are 3 parameters:
q ie oe and their corresponding values.
The query string is under authority of RFC 3986, section 3.4 which does not specify any limit with the exception of the allowed characters. You will also struggle to find any limitation on the logical number of parameters, since there has never been a real specification on the format; what you find in there is rather a best-practice that has been highly influenced by what CGI is doing. So the number of parameters is very much bound by what the client or server is willing to transfer/accept (the lower bound wins, obviously). Per this answer, you can find a rough estimate here.
There is no limit for parameters number, its all about data size how many KBs you are sending using your GET request, however this value is configurable from web server side (Apache, Tomact, ..etc).
The default limit for the length of the request line is 8190 bytes in apache and this value could be changed to increase it or decrease it.
The Firebase Java API specifies that Long is a valid type to pass to setValue(). JavaScript only supports a single number type, the equivalent of Java's "double". So if I insert a number from JavaScript and retrieve it later from Java, am I going to get a Long or a Double? Is it a bad idea to use Longs in any cross-platform Firebase code, seeing as how a JavaScript client has no way of creating this type?
Numbers are slotted into either Longs or Doubles on the server. If the number maps exactly to a Long (i.e. is within the range of Longs, and does not have a decimal point), it will be stored as a Long. Otherwise, it will be stored as a Double.
Javascript does have less precision than Java when it comes to Longs, but if you remain within Javascript's limits, you shouldn't have a problem using Longs cross-platform.
I'm having difficulty with the Google maps V3 JavaScript elevation service.
According a google groups posting ( https://groups.google.com/forum/#!msg/google-maps-js-api-v3/Z6uh9HwZD_k/G1ur1SJN7fkJ ), it appears that if you use getElevationAlongPath() it compresses and sends the entire path to the Google server as an Ajax GET request and subsamples it on their server. This means that if you have a large number of path segments the encoded URL exceeds the maximum URL length and the request fails with UNKNOWN_ERROR.
Can anyone confirm that this is a URL length issue?
I've tried doing my own subsampling along the path and sending just the points I want elevation data for as a getElevationForLocations() request. This does seem to be an improvement, but I'm still getting some UNKNOWN_ERROR responses. These occur unpredictably. Sometimes a request with 400 points returns successfully. Other requests will fail with only 300 points passed. I'm guessing that this still a problem with URL length (presuming getElevationForLocations() also sends URL-encoded data to Google).
The documentation says that "you may pass any number of multiple coordinates within an array, as long as you don't exceed the service quotas." This doesn't seem to be the case.
Does anyone have any suggestions for a reliable way to get a large number of elevation data points (500?) from a long path?
Thanks,
Colin
After a bit more digging, this seems to be the situation.
The JavaScript API for elevation uses the HTTP elevation service behind the scenes. The HTTP elevation service docs do say that requests are limited to 2048 characters. However, if you're using the HTTP service directly, you build you're own URLs. This means you can check the length before sending. If you use the JavaScript API, the URL is built for you, but the API code doesn't check the URL length before sending.
The call end-point URL and the necessary parameters take up 78 characters leaving 1970 for the encoded points.
This is where it gets messy. The number of characters in an encoded point varies with the size and precision of the lat and lng values. Generally, somewhere between 8 and 12 characters per point. An added complication is that some of the characters used in the path encoding may need URL-encoding - further increasing the number of characters needed per point by an unknown, but potentially significant amount (2 extra characters for each path character in need of URL encoding).
All of these complications mean that its theoretically possible for a call to result too long a URL with just 55 points - very, very unlikely though. A safe limit is probably 150 points (but this may still fail occasionally). 200 should work most of the time. 250 should be about the maximum.
In reality, from a small number of tests:
- 200 worked every time
- 300 usually works
- 400 sometimes works
The discrepancy between the calculation and the tests suggests that the JavaScript API may be doing some further form of compression or I've got something wrong in calcs?
Your suspicions are correct, this is a URL length issue. If you have Chrome's Developer Tools open when you submit the request you'll see an HTTP 414 (Request-URI Too Large) error. The URL is around 3000 characters which is about 1000 too many (2048 is a common max url length).
Internally the Google Maps API converts all those points to what looks like an encoded polyline which helps compress that data down, but it's clearly not enough for this really long path. It might be worth splitting the request up into multiple segments when you know your going to be including more than N points (I'd experiment around with N to see what works).
Has anyone used Google translation API ? What is the max length limit for using it?
The limit was 500... now it is 5000 chars.
source
500 characters
source
At the moment, the throttle limit is 100,000 characters per day. Looks like you can apply to have that limit increased/removed.
I've used it to translate Japanese to English.
I don't believe the 500 char limit is true if you use http://code.google.com/p/jquery-translate/, but one thing that is true is you're restricted as to the number of requests you can make within a certain period of time. They also try to detect whether or not you're sending a lot of requests with a similar period, almost like a mini "denial of service" attack.
So when I did this I wrote a client with a random length sleep between requests. I also ran it on a grid so all the requests didn't come from a single IP address.
I had to translate ~2000 Java messages from a resource bundle from Japanese to English. It worked out pretty nicely, as long as the text was single words. Longer phrases with context came out awkwardly.
Please have look at this link it will give the correct answer at the bottom of the page.
https://developers.google.com/translate/v2/faq
What is the maximum number of characters per request?
The maximum size of each text to be translated is 5000 characters, not including any HTML tags.
You can send source strings of up to 5,000 characters, but there are a
few provisos that are sometimes lost.
You can only send the 5,000 characters via the POST method.
If you use GET method, you are limited to 2,000-character length limit on urls. If a url is longer than that, Google's servers will just reject it.
Note: 2,000-character limit including the path and the rest
of the query string as well + you must count uri encoding (for instance every space becomes a %20, every quotation
mark a %22)
The Cloud Translation API is optimized for translating of smaller requests. The recommended maximum length for each request is 5K characters (code points). However, the more characters that you include, the higher the response latency. For Cloud Translation - Advanced, the maximum number of code points for a single request is 30K. Cloud Translation - Basic has a maximum request size of 100K bytes.
https://cloud.google.com/translate/quotas