How is track data processed and who should I record it?

Tony_Q · 2007-03-26T10:13:51.000Z

I’m new to this game, but I have a couple of questions about the data that we upload.

Since GPS isn’t completely accurate, the tracks we record aren’t either. Indeed you can see that if you plot the track back onto something like Google Earth. For example, I drove out along a dual carriageway, round a loop, and then back along the same dual carriageway. Looking at the track, the two carriageways cross over each other halfway along which clearly isn’t right. How is this sorted out when put into the openstreetmap data? Do I have to do it manually?
I suppose related to the above, should I deliberately record multiple tracks down the same road, to average out the GPS error?
Is there any guidance on collecting track data? Some of the tools allow some control on the amount of data collected - things like time/distance between points. Should I be concerned about this, or do I just let it “do its own thing”? (I’m currently using VisualGPSce but I’m toying with buying a copy of Beeline from the same folk. I then munge the NMEA data to GPX using Gebabbel. The GPS is an HP iPaq rx5930 travel companion.
Once I’ve uploaded a track, what happens then? I think that once it appears, I go back an edit in things like street names. Is that right?

Sorry for asking dumb questions, but I’m just getting started on this, and there doesn’t seem to be any guidance that I can see …

T

DaveL · 2007-03-26T10:30:44.000Z

The answers to 1,2 and 4 are closely related.

Your uploaded tracks will appear as a series of points. It is up to you (and every other mapper) to create a series of lines on top of those dots to represent a roadway with one of a selection of editors. Joining those lines together, and adding properties (such as road names) completes the interpretation of the GPS track to a road on the OSM map. Provided you have enough GPS data (and trust in that data!) to make the lines, there should be no need to gather multiple tracks for the same road.

I think question 3 sounds a bit more personal. There is obviously a compromise to be made between the frequency of track points you allow your device to collect and the storage capacity of that device. See what works best for you.

eg My device can store 10,000 points. In the car, I typically let it record at one point per second to give something approaching 3 hours of data. When travelling much slower (on the pushbike), the device records at one point every 3 seconds, so I can wait longer before transfering data to the PC. I am sure every mapper has their own ideas about all that.

Ben · 2007-03-27T13:59:43.000Z

If your just getting started and want to know the very basics you can check here http://wiki.openstreetmap.org/index.php/Beginners_Guide

The amount of points per second can vary, depending on what you trying to map more than how fast you travel. i.e. on a canal barge There is very little to map that would only be posible to make on in a trace recorded at 1 point per second, but If going on foot but mapping in high detail rather than just mapping a road on foot, then 1 point per second is again helpful.

Having more points per second also makes the data more readable. Its surprising what you learn to make out from a string of dots. Also if you loose reception for a few seconds and have it logging points more frequently then the data is still ok for mapping with.

In short, I would suggest recording at 1 point per second for most things. On motorways and other already heavily mapped routes I would suggest lowering the amount just so that the dots can be better used on other roads. The density of points should corralte to the density of things you add to the map I find.

For Q2) I would say yes. I find a route that has been travelled about 7 times seems to have all the data nessesery to map acuratly

Lambertus · 2007-03-27T14:10:35.000Z

Ben:

In short, I would suggest recording at 1 point per second for most things. On motorways and other already heavily mapped routes I would suggest lowering the amount just so that the dots can be better used on other roads. The density of points should corralte to the density of things you add to the map I find.

Definitely true, but I would like to make a small comment:
If you plan to track all day and your tracklog does not have enough space to store a point every second then it might be a good idea to set the loginterval to 2, 3 or even more seconds. I say this because my Garmin can log 10.000 points per tracklog which is ~3 hours.

When I save the tracklog in order to clear the current log it will compress the old tracklog to only 500 points, which is in most circumstances way to few to be accurate (I lost valuable data before I found out what happened). Therefore I can do only 3 hours of tracking before I have to find a computer again. So if I’m going further away I will set the interval to something that is quick enough to be accurate, but slow enough to last the entire trip.

Edit: Just found out that (with a Garmin GPSMap 60CSx) if you enable ‘Log track on memory card’ then you can simply delete the current tracklog when it’s nearly full, because the track is also logged on the microSD memory card. A 64 MB SD card can hold probably weeks of tracklog data…

bruce89 · 2007-03-29T20:53:26.000Z

I personally use 0.5Hz (2 seconds), as this seems the best mix of space and density.

Lambertus:

Edit: Just found out that (with a Garmin GPSMap 60CSx) if you enable ‘Log track on memory card’ then you can simply delete the current tracklog when it’s nearly full, because the track is also logged on the microSD memory card. A 64 MB SD card can hold probably weeks of tracklog data…

I never thought of that, might be useful. I wonder if the internal tracklog becomes full, the external card log also stops/wraps.

Lambertus · 2007-03-29T21:06:04.000Z

bruce89:

I personally use 0.5Hz (2 seconds), as this seems the best mix of space and density.

Lambertus:

Edit: Just found out that (with a Garmin GPSMap 60CSx) if you enable ‘Log track on memory card’ then you can simply delete the current tracklog when it’s nearly full, because the track is also logged on the microSD memory card. A 64 MB SD card can hold probably weeks of tracklog data…

I never thought of that, might be useful. I wonder if the internal tracklog becomes full, the external card log also stops/wraps.

Unfortunately I have had that situation once where I had forgotten to clear the tracklog before leaving Anyway, the result was that logging stops completely when the tracklog is full, so no further logging to the microSD card either… That is something to be weary about.

EdP · 2007-06-15T18:43:11.000Z

As another newbie, I found this a useful thread. I’d like to throw in a follow-up to question 1.

Sometimes due to a spurious signal/battery problem or other glitch, one or more gpx points is obviously wrong. Other than laboriously ploughing through the xml statements; is there an easy way of deleting bad points (ideally with a GUI interface)?

Or are the gpx points gathered only as a means of proving the (finally) plotted tracks are copyright free? Is it a waste of time to try to edit out bad gpx data?

Ed

Lambertus · 2007-06-15T18:54:55.000Z

EdP:

Sometimes due to a spurious signal/battery problem or other glitch, one or more gpx points is obviously wrong. Other than laboriously ploughing through the xml statements; is there an easy way of deleting bad points (ideally with a GUI interface)?

If you have Garmin unit then it probably came with the MapSource application which is usable to remove any obviously erroneous points. Perhaps GPSBabel when using the

-x discard,hdop=4

parameters is usable for this as well. OSM has some more info on GPSBabel.

Or are the gpx points gathered only as a means of proving the (finally) plotted tracks are copyright free? Is it a waste of time to try to edit out bad gpx data?

That is only part of use of the tracklogs. Multiple track of the same roads are also used to determine the position of those roads more accurately: The more tracks of the same roads are available the easier it is to identify and ignore inaccurate tracks.

Ben · 2007-06-16T22:42:50.000Z

Usually bad data comes in the same spots on the repeated route. Its best to just add them, unless they data is particually bad, becuase then the way can average all the points, rather than just go on nothing.

I imagin that it won’t be long before admin tools allow the removal of specific dots/areas, to stop rubish having to be hunted down, and then the whole gpx file removed.