I am building an android app with kotlin in which a user set a location and after user visit the set location some function will be triggered. I have built the app to get longitude and latitude of the user location and set location, but how to equal these two locations so the function will be triggered.
For example:- A user set a location whose Longitude & Latitude are 28.690040, 77.208654. After user reach this location the Longitude & Latitude are 28.690041, 77.208653. So by reaching the exact location, user's location is not equal to the set location and hence the function will not be triggered.
Your equality differs at the sixth decimal place, So what you can you do is to round up the lat and long to is to round up to 5 decimal place or even 4 decimal places.
According to an answer in the Stackexchange,
fourth decimal place is worth up to 11 m
fifth decimal place is worth up to 1.1 m
sixth decimal place is worth up to 0.11 m
So you should prefer fifth place or fourth place, depending on your requirement.
Related
In Google Sheets, I set the data validation of a cell to a number that must be greater than or equal to 100. When I enter 9999999999999999999999, I get an error that the entered value must be greater than or equal to 100. Why does this happen? I also tried to change the formats to no avail.
Screenshot 1 | Screenshot 2 | Screenshot 3
Google Sheets (and spreadsheets in general) store numbers with 15 digits of precision. The reason why has to do with how numbers are stored in computer hardware. See https://en.wikipedia.org/wiki/IEEE_754 for an explanation.
When you enter a number like 9999999999999999999999, Google Sheets treats it like a string. If sheets tried to treat it like a number, it would actually be rounded to 1E22 (the last 8 digits are rounded off).
I need to get drive times for a place to the nearest airports. There is a service which is already in place which gives me the address of the place as well as the address of nearest airports in the north america region. One airport has a 5 digit zipcode, one has the zipcode this format 83402 4906, other has a zipcode in this format(canada) A12 123
The distance matrix api is not accepting all other zipcode formats apart from the 5 digit one. If I remove the space its not working.
I need to get the drive times irrespective of the zipcode format
My app may be used anywhere in the USA, but will be used by local businesses serving their own areas.
As my project-in-development exists now (and I can change it) I'm storing only 10 digits. I'd like to think my software may be in use 10 years from now, although I can certainly release updates. But since the trend is for every person to have a phone instead of just one number per household, I understand the USA is running out of 10-digit phone numbers.
I know it may not seem so, but yes, I HAVE Googled and the answer I seek is still as clear as mud.
I read that there are locales within the USA (I don't know where) in which even within the same area code, a 1 and the area code must be dialed first. Other times, just the area code must be dialed, without the 1, even within the same area code.
MY QUESTION IS: To accommodate the whole USA and the foreseeable future, will I need to add an "optional 1" in front of the number, in the form of a check box or other device to distinguish those which need a 1 from those that don't? Is there another phone number schema coming in the future? Or putting it all more simply: Is 10 digits enough?
if you only want to store North american numbers you'll be fine
North American Numberin Plan
10 is the standard length in north america (includes canada)
You should allow for 15 digits including the country code. You already need 12 to 14 digits (including country code) for many countries.
Store all numbers in E.164 format including the country code, without spaces or punctuation.
This will allow easy expansion internationally to other countries and also allow manipulation of numbers in the database if the length of numbers used in any country were to ever change.
There's talk that US numbers will become a digit longer some time in the next decade or or two. You should plan for that now, not when you have tens of millions of numbers stored.
There's constant change in national number plans. If you know that area code 765 in country 980 is changing to area code 77 and all local numbers are having 88 added to the beginning it's a simple operation to make that change if all the numbers in the database include the country code.
I'm developing an Android app that has postal address routing in it.
We would like to sort each address in a database table in such a way where each address can be printed out for our driver. We don't want to spend time sorting addresses ourselves when a database table would be ideal for that.
I was thinking somehow to create a primary key in the table on a number that we can easily sort in ascending order. That would make it easy to create a manifest for the driver.
I was researching and found that there was something called WOEID (Where on Earth ID) which I think represents a region but I'm not sure if it would be good for us since 2 postal address in the same neighbourhood could use the same WOEID.
For example these 3 addresses have the same WOEID:
100 Bowden St., Lowell, MA
131 Stedman St., Lowell, MA
50 Stromquest Ave., Lowell, MA
The concept of using a single number like WOEID is perfect for us but we need to sort addresses like these in order so we know which ones are closest to each other.
Maybe there is a web site we can use to send out a request from within our app providing them with the postal address and the site will return a single number representing that address in a format our app can parse.
Maybe there is a way to Geocode or convert latitude and longitude numbers into a single number we can use.
Thanks.
So the problems arise when multiple addresses share the same WOEID? I don't know how many resources are available but couldn't it be in idea to fed this data to some API like Google Maps and calculate the distance from your position to there?
If you want to avoid google a really basic approach could be to do the calculation by yourself. (Though this would be more of an estimation.)
However I got the feeling you want to find the best route over total distance so I think your problem is also related to the travelling salesman problem
Given a list of cities and their pairwise distances, the task is to
find the shortest possible tour that visits each city exactly once.
I found a web site that allows me to do a reverse Geocoding. It returns a latitude and longitude.
I experimented a bit and found that I can add the latitude and longitude together to get a single number. Since giving an exact address to the web site will give results not completely what I'm looking for I give it just a street and city and US state to locate. I can then use the latitude and longitude returned and then sort the house addresses in numeric ascending order.
For example we have many streets that are very grid like so 1 number from the adding of the latitude and longitude represent many homes on 1 particular street. On another street a block away I did the same thing. Now all I have to do is just list everything in the database table like this:
City chosen by a dropdown, US state also chosen by a dropdown, then the geocoded number for each street followed by the home numbers.
Here is the web site I used to get the Geocoding along with a sample street address:
http://where.yahooapis.com/geocode?q=stedman+st,+lowell,+ma
Background: I receive a long and lat as parameters to a web service. They are typically up to 6 decimal places. When a new request is received, I calculate the distance between the last recorded loc and the long/lat in the params of the request. If the distance is greater than a certain threshold of miles apart, I update the current loc.
Problem: I use the geokit gem/plugin to calculate the distance between the locs. Very rarely, a bug shows up (the zero distance bug mentioned on the author's site - I'm using 1.4.1 which claims the bug is fixed, but I still see it occurring shrug) that causes the distance calc to return something wildly inaccurate when calculating the distance between two points that are identical (this occurs if the user is not moving). This is causing updates to the user's current loc that should not be happening. You're probably wondering - well if it's just updating the loc to be exactly the same coordinates, who cares? Well, the answer is that a bunch of other crap occurs when the loc is updated that makes it an actual issue.
Attempted Solution: I tried to add in logic to manually check if the two locs are identical before calculating the distance and then just skipping the calc and not updating if that is the case. The incoming parameters are long/lats with 6 decimal precision; whereas, in my database, I store the values as floats, which appears to only store 4 decimal places. This is causing my float comparison to always fail and the inappropriate loc updates continue to occur.
Phew, ok so the actual question is: How should I perform this comparison? Should I truncate 2 of the decimal places from the incoming lat/longs, round up somehow so the fourth digit is correct and then compare? Or, should I do a "within a certain range" sort of comparison (e.g. reported_loc.long > current_loc.long - .0001 && reported_loc.long < current_loc.long + .0001)? Also any recommendations for existing ruby gem/plugins or built in functions to do this sort of thing would be much appreciated.
Here is sample output from the log:
[update_loc] Last location history record at lat: 41.5024, long: -81.6816
[update_loc] Current loc at lat: 41.502467, long: -81.681623
[update_loc] Distance from current loc and last loc history: 5795.10615113555 miles
[update_loc] Locs not identical and distance greater than threshold, inserting new loc history
[update_loc] Location update complete
Thank you
Tom
The usual way to test if two numbers are close is to use abs, ie,
(reported_loc.long - current_loc.long).abs <= tol
where tol is some pre-specified tolerance, eg, 0.0001.
A GPS receiver can give you a location with a precision of many decimals, but that doesn't mean that the measurement is actually that accurate.
Usually about 95% of the measurements lie within a circle of a couple of meters, which is about the same accuracy that you can store with a 32bits float.
However, you will clearly notice rounding errors when you plot a gps log as floats on a map.
Anyway, to do this comparison, I'd use a range instead of rounding the incoming value and comparing that to the database value. You won't be able to detect the smallest movements anymore, but at least you won't get false positives anymore either.
As you're using floats to store stuff, you clearly don't care about millimeters or centimeters anyway.