I'm using http://code.google.com/p/php-google-map-api/. I made an application to get latitude and longitude of different street names. But when I execute this script from outside my country this precision is lost and I can't geolocate all the streets.
I think that Google keeps a different index depending of the country you are. How can I change the country (or locale) of my API?
Once we had an experiment on Mobile Network Development. We used GoogleMaps as basic geolocation tool for mapping/locating and measuring Base Stations characteristics. As the result, we've got into trouble very quickly.
We needed rather precise data (about 5 meters maximum deviation) and what do you think ? The street which was 2 km long (what was measured after experiment with required accuracy) was calculated as 1.7 km in GoogleMaps.
Moreover, most of the patches (ground photos) that are shown on map, overlaps each other in different way. Actually, it depends on country and on the precision of shooting, because some countries are more detailed some are not (very not).
Speaking about streets, this deviation is rather considerable to say that it can be precise. GoogleMaps should not be treated as the precise geolocation tool in any case, especially if high precision is required (street level is already above-normal precision).
So, I propose you not to take into account this data very seriously. Otherwise GoogleMaps is a very nice security breach for all of us. Imagine that You have nuclear bomb or missle and you already know where to direct it with accuracy of several meters, sitting somewhere in the middle of the Sahara. Here you are ...
Related
Using Google Map or any other map provider, if I have a GPS tracking device on a train, how do I get a railway distance between the train to the nearest train station?
If you are physically on the train and have a GPS tracked device, most mapping platforms won't be able to snap you to the railway line unless the device/user is sitting at a station. If the device is close enough to road, usually within 150 meters, it will likely snap to that. If the user was at a station, its much easier and just a matter of calculating a transit route.
That said, most transit data uses straight line distances between stations and not true travel distances. I've worked with many large transit agencies around the world and many of them don't even know where their railway lines run, let along the true distance between stations. What they do know is how long it takes to travel between stations and that's all they generally care about for the most part.
To do this correctly, you will need access to the raw railway line vector data. Open street maps has some, but I don't know how accurate or complete it is. Many agencies or governments publish this data, but often it is just straight lines drawn between stations, so you would have to look and see what's available. Once you have complete data, then you can snap to your GPS point to the nearest railway line then calculate the shortest path along all railway lines to the station in question. This is fairly complex, but I've done this before for both railway lines and private road networks. There are several open source libraries that can assist with this, like this one: https://github.com/perliedman/geojson-path-finder
We have a tool on our travel site which should exactly calculate the distance from the visitor location to a given hotel which is known bye longitude and latitude. To achieve this we use google API but this is not accurate, some time the visitor location is about 40/50 km from the real location. According to other coders is not possible to do better. I can't believe that there is no the possibility to detect the exact geographic location of visitor. I have seen there are some other similar question but those are 2/3 year old.
Thank you
the location of a device can be obtained in two ways, by means of GPS or by means of the approximate location of the IP. The GPS reception can be affected by various factors .. in the cities is of some importance to the Urban Canyonin ie the reflection of the GPS waves on buildings. these factors can lead to an error of several meters and particularly unfavorable circumstances even of some tens of meters .. Another mode of detection is based on the geo-referencing of the IP and on routing that uses the device through wifi networks or data connections in this case the error on the position is normally a few tens of meters ..
I recently worked on a small project on location-based services and my intention was to locate the nearest cab (GPS fitted) within a given radius of a requesting passenger (GPS enabled Android phone). I wanted to use MongoDB's geospatial indexes, but it turned out that geospatial indexes work on lat-longs and they calculate displacement between two points, not the distance. In my case, search was confined within a city, and I had to go for GoogleMaps Directions Service because it tells the distance as on the road, estimated time taken etc.
Does this mean that geospatial indexes make sense only when displacement is large enough, so that distance and displacement becomes essentially the same?
Geospatial indexes have the goal of having fast data retrieval based on position on a multi-dimensional space. If you have the cab position data in a MongoDB database you could use a geospatial index to fastly select a reduced set of cabs which are more likely to be the closest one, but still you'd have to calculate the distance on the road (and eventually the drive time) using an algorythm on the road network.
For example you know that if the closest (in straight line) cab is at 20km from you (measured through the road), you know that any cab outside the 20km radius will surely be further away (on the road) than the first one you found, so you're not interested in them.
You can then use MongoDB spatial index to get all the cabs in 20km radius and then you can find among them which one has the minimum distance.
I have been reading the W3C Geolocation API specification and I was wondering if anyone has found any information on how accurate the location returned is.
I found the accuracy attribute:
The accuracy attribute denotes the accuracy level of the latitude and
longitude coordinates. It is specified in meters and must be supported
by all implementations. The value of the accuracy attribute must be a
non-negative real number.
But I'm wondering if anyone is aware of a possible range for these values? Is there a maximum number of meters that will be returned?
Any application I wrote that used this would be used in a relatively small geographic area, does the accuracy depend on where that area is?
Note:
I found a similar question, but it does not talk about the accuracy range and I believe they are talking about using Google's GeoLocation service.
Based on experience the accuracy on device without GPS, like laptop that only relies on Wifi mapping, is 100-200 meters in urbanized area. With GPS, like in mobile phone browser its as goods as it gets, 10-30 meters.
I'm developing a Mapping Service with Bing Maps AJAX API and SQL Server 2008. The question which appears to me is should I use the geography or geometry data type. I researched a lot but doesn't found a satisfactory answer. Here are some links about the topic:
SQL 2008 geography & geometry - which to use?
http://www.mssqltips.com/tip.asp?tip=1847
https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/
If I compare the two types I see the following points.
pro geography
consistent distance calculation around the world (time line!)
the coordinate system of the database is the same as the one which is used to add data to a map with the Bing Maps API (WGS84)
precise
contra geography
high computational costs
data size constrained to one hemisphere
missing functions (STConvexHull(), STRelate(),...)
pro geometry
faster computation
unconstrained data size
contra geography
distance units in degree (if we use WGS84 coordinates)
The problem for me is that I don't need a fast framework, a great coverage (the whole world) and high functionality. So I would prefer the geometry type.
The problem with the geometry type is, that I have to transform my data into a flat projection (Bing Map use SRID=3875), so that I get meters for the calculation. But when I use the Bing Maps projection (3875) in the database I have to transform my data back to WGS84 if I won't to display it in the map.
You've provided quite a good summary of the differences between the two types, and you've correctly identified the two sensible alternatives to be either geography(4326) or geometry(3857), so I'm not quite sure what more information anyone can provide - you just need to make the decision yourself based on the information available to you.
I would say that, although the geometry datatype is likely to be slightly quicker than the geography datatype (since it relies on simpler planar calculations, and can benefit from a tight bounding box over the area in question), this increase in performance will be more than offset by the fact that you'll then have to unproject back to WGS84 lat/long in order to pass back to Bing Maps - reprojection is an expensive process.
You could of course store WGS84 angular coordinates using the geometry datatype, but this is really a hack and not recommended - you are almost certain to run into difficulties further down the line.
So, I'd recommend using the geography datatype and WGS84. With careful index tuning, you should still be able to get sub-second response time for most queries of even large datasets. Incidentally, the "within a hemisphere" rule is lifted for the geography datatype in SQL Denali, so that limitation goes away if you were to upgrade.