I want to use the Google Weather API - by passing lat and long values. I am storing these values, however it seems Google needs these values in different format.
i.e. For the town of McTavish I have values of 45.5 and -73.583
This works here: http://api.wunderground.com/auto/wui/geo/WXCurrentObXML/index.xml?query=45.5,-73.583
But when I use these data for Google API, it does not work: See: www.google.com/ig/api?weather=,,,45.5,-73.583
Any help appreciated. I would prefer to use the Google Data.
UPDATED ANSWER:
I have just noticed some OTHER irregularities with Google's Weather API. In ANY case, you need to have 8 numerical digits, in addition to the negative sign, if it applies. See the following code block (Java-based) for proper formatting. (Not the perfect algorithm, but just a quick example so that you can see the results)
lat = lat.replace(".", "");
while(lat.length() < 9)
lat = lat.concat("0");
if(lat.contains("-"))
lat = lat.substring(0, 9);
else
lat = lat.substring(0, 8);
ORIGINAL RESPONSE:
Paul, the trick about Google's Weather API is that you don't use the coordinates as received by traditional latitude/longitude. Instead, you parse out the decimal points. Additionally, a "fun quirk" of Google's Weather API seems to be a requirement that the data come in as a 7- to 8-digit string. So, for instance, 45.5 should really be 45.50000, and -73.583 should really be -73.58300. This length of 7-8 digits does NOT seem to include the negative sign (-) in front of any negative coordinates.
So, your 45.5(0000) becomes 4550000, and your -73.583(00) becomes -7358300. So the final URL would be:
http://www.google.com/ig/api?weather=,,,4550000,-7358300
Note that again, 7-8 digits means 4550000 or 45500000 would be acceptable, as would -7358300 or -73583000.
I only found out about the 7-8 digit length when I saw your question--I tried entering the data into my weather parsing program, and found that 455,-73583 does not yield proper data.
Note that this is by my unofficial experimentation, and not by official documentation, so there may be other quirks to be discovered.
It's much simpler - latitude & longitude should be multiplied by one million
In my opinion longitude an latitude must be coded in _e6 format (six last digits must be the decimal part of the lon/lat string passed to the API). Then you must adjust first decimals to a length of six, you add 0s if you have fewer than six decimals, and you clip it to 6, if you have more. For the int part if you have just one character you must add a zero first, for two or three digits, you don't need to do anything.
Examples:
1.1234 must be coded as: -01123400
112.2345 must be coded as: 112234500
34.123456 must be coded as
Here you have a explanation with examples and a the php source code (the blog is written in Spanish).
As Miguel said it is the last 6 digits that should be the decimal places. So the correct code is as simple as....
string.Format("http://www.google.com/ig/api?weather=,,,{0:0},{1:0}",
(latitude * 1000000),
(longitude * 1000000));
Related
Long story short, I am trying to convert strings of hex values to signed 2's complement integers. I was able to do this in a single line of code in Swift, but for some reason I can't find anything analogous in Kotlin. String.ToInt or String.ToUInt just give the straight base 16 to base 10 conversion. That works for some positive values, but not for any negative numbers.
How do I know I want the signed 2's complement? I've used this online converter and according to its output, what I want is the decimal from signed 2's complement, not the straight base 16 to base 10 conversion that's easy to do by hand.
So, "FFD6" should go to -42 (correct, confirmed in Swift and C#), and "002A" should convert to 42.
I would appreciate any help or even any leads on where to look. Because yes I've searched, I've googled the problem a bunch and, no I haven't found a good answer.
I actually tried writing my own code to do the signed 2's complement but so far it's not giving me the right answers and I'm pretty at a loss. I'd really hope for a built in command that does it instead; I feel like if other languages have that capability Kotlin should too.
For 2's complement, you need to know how big the type is.
Your examples of "FFD6" and "002A" both have 4 hex digits (i.e. 2 bytes). That's the same size as a Kotlin Short. So a simple solution in this case is to parse the hex to an Int and then convert that to a Short. (You can't convert it directly to a Short, as that would give an out-of-range error for the negative numbers.)
"FFD6".toInt(16).toShort() // gives -42
"002A".toInt(16).toShort() // gives 42
(You can then convert back to an Int if needed.)
You could similarly handle 8-digit (4-byte) values as Ints, and 2-digit (1-byte) values as Bytes.
For other sizes, you'd need to do some bit operations. Based on this answer for Java, if you have e.g. a 3-digit hex number, you can do:
("FD6".toInt(16) xor 0x800) - 0x800 // gives -42
(Here 0x800 is the three-digit number with the top bit (i.e. sign bit) set. You'd use 0x80000 for a five-digit number, and so on. Also, for 9–16 digits, you'd need to start with a Long instead of an Int. And if you need >16 digits, it won't fit into a Long either, so you'd need an arbitrary-precision library that handled hex…)
Based on Apple's documentation here: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Strings/Articles/FormatStrings.html
It's pretty easy to understand the number to the right of the decimal point is the number of digis will be rounded up...
For example, %1.2f, 123456.123456 will turn out 123456.12 and %1.4f will turn out 123456.1234...
But it looks like the number to the left of decimal does nothing.
I tried changing the number to whatever I can think of, nothing happened.
What does it do?
The number before the decimal point in the format is called the format string's width. That is, if the resultant string would involves less characters than its width, it will be left-padded with blank spaces. You don't see any change because you either aren't using a high enough number (try something ridiculous like 100 or 200), or don't have a means of properly seeing your whitespace.
Can any one please help me how to get float value as it is from text box
for Ex: I have entered 40.7
rateField=[[rateField text] floatValue];
I am getting rateField value as 40.7000008 but I want 40.7 only.
please help me.
thanks in advance
Thanks Every body,
I tried all the possibilities but I am not able to get what I want. I am not looking to print the value to convert into string.I want to use that value for computation. If i use Number Formatter again when i am converting from number to float it is giving same problem.So i want float value only but it should be whatever i have given in the text box it should not be padded with any values.This is my requirement.Please help me.
thanks®ards Balu
Thanks Every body,
I tried all the possibilities but I am not able to get what I want. I am not looking to print the value to convert into string.I want to use that value for computation. If i use Number Formatter again when i am converting from number to float it is giving same problem.So i want float value only but it should be whatever i have given in the text box it should not be padded with any values.This is my requirement.Please help me.
thanks®ards
Balu
This is ok. There is not guaranteed that you will get 40.7 if you will use even double.
If you want to output 40.7 you can use %.1f or NSNumberFormatter
Try using a double instead. Usually solves that issue. Has to do with the storage precision.
double dbl = [rateField.text doubleValue];
When using floating point numbers, these things can happen because of the way the numbers are stored in binary format in the computers memory.
It's similar to the way 1/3 = 0.33333333333333... in decimal numbers.
The best way to deal with this is to use number formatters in the textbox that displays the value.
You are already resolved float value.
Floating point numbers have limited precision. Although it depends on
the system, float relative error due to rounding will be around 1.1e-8
Non elementary arithmetic operations may give larger errors, and, of
course, error progragation must be considered when several operations
are compounded.
Additionally, rational numbers that are exactly representable as
floating point numbers in base 10, like 0.1 or 0.7, do not have an
exact representation as floating point numbers in base 2, which is
used internally, no matter the size of the mantissa. Hence, they
cannot be converted into their internal binary counterparts without a
small loss of precision. This can lead to confusing results: for
example, floor((0.1+0.7)*10) will usually return 7 instead of the
expected 8, since the internal representation will be something like
7.9999999999999991118....
So if you're using those numbers for output, you should use some rounding mechanism, even for double values.
I am using Google Chart API in my Application and generating graph using URL "http://chart.apis.google.com"
I am getting error "The requested URL is too large to process", when I provide large set of parameters to this URL.
What I can do in this situation?
The Google Charts API FAQ offers this advice:
Is there a limit on the URL length for the Google Chart API? What is the maximum URL length?
The maximum length of a URL is not determined by the Google Chart API, but rather by web browser and web server considerations. The longest URL that Google accepts in a chart GET request is 2048 characters in length, after URL-encoding (e.g., | becomes %7C). For POST, this limit is 16K.
If URL length is a problem, here are a few suggestions for shortening your URL:
If you are using a text encoding data format, remove leading zeros from numbers, remove trailing zeros after decimal points, and round or truncate the numbers after decimal points.
If that does not shorten the URL enough, use simple (1 character) or extended (2 character) encoding.
Sample data less frequently; i.e., reduce granularity.
Remove accoutrements and decorations, such as colors, labels, and styles, from your chart.
also found this but there doesn't seem to be an answer/solution.
http://groups.google.com/group/google-chart-api/browse_thread/thread/b47c1588b39d98ce
In case it is a browser error - browsers have their maximum URL length limitations (IE 6/7 has 2,083 limit):
What is the maximum length of a URL in different browsers?
I'm getting HTTP 414 but my URL length is not an issue (it is 1881 characters), and I have tried both GET and POST. My guess is that Google will also return this error when the chart you are requesting is too "expensive" to generate.
A method that worked well for me was to divide all values by 10 or 20 and converting the results to int (no commas), but I kept the numbers on the axis. This way, it's a little less accurate but reduces the amount of characters used in the URL.
Code example:
$newSalesrank = $rank/20;
$rankdata .= intval($newSalesrank);
This solved my problem, I got no more "url too long" errors and it still looks good on my charts - because it still looked the same, the numbers just were simply scaled down.
For example:
code = '7777-5';
input = code.substring(0, 4); // Returns '7777'
checkdigit = f(input); // f() produces a checkdigit
assert.areEqual(code, input + "-" + checkdigit)
Is there a technical term for input used above?
Specifically I'm calculating checkdigits for ISBNs, but that shouldn't effect the answer.
Is "original number excluding the check digit" technical enough? :)
Actually, it's often the case, as in the link you posted, that the check digit or checksum ensures a property about the full input:
...[the check digit] must be such that the sum of all the ten digits, each multiplied by the integer weight, descending from 10 to 1, is a multiple of the number 11.
Thus, you'd check the full number and see if it meets this property.
It's "backwards" when you're initially generating the check digit. In that case, the function would be named generate_check_digit or similar, and I'd just name its parameter as "input".
Although I am not sure if there is a well-known specific technical term for the input, what LukeH suggested (message/data) seems common enough.
Wiki for checksum:
With this checksum, any transmission error that flips a single bit of the message, or an odd number of bits, will be detected as an incorrect checksum
Wiki for check digit:
A check digit is a form of redundancy check used for error detection, the decimal equivalent of a binary checksum. It consists of a single digit computed from the other digits in the message.