Well I have a problem with Geolocation, when the page is initialized I have “right” location, after I refresh the page there are different location, maybe 10 meters from first. After one more refresh I have a third location, etc.. I tested on this link https://developers.google.com/maps/documentation/javascript/examples/map-geolocation , and again I don’t have a right position.
Accuracy of geolocation depends on how does your geolocation is determined. It may change.
There are a variety of ways that your
device and the location service provider
calculate your position, and some are more
accurate than others. GPS is often the most
accurate.
You may like to know
How the Geolocation API determines your location -
IP Address
Location information based
on your IP address uses an
external database to map
the IP address to a physical
location. The advantage of this
approach is that it can work
anywhere; however, often
IP addresses are resolved to
locations such as your ISP’s
local office. Think of this
method as being reliable
to the city or sometimes
neighborhood level.
GPS
Global Positioning System,
supported by many newer mobile
devices, provides extremely
accurate location information based
on satellites. Location data may
include altitude, speed and heading
information. To use it, though, your
device has to be able to see the sky,
and it can take a long time to get a
location. GPS can also be hard on
your batteries.
Cell Phone
Cell phone triangulation
figures out your location
based on your distance from
one or more cell phone towers
(obviously the more towers, the
more accurate your location
will be). This method can be
fairly accurate and works indoors
(unlike GPS); it also can be much
quicker than GPS. Then again, if
you’re in the middle of nowhere
with only one cell tower, your
accuracy is going to suffer.
WiFi
WiFi positioning uses one or more
WiFi access points to triangulate
your location. This method
can be very accurate, works
indoors and is fast. Obviously
it requires you are somewhat
stationary (perhaps drinking a
venti iced tea at a coffee house).
Related
I am using Flutter to write my running app likes Strava. In this app, I used location and google maps plugin for flutter. Everything is good until I call getCurrentLocation every 10s to track my location and receive different LatLng even if I stand still.
Did anybody here face the same problem? I think it probably cause by the GPS's accuraccy issue.
Every few seconds, Android (and ios) gets a new location by either connect to cell towers or connecting to gps satellites. Based on that data it determines the most likely location for you on the globe. Since these measurements are not 100% accurate, every time it recalculates the users location, there will be a slight difference in location. Even if you stand still, your lat-lng values will change slightly. That is normal. You can decide to discard the new value if it is too close to the previous one. maps_toolkit is a good library for calculating the distance between two locations.
I was wondering how Google geocodes and address? Does it work like a DNS lookup, where they have a big table of addresses which is a hash to a geocode, or is there any fun geometery that goes into it? If it is a big hash table how did they go about gathering all that data?
Busbina, I work for SmartyStreets where we verify and geocode street addresses -- so I'll tell you what I know, and link you to further sources for your own research.
To answer your question: It is both.
There are suppliers of massive databases (for example, those like TIGER Data) which contain relational, geo-political information including coordinates, streets, boundaries, and names. For US data, it is likely to obtain at least ZIP-level accuracy through tables like these simply by doing a lookup. For more accuracy, though, append the +4 code and you may narrow it down to a city block or floor of a high building.
To attempt further accuracy (ie. knowing where precisely on the street a building is located), Google and others perform what is called interpolation, where they take the known boundaries from their datasets and and the known range of primary numbers from the start of that block or street to the end of it, and they solve a ratio. If the correct primary number is known, and for straight streets in an ideal setting, a simple ratio like this works:
(primary number - starting primary number) / (ending primary number) =
(x - starting boundary coordinate) / (ending boundary coordinate)
Where x is a close guess to the actual location on the street - but only a guess. Accurate building-level data can be very expensive and I think is only available for some urban areas.
The key is to get the right primary number and accurate, up-to-date data. Maintaining this can be time-consuming and expensive because of all the overhead involved with so much information.
Note that Google and similar map services only perform address approximation, not address verification, and thus are liable to make mistakes (even if the geocoding algorithm is very precise) because the primary number may be wrong or may not even exist. So when that matters to you (or you aren't showing a Google Map and must honor the Terms of Service), something like LiveAddress, as a starting point, is certified by the USPS and won't return bad addresses.
So there are some things to consider.
More information:
http://en.wikipedia.org/wiki/Geocoding#Address_interpolation
http://www.ncgia.ucsb.edu/giscc/units/u016/u016.html
** I'll add a note, since I have had this question a lot: rooftop- or building-level accuracy is very expensive information. I know of very few providers who offer this, and they have mined and collected that data themselves. For example, Google has the Street View project, from which they've obtained accurate coordinates for approximate addresses, and they can provide such precision. But most geocoders use the same data from official sources, they just interpolate differently. If you want extremely precise coordinates like building-level, you can expect to pay mightily for it, or go collect the data yourself. (Yes, Google's is free to a point -- unless you intend to use the information for more than just showing a map, basically.)
Another service that is very similar is GeoNames which is a US Government run database of location names. This service is better tailored towards points of interest, like an airport or landmark. This is just a database of names, locations, and some meta data.
http://www.geonames.org/
I am building a mobile web site for a physical product. The typical use-scenario is opening the web site by scanning a QR code on the product label.
I would like to have a page with a list of of vendors, ordered by distance from the phone's location. If the page can not get the phone's location, I would like to show the list sorted alphabetically.
What's the right way to code this, in a way compatible with both iPhone and Android?
http://diveintohtml5.ep.io/geolocation.html explains usage of the HTML5 geolocation API.
You'll probably then want to make an AJAX call to some server which will retrieve a listing of vendors with their lat/long coordinates, name, etc. given the part you scanned.
If you got a geolocation result back, you can sort the list by distance using the standard sqrt(a*a+b*b) distance formula, assuming the distances aren't too far and you aren't too close to a pole, and depending on how accurate you need the distance calculation to be. If the distances are far, or you're at high or low latitudes, or the accuracy requirement is high, you'll need to do some more complicated math to operate on a spherical coordinate system.
The actual process of sorting the list will depend on what framework you're using (if any).
Just a quick question I have built the following code:
http://letterpool.testmode.co.uk/map.html
However with some users I am getting reports that people are getting around a 200-300 meter of their actual location.
Does any one know why ?
The W3C Geolocation API, which you're using to locate users on the test map, is intentionally agnostic to the method the browser uses to locate the device. This is a useful convenience since devices vary widely on how they locate (GPS, WiFi triangulation, cell tower triangulation, IP geolocation, manual entry, etc.) and your website probably doesn't want to deal with all of those details.
However, if you're not happy with the accuracy, there are a few options you can take advantage of that may help. The enableHighAccuracy option will hint to the device that it should prefer to use up a little more power in order to get a more precise location. You're currently using the latitude and longitude of the return value, but the API also returns an accuracy value, so you can see whether the position you're receiving is precise or not. You could also use watchPosition which will continually update the location and may eventually get a precise enough fix for your purposes (most mobile devices tend to start with low accuracy and get more refined over a few seconds or minutes).
Because geo-location is not accurate and never has been. They are probably getting the location of the closest junction box.
With me, it found the data center where my ISP operates from - miles away.
See this article.
Geolocation of course depends on the available position measurement methods. If the browser only has the IP address then it will be very inaccurate, but if it has access to a a GPS device like in a smartphone it will be pretty good.
I want to get geocode from google, and I used to do it with the V2 of the API.
Google send in the json a pretty good information, the accuracy, reference here : http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy
In V3, Google doesn't seem to send me exactly the same information. There is the array "adresse_component", which seem bigger if the accuracy is better, but not exactly.
For example, I have a request accuracy to the street number, the array is of size 8.
Another query is accuracy to the route, so less accuracy, but the array is still of size 8, as there is a row 'sublocality', which not appear in the first case.
Ok, for a result, Google send a data 'types', which have the 'best' accuracy. This types are here : http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types
But, there is no real order, and if I wan't the result better than postal_code, I have no clue to how to do that.
So, how can I get this equivalent of the V2 accuracy, whithout some dumb and horrible code ?
Well, there is the location type, which is not so bad :
location_type stores additional data about the specified location. The
following values are currently supported:
"ROOFTOP" indicates that the returned result is a precise geocode for which we have location information accurate down to street address precision.
"RANGE_INTERPOLATED" indicates that the returned result reflects an
approximation (usually on a road) interpolated between two precise
points (such as intersections). Interpolated results are generally
returned when rooftop geocodes are unavailable for a street address.
"GEOMETRIC_CENTER" indicates that the returned result is the geometric
center of a result such as a polyline (for example, a street) or
polygon (region)."
"APPROXIMATE" indicates that the returned result is
approximate.
I test if the location_type is different of approximate, and it gives some good results.
With Google deprecating their Geocoding v2 API later this year, there's going to be a ton of people migrating their geocoding logic to v3 and this very question is going to crop up: How to map the 'location_type' string to an equivalent 'accuracy'?
Here's a decent mapping:
"ROOFTOP" -> 9
[Everything else] -> 4 to 8 (aka the text string might as well read "GARBAGE")
If something other than ROOFTOP is specified, use the area of 'northeast' and 'southwest' to decide if it is accurate enough for you.
Now what should happen if you don't get something "accurate"? Run a Google Places text search query for the same address. Google Places does geocoding as well and, with Billing enabled, you can get 10,000 Places text search queries per day (no rate limit) and Google claims they won't charge the card (they supposedly just use it for verifying the account). With Billing, you get 100,000 queries, but Places text search queries have a "cost" of 10 times the amount of a regular Places query, hence the aforementioned 10,000 limit. Places can be finicky though and you should only consider responses with one result.
Sometimes Places queries will not return a zipcode - especially if one isn't sent. If you need the zipcode, take the lat/lng results of the Places query and feed it back into the geocoder, which will usually spit out an address with a zipcode (and very frequently a ROOFTOP match).
It should be noted that the official Geocoding API courtesy limit is 2,500 requests per day with a rate limit of one per second per IP address. Therefore, following the above formula will likely decimate and may even halve the number of geocodings available to you.
If you need more than the Google Geocoding limit (who doesn't?), invent your own mini geocoding service with something like the OpenStreetMap database. Clone the parts of OpenStreetMap that you need and write your own geocoder (or use a library). Then you can geocode to your heart's content with no quantity limit or rate limit. If you still use Google Maps, you can use Google's geocoder as a fallback should the OSM geocoder not be accurate enough for all cases.
Alternatively, if you trust your users to not submit bogus data (really?) and have to use the Google geocoding service, you could also abuse a user's web browser by having the browser geocode information for you and then feed the results to your server. You might burn through the user's daily limit and you risk someone pushing bogus data, but if you are going to all that trouble, do you actually care?
At any rate, the tips above should suffice for interim usage for most users to get a working v3 API set up. Ran into this issue myself, so figured I'd share with the community a halfway decent solution. I still think v2 was the better API - integer accuracy ratings instead of ugly text strings always wins out.
Paula's answer is good but you do need to also consider John's comment that ROOFTOP can return garbage.
I use a post-geocode-query sanity checker to get rid of those cases where location_type is 'ROOFTOP' but the address has nothing to do with the address you sent to google - this sanity checker compares the new address with the old address and considers what changed and by how much. The google geocoder is good at fixing typos, sometimes, but it can also make some non-sensical decisions - for instance choose a different city, a different state, or a different country. You need to decide if the result is a fix in a typo or if the geocode logic went astray.
So, don't just assume ROOFTOP == 9. It can also be garbage if the new address is way off from the original that you sent.
For things like Apartments or building with multiple units, the location_type = 'RANGE_INTERPOLATED' may also be accurate when the result type is 'subpremise'.
Remember, geocoding is not the same thing as address validation. They have some overlap but google geocode logic tries too hard to get you an answer, even when your input is garbage.