I have a Ublox NEO-6M and NEO-N8M, both ordered from China (possibly foreshadowing?).
When I wired the N8M up, it gave me a location in the middle of a lake 30 miles away. For context, I am in South Africa in the southern hemisphere.
I drove around logging two other locations, assuming it could be calibrated with a fixed point error by getting a fixed location reading and subtracting the real coordinates, and using that offset in future calculations.
It didn't work, the inaccuracy was too great, however a lot better, but obviously, it was not the solution.
I then used the 6M. To my absolute surprise, it gave me the exact same location as the first module, exactly in the middle of that same lake. So at this point, I'm starting to wonder, could this be related to the hemisphere? Is it the fact that it could be counterfeit?
The N8M used $GNGLL and the 6M used $GPGLL so I doubt it's a discrepancy with the GPS and GLONASS systems.
Any help would be appreciated, all I want is a really accurate fix on my location.
I stumbled the same way (~30 miles away) until re-reading the NMEA Protocol and realising that it was my fault. So maybe this may help you as well:
The format in the sentence for lat is ddmm.mmmm and for lon it is dddmm.mmmm so you have to do some calculations on your own:
Separate the (d)egrees and the (m)inutes. Divide minutes by 60.0 and add them to the degrees. Voila - you have your correct lat and lon.
Related
I have two identical gps modules running the same program with antennas side by side. I get different results. I don't understand why
One example is 4211.41545 from the first unit and 4211.41481 from the second the timestamp is the same.
You don't say what the values you quote are so I will assume that the value you are showing is the Lat or Long value from the NMEA output data. If this is the case then the difference between the values is 0.00064 minutes of arc. The maximum physical distance that this will represent is around 1.1 metres (along a great circle). At 60 degrees north this would correspond to around 55cm in an E/W direction.
You do not say how far apart the antennae are or whether there are any obstructions above the level of their horizons which will introduce varying multipath signals that will be different for the two antennae. The two receivers will not necessarily be sampling the satellite signals at the same instants and so can have marginally different signal timings resulting in a different position result.
A typical consumer grade GPS will have a CEP figure of 2.5 metres meaning that 50% of the values for position in an unobstructed sky view position will lie within a 2.5 metre radius circle of the true position.
Taking this into account you should not expect any two adjacent GPS devices to give identical results.
I am working on project that get the longitude and latitude and it is everywhere, but I need to get the error estimation at least to draw a circle around my GPS point. How i can find this error in eclipse.
It is known that the total Potential error is around 15 m and the total Typical error is around 10 m. Do i need the average deviation to find the error?
I just need to know how to find the accuracy of my GPS and what values can i fetch using Eclipse?
Thanks alot.
Not sure about your "eclipse" As far as GPS error, there are some things to consider...
Some receivers can output a NMEA GST message with includes error estimates.
You can watch GDOP and HDOP values to get an idea as well as number of satellites tracked.
Assuming a GDOP < 6 and an HDOP <3 with more then 4 tracked satellites you should achieve the receivers specified RMS accuracy.
Another, more complicated method, which should be the basis for the results in then mentioned GST message is Range Residuals. Advanced receivers may output these RRE measurements for each satellite. Using this information you can even detect errors such as multipath, and RF interference. RRE values tell how well a satellites range measurements match the resolved position result.
Im trying to analyse data from cycle accidents in the UK to find statistical black spots. Here is the example of the data from another website. http://www.cycleinjury.co.uk/map
I am currently using SQLite to ~100k store lat / lon locations. I want to group nearby locations together. This task is called cluster analysis.
I would like simplify the dataset by ignoring isolated incidents and instead only showing the origin of clusters where more than one accident have taken place in a small area.
There are 3 problems I need to overcome.
Performance - How do I ensure finding nearby points is quick. Should I use SQLite's implementation of an R-Tree for example?
Chains - How do I avoid picking up chains of nearby points?
Density - How to take cycle population density into account? There is a far greater population density of cyclist in london then say Bristol, therefore there appears to be a greater number of backstops in London.
I would like to avoid 'chain' scenarios like this:
Instead I would like to find clusters:
London screenshot (I hand drew some clusters)...
Bristol screenshot - Much lower density - the same program ran over this area might not find any blackspots if relative density was not taken into account.
Any pointers would be great!
Well, your problem description reads exactly like the DBSCAN clustering algorithm (Wikipedia). It avoids chain effects in the sense that it requires them to be at least minPts objects.
As for the differences in densities across, that is what OPTICS (Wikipedia) is supposed do solve. You may need to use a different way of extracting clusters though.
Well, ok, maybe not 100% - you maybe want to have single hotspots, not areas that are "density connected". When thinking of an OPTICS plot, I figure you are only interested in small but deep valleys, not in large valleys. You could probably use the OPTICS plot an scan for local minima of "at least 10 accidents".
Update: Thanks for the pointer to the data set. It's really interesting. So I did not filter it down to cyclists, but right now I'm using all 1.2 million records with coordinates. I've fed them into ELKI for analysis, because it's really fast, and it actually can use the geodetic distance (i.e. on latitude and longitude) instead of Euclidean distance, to avoid bias. I've enabled the R*-tree index with STR bulk loading, because that is supposed to help to get the runtime down a lot. I'm running OPTICS with Xi=.1, epsilon=1 (km) and minPts=100 (looking for large clusters only). Runtime was around 11 Minutes, not too bad. The OPTICS plot of course would be 1.2 million pixels wide, so it's not really good for full visualization anymore. Given the huge threshold, it identified 18 clusters with 100-200 instances each. I'll try to visualize these clusters next. But definitely try a lower minPts for your experiments.
So here are the major clusters found:
51.690713 -0.045545 a crossing on A10 north of London just past M25
51.477804 -0.404462 "Waggoners Roundabout"
51.690713 -0.045545 "Halton Cross Roundabout" or the crossing south of it
51.436707 -0.499702 Fork of A30 and A308 Staines By-Pass
53.556186 -2.489059 M61 exit to A58, North-West of Manchester
55.170139 -1.532917 A189, North Seaton Roundabout
55.067229 -1.577334 A189 and A19, just south of this, a four lane roundabout.
51.570594 -0.096159 Manour House, Picadilly Line
53.477601 -1.152863 M18 and A1(M)
53.091369 -0.789684 A1, A17 and A46, a complex construct with roundabouts on both sides of A1.
52.949281 -0.97896 A52 and A46
50.659544 -1.15251 Isle of Wight, Sandown.
...
Note, these are just random points taken from the clusters. It may be sensible to compute e.g. cluster center and radius instead, but I didn't do that. I just wanted to get a glimpse of that data set, and it looks interesting.
Here are some screenshots, with minPts=50, epsilon=0.1, xi=0.02:
Notice that with OPTICS, clusters can be hierarchical. Here is a detail:
First, your example is quite misleading. You have two different sets of data, and you don't control the data. If it appears in a chain, then you will get a chain out.
This problem is not exactly suitable for a database. You'll have to write code or find a package that implements this algorithm on your platform.
There are many different clustering algorithms. One, k-means, is an iterative algorithm where you look for a fixed number of clusters. k-means requires a few complete scans of the data, and voila, you have your clusters. Indexes are not particularly helpful.
Another, which is usually appropriate on slightly smaller data sets, is hierarchical clustering -- you put the two closest things together, and then build the clusters. An index might be helpful here.
I recommend though that you peruse a site such as kdnuggets in order to see what software -- free and otherwise -- is available.
I have a requirement to calculate the lat and long values of the current position of the user. However, I can't use GPS/Network. I know a previous lat long location of the user. This previous location has been queried from the GPS provider. After this initial location is found, GPS is no more available. User travels a certain distance from this point and in certain direction. Both these values, distance and direction of travel (in terms of angle), are known. Is there any way that I can arrive at the new lat/long coordinates based on this available information (previous lat/long coordinates, distance & direction traveled from the previous position).
This method of navigation is known as dead reckoning: Given is an initial position, the task is to deduce the current position from known information, e.g. heading, time travelled, and speed (or heading and distance).
You may find some formulas to compote the new location here.
Stefan gives you a good place to start. However, depending on what you want to do with that information, you might be better to use a Kalman Filter, which would allow you to account for error in both the starting position, distance traveled and direction traveled. This is especially true if the user is isn't moving just once, but several times.
This link GeoTools - How to do Dead Reckoning and course calculations using GeoTools classes answers my question. Given an angle, distance and starting geographic point, GeoTools (java) can be used to do the calculation. Refer to the SO link to see the sample.
I have a range defined by an intersection and a number of feet away from the intersection. (e.g. 100 ft north of Washington St. & 5th St. to 300 ft south of Washington St. & 6th St.)
I am looking to geocode this into a lat/long pair. However, I cannot see any way to get Google Maps API or Virtual Earth, etc. to do this. They will happily geocode the intersection, but not the distance away. I can't just add 100 ft because the road doesn't necessarily go exactly straight or exactly in a cardinal direction.
I investigated getting the polyline that describes the road, but am not having much luck with obtaining that either from Google/VEarth. I looked at TIGER/LINE from the US Census but their data is very inaccurate.
Can anyone make a suggestion for how to geocode this? This is for a public map, so any of the free APIs from Google, Microsoft, etc. should be fine.
Ultimately, by the way, I'm looking for an actual street address rather than coordinates. I want to know that the range in the example I gave above, for instance, would be 508 to 563 Washington St.
Food for thought - I don't know what your application is but remember the accuracy of a typical GPS device is 10 meters (approx 33 feet). Is it possible you are trying to make this more precise than necessary?
Possible solutions
Can you just add the 100 feet and project that point perpendicular to the road? Close enough?
Grab the intersection. Traverse the first segment. If its length < 100 feet, grab the scond segment, and so on until you are 100 feet away from the intersection as measured along the road. You will need to add the appropriate checks / do some math to determine where along a segment the actual 100' mark falls.
I used the second method over the summer and will see if I can find some sample code. No promises though.
#3 - Grab the intersection. Get the bearing of the first segment and use coordinate geometry to calculate the point 100 feet along the street at a given angle. This assumes the street does not have any deflections in it, otherwise use #2.
I ended up taking a different approach -- rather than geocoding to house numbers, I use percentage up the street. I can therefore get away with calculating the length of the street and then determining how far up the street the geocoded coordinates are.