There are any documentation for this? I've checked many formulas and algorithms but didn't find an explicit definition how they get the speed provided in Geolocation object.
The GPS chipset provides the current velocity to the system along with the current location.
The chipset may compute the velocity by comparing location over time and correcting for the curvature of the Earth at the current location, or from the Doppler shift of the received satellite signals.
Whichever method is used, the operating system doesn’t need to do any processing to get the speed. The velocity data is provided along with location and altitude data directly from the GPS chip (actually chips in many newer devices support both GPS and GLONASS, but which system is used is not visible to the user).
Physics.org has a simple explanation of how GPS works
Wherever you are on the planet, at least four GPS satellites are ‘visible’ at any time. Each one transmits information about its position and the current time at regular intervals. These signals, travelling at the speed of light, are intercepted by your GPS receiver, which calculates how far away each satellite is based on how long it took for the messages to arrive.
Once it has information on how far away at least three satellites are, your GPS receiver can pinpoint your location using a process called trilateration.
But you can search for more detailed explanations of the mathematics and physics involved.
It basically scans your location (i.e. your latitude and longitude) and compares with the last check. Using euclidian distance, it can get the distance in the period of time. With the time (for example, if it scans your location every 2 seconds), it can easily estimate your speed by doing Speed = Distance/2.
Related
Hi i am working on a real time location tracking application where i have used Fused Location provider Api. I was able to get the location updates when the device is moving. But i was also able to get the location updates even if the device is stationary on a table when i am indoor. So I have calculated the distance between the last location and the current location triggered in Onlocationchanged event and checked whether the distance is less than 30 metres, to know the device is actually moving. But sometimes the distance i get is greater than 400 metres (indoor/Device is Stationary). How Can i ignore the onlocationchange event when i am indoor? Any suggestions are appreciated.Thanks in advance.
Unfortunately I don't believe there's much you can do about it.
The reason you see those updates with great changes it's because indoors, you won't get a GPS lock, so the device is relying on cell tower and WiFi hotspot triangulation to determine your location, and something around 200m to 1km is the best you'll get with this kind of technology.
A possible attempt to hack-around it would be to:
check the source and precision of the location update
use the activity recognition API to guess if the device really moved
but both are a hack, around the technology limitation and might not be as reliable.
I'm building an app for mobile which needs to monitor the distance between the user's location and multiple location markers at regular intervals. From what I have read here and on other sites, I have three options:
1) use the distanceTo and distanceBetween functions to calculate the distance between the user's location and each location marker
2) use proximity alerts associated with each marker location
3) use geofences associated with each marker location as per Creating and Monitoring Geofences
Which approach is the best to use in light of (a) ease of implementation, (b) battery drain, and (c) gps / location accuracy? Given that I am designing predominantly for mobile, I am assuming that wifi will not always be available.
An important note on the Google Play GeoFencing API. I've found that the GeoFencing never intelligently retrieves locations from the GPS hardware. The GeoFence API will observe the most accurate location available from the OS or if no recent location reading is available, it will cause a location to be calculated from Wifi / Cellular. (which sucks because cellular is wildly inaccurate and wifi is often unavailable)
So to get at all responsive or accurate results out of the Geofencing API you have to set up your Geofences and then poll the GPS hardware on an interval, not even doing anything with the result received, so that under the surface you are providing worthwhile data to the OS.
I can't speak specifically to the behaviour of LocationManager.addProximityAlert but I doubt it behaves any differently. You could really use either and the results and performance will likely be identical because the heavy lifting is done by waking up the GPS manually.
As for how to implement your current distance to your fences, none of the proximity APIs have an interface to determine this for you. In the situation I describe above when the GPS poll occurs, instead of doing nothing with the result, I'd use it with distanceBetween to update the distance between myself and the points I've set my GeoFences at.
I have been using LocationManager for Android to record location data, and the new 'LocationClient' API has come, so I tried it.
The result looked good. It gets location data very quickly, but I found that the Android Fused Location provider(LocationClient) doesn't provide altitude data in almost all cases, even though I tracked quite a long time.
So, the question is, 'Is there any nice way or idea to get altitude data while using LocationClient?', or should I just stay using GPS provider which is not fast enough?
AFAIK, the only provider today in standard Android that can give you altitude is GPS. AFAIK, both WiFi hotspot proximity and cell tower triangulation presume that you are on the surface of the Earth, or at least within a relatively narrow band of the surface, treating the local area as a flat plane.
LocationClient and the "fused" location provider is designed to blend all of those approaches to get you more accurate latitude/longitude more quickly. However, if my AFAIKs are correct, it cannot get altitude any faster than GPS. And, depending on how it handles things internally, it may put more emphasis on the non-GPS providers, and therefore give you altitude less frequently. Since the Play Services stuff is closed-source, we have no good way to know.
or should I just stay using GPS provider which is not fast enough.
The speed of obtaining GPS fixes is tied to environment (e.g., indoors/outdoors) and to device GPS receiver quality.
I want to write a LocationListener that takes the most accurate and precise recent location as its location. I'm intending to use this code in my LocationListener:
#Override
public void onLocationChanged(Location location) {
if(location.distanceTo(mLocation)>location.getAccuracy()){
mLocation = location;
}
}
What I intend this to do is update the location if the user's old location is outside the circle of "possible locations" that the new location indicates. So, for example, if our last measurement was a GPS signal and the new one is a cell tower, and the old location was in range of the cell tower, we don't update; on the other hand, if the cell tower is sufficiently distant, we know the user has moved and record that.
However, the distanceTo(Location) function states it returns the approximate distance in metres between locations. Does it already take the accuracy into account? Will it give me a precise enough figure to let me use in this way?
Short answer is no, Location.distanceTo(Location) does not take Location.getAccuracy() value into account when measuring distance.
Here's the actual code from the Android platform that is used to calculate distance for Location.distanceTo(Location):
https://github.com/android/platform_frameworks_base/blob/master/location/java/android/location/Location.java#L272
It uses Vincenty's Inverse Formula (http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf - Section 4) based on the given latitude and longitude (accuracy not considered).
As to whether your method of updating the "true" user location will be "precise enough", it really depends on GPS sensitivity, accuracy, and precision, which can vary significantly from device to device.
The accuracy estimate value from Location.getAccuracy() can also vary widely depending on the OEM, and typically devices I've seen overestimate accuracy (i.e., the device gives an accuracy value greater than the true accuracy) more than underestimate accuracy.
You might want to check out an app I created "GPS Benchmark" (http://www.gpsbenchmark.com/) which helps quickly benchmark location provider accuracy (GPS and Network) on Android devices, as well as "estimated accuracy" accuracy. I also co-authored a paper on this topic (http://journals.cambridge.org/repo_A82eaJIy) based on GPS benchmarking results from some Java ME devices, and most of the material is also relevant to Android.
I am using LocationManager to get the values of Latitude and Longitude of a user. These values are updated regularly to a database and find out the distance between two users basing on the stored Latitude and Longitude values.
Now,onLocationchanged() called very slow,some times get fast.while i'm waiting long time to proceed next process.When i 'm in indoor the Location search is very slow..
Is there any solution to this prob.pls give me a guide and example.
Please Accept My question as soon as give me a solution.
If you use network location provider, you will get location faster, but it will be less accurate (100-500m).
OTOH, GPS provider will be more accurate (10-20m) but it will take more time to acquire location as device needs to acquire GPS satellite signals. Sometimes it's not even possible to acquire signals, especially if indoor or beneath thick trees.
Well there are there types of GPS starts :
COLD start: takes a lot of time. The old GPS (satellite/time) data is practically useless.
WARM start : is when the GPS device remembers its last calculated position, almanac used, and UTC Time, but not which satellites were in view. You get the fix fairly fast.
HOT start : is when the GPS device remembers its last calculated position and the satellites in view, the almanac used (information about all the satellites in the constellation), the UTC Time and makes an attempt to lock onto the same satellites and calculate a new position based upon the previous information.
To emulate the warm start case all you have to do is connect to the SUPL network, which provides assistance data. Even cold starts can be converted to a warm start. To make sure that SUPL networks are available, make sure you are connected to the internet. In indoor cases no satellites are visible so getting an exact fix is tough without any assistance data. At least 3 satellites should be visible. Again SUPL networks come to the rescue.
Note that, various GPS chipset have different performances/algorithms and the triangulation time depends on the SUPL networks provided by your Network provider.
You can here more about this here
Good starting point is blog/project by Reto Meier:
http://code.google.com/p/android-protips-location/