I am using Google Direction Service for route drawing by providing it way points (recorded at some specific time interval). While drawing, it, sometimes (may be due to slight error in GPS measurement), it draws like the vehicle took a U turn to reach there. I guess it can be solved only if google ignores road dividers.
For example:
Look at the below picture, my vehicle moves on left road, but due to GPS accuracy issues, it sometimes gives me coordinates on right part of road. And when I give the coordinates to google to draw the the path, it gives me a U - Turn.
Can anybody please tell me how can I solve this issue?
Related
I have a web app that allows users to create a cardio workout where they may or may not be actually moving. They could create a "run" either outside or on a treadmill. Either way, geolocation is automatically enabled for the workout.
But I only show the distance on the screen if they have moved at least .25 of a mile. I have tested this myself and the problem is that geolocation is telling me I'm moving even when I'm not!
This evening I was on the eliptical machine for 32 minutes and my app told me I had moved 1.15 miles.
If I test the app when actually moving, (e.g. in a car, on a bike, etc.) geolocation works fine. It's only when I'm NOT moving that I'm having problems.
Anyone else face this issue? Is there perhaps a hack to prevent it?
I'm using Chrome for Android as the browser.
Well I've come up with my own solution to this issue. I'm sure it's not perfect, but it seems to be working well. It is partially based on this excellent article...
Getting the best single location
For my web app, I used an array to capture 50 lat/lng's with an accuracy of less than 11 meters. After capturing the 50th coordinate, I grab the next lat/lng to be my current position. I am basically assuming that after checking 50 coordinates with accuracies better than 11 meters, I should have a pretty good idea where I am.
When checking coordinates on indoor WiFi (such as in a gym on a treadmill) the accuracies rarely get near 11 meters, and the array either does not fill up, or it takes a half hour or so to fill. Even so, by that point my position is pretty stable, and the app will not calculate distance when I'm not actually moving.
When outside using cell towers, the array will fill with 50 coordinates normally in less than 30 seconds. This means that I lose the first 30 seconds of the persons movement. But if you're walking or riding a bike, that really isn't missing much. In the end, my distance measurement may be off by .15 of a mile or such. I can live with that.
The biggest lesson I've learned is that "getCurrentPostion()" for HTML5 geolocation is basically worthless. The method simply forces lat/lng coordinates out of the phone, which are usually way off. In my code I call "updateLocation()" 50 times to collect the coordinates. In the end, this is much more accurate.
Take some time and read the article posed above. You'll learn a lot.
I would be very happy if someone could help me on this. i am planing to write a script that simulates a moving car on google maps. simply a marker that is traveling across the roads. the point is that it has to move and turn randomly on the roads, i mean without a end destination. it should just need a starting point and decide on its own where it has to turn.
here for example it moves across the destination: http://econym.org.uk/gmap/example_cartrip.htm
what i need is to give it just one location and it starts to move and turn randomly and continuously.
is that possible. and how can i accomplish that. i would really appreciate if i could get a lead.
PS: at the same time i need to store each moves coordinated in to the database.
I have lists of between 100 and 10000 GPS location from vehicles driving around during some timespan.
I want to display that on a Google Map, using their API (with the Business licence if that matters).
As I see it, there are 3 options, all with problems:
1) Draw a polyline between all positions. Some positions are not that accurate so it looks like the route hits some buildings next to the road. I know that all positions are on a road. Also, it cuts some corners, and it doesn't look professional.
2) Display just the GPS positions in the map. This is not good either since the GPS positions are off the road (which they shouldn't be).
3) Draw the route using Maps API. This limits us to using 23 waypoints between the start and end positions. The route looks excellent and it follows the road (GPS positions next to the road are moved to the road automatically). But especially for longer time spans, this option means that the route displayed is incorrect (Google guesses the route taken between the waypoints - so from the 10000 GPS positions it only uses 23). And we can't display a clearly incorrect route.
Does anyone have a good/better way to show a driven route on Google Maps that follows the road but takes into account all/many given GPS positions?
Could you not chain the route using the maps API? It's not something I've done before so this answer could be a little vague but would it not be possible to segment your list of coordinates into chunks of 23 fire the requests and then display the resultant routes on the map?
I'm not overly sure on the return format so it may be necessary to mess with the output in order to give the illusion of the route, also you will likely not need to use every coordinate (perhaps exclude those that are within a small distance of each other for example being stuck at lights), otherwise the requests may take a long time.
We've actually moving away from option 3. The reason is that when the positions get moved to the nearest road, that is not always correct (like if you're driving on a parking lot), so since that doesn't always give the correct route, then we'll not take that path.
So I don't know if it's possible to chain several routes in the same map.
I'm trying to build a map with the following algorithm:
Wait for pan or zoom to occurs.
Query for all streets visible in the viewport (extent).
Color every visible street with a predefined color.
Example:
I want to show the numbers of businesses on each street, or the number of crimes committed at each street.
I have a DB which holds this kind of information (streetname, data), but each row doesn't have the location data.
Therefore, after each map zoom or pan, I cannot query all of it by a geographical bounding rectangle, it will be far more efficient to use Google own DB and query it by street names.
I know how to register to pan and zoom events.
I know how to calculate the viewport coordinates.
I know how to color a single street.
How can I get a list of all streets visible in the viewport?
Any other solutions or architectures are welcome.
The preferred solution will not use Google DirectionsService nor DirectionsRenderer since they slow down the map.
My understanding is that what you are asking is not possible from Google API's. Reverse geocoding inside a polygon is not a service they offer. There are some posts on other sites (e.g. https://gis.stackexchange.com/questions/22816/how-to-reverse-geocode-without-google) with the reference gisgraphy.com looking like a pretty neat reverse geocoding tool.
This still does not address your all streets in a polygon problem however. I think your only option would be to get your hands on the data (Open Street Maps) and write the code yourself. Further - if you are going to do this for a large area I would take an approach like I recommended here with grids: https://stackoverflow.com/a/18420564/1803682
I would create my grid elements, and for each street calculate all the grids to which it belongs and store in the database. Then when you search a polygon, you would calculate all the grids the polygon overlaps, and can then test the subset of road data in each of those squares to determine overlap.
I looked into this and abandoned a similar requirement a few months back and still have a desire to implement it. Most of the point/line in polygon work is happening on data created in my application (i.e. not street data) and right now that is the only data I will be including. What I am trying to say is - I hope someone gives you a better answer.
Update:
For what you are asking I still believe you will need to use a mix of your own database based on OpenStreetMap and some kind of grid analysis carried out in advance. If you have some time to commit to the project this should not be too awful to process. The database will be large, and the calculations needed will likely require a significant amount of one-time / upfront processing time. As far as highlighting routes/roads/whatever within the viewport, there are lots of way to accomplish this using the API - example here which I found useful: polyline snap to road using google maps api v3
Also useful: http://econym.org.uk/gmap/snap.htm
Note that one way streets may give some grief if using the directions api to snap to a street and you will likely have to watch for this and correct or reverse the start/end points.
Google would recommend using it's Geocoding Service in order to populate your data base with the co-ordinates. You can then use the LatLng Bounds Class method "contains" to check whether your points lie within the viewport. The advantage of this approach is you only need to geocode the information once and then store this, versus sending coding requests each time the viewport changes.
An alternate efficient way of displaying this kind of data may be to use google fusion tables. this greatly simplifies the integration of the data with the map.
I am asking the same question on Google's product forum, so excuse me if you see the same question.
I am using Street View Service to develop my application that is similar to this example (figure above). In this application, I want to store where, in lat/lng coordinates, users have traveled on the map. I figured out StreetViewPanorama class provides an API, getPosition(), and this returns LatLng. Lat/lng coordinates you extract from LatLng object look like lat=38.924066 and lng=-77.032172. I can use these values to store what I want.
Although the aforementioned latlng values have 8 significant figures, I was actually wondering how accurate these values are, because GPS locations that Google collects while running a Street View car would have errors.
So my question is, how accurate is the latlng value returned by getPosition()? In other words, how much concordance can I expect between latlng values from getPosition() and latlng position on Google Map?
Thank you very much!
I got an answer in another forum so I copy it over here too and mark the question as solved. The following is the answer from barryhunter in Google Forum.
A 6dp lat/long is on the order of precise to 0.1m. (ie 10cm)
So such a lat/long should match up very precisely with the Google Map.
Ie its a precise location.
But as to how accurate the underlying map is, that varies a lot. Its
almost impossible to tell. Most locations I would estimate to be
within about 6-30m
You can check the accuracy of a lat or a lng value with 6 decimal points in the following page:
http://nearby.org.uk/precision-ll.cgi?lat=38.924066&long=-77.032172
As indicated in the above answer, the real limitation is the positioning of the map, not the numerical value obtained from it.
For example, I happened to be taking readings at a location where two Google Map sections overlapped. There was an obvious discontinuity in color and terrain features when going from one to the other. The photos must have been taken at least a year apart.
A marker placed on one side of this overlap jumped by at least 10 m when viewed on the other overlapping section. In other words, one (or both) map sections were off by at least a few meters relative to the true GPS coordinates.
If you are lucky enough to be working on a single section, distances between map points are probably quite accurate, but if you check a point against the actual GPS coordinate on the ground, who knows? A bias error of 6-30m seems likely to me.