User:LA2/Diary for Q2 2005

LA2's OpenStreetMap Diary for the 2nd Quarter of 2005

June 23, 2005: Added a GPX file for motorway E4 between Linköping and Jönköping.

May 28, 2005: I release my seven GPX files from the Linköping region into the public domain (download).

I used gnuplot to display my track log rydsskogen.gpx (from May 24, see below) with dots and with lines. The dots version looks like the OSM editing applet, where the user is supposed to connect the dots with lines. See also this enlargement of a part where two laps in the jogging track runs next to a bike lane. Applying the same method on all seven of my GPX files gives a result in a fraction of a second that is very similar to the carefully hand-drawn map I made with the OSM applet. Applied to Petter Reinholdtsen's richer track logs from Oslo, this kind of map clearly shows the difference between more and less used streets. I used these Linux commands to generate the graphs:

sed '/^<trkpt/!d;s/.*lat="\(.*\)" lon="\(.*\)">/\2 \1/' <rydsskogen.gpx >rydsskogen.plot
cat *.gpx | sed '/^<trkpt/!d;s/.*lat="\(.*\)" lon="\(.*\)">/\2 \1/' >all.plot
gnuplot
set terminal png
set output "rydsskogen-dots.png"
plot [15.56:15.60] [58.405:58.425] "rydsskogen.plot"
set output "rydsskogen-lines.png"
plot [15.56:15.60] [58.405:58.425] "rydsskogen.plot" with lines
set output "rydsskogen-tracks.png"
plot [15.582:15.5855] [58.412:58.414] "rydsskogen.plot" with lines
set output "all.png"
plot [15:15.7] [58.3:58.55] "all.plot" with lines
set output "oslo.png"
plot [10.77:10.79] [59.94:59.948] "jm-2004-09.plot" w l, "jm-2004-10.plot" w l, "jm-2004-11.plot" w l

May 27, 2005: Some thoughts: (1) Where are the maps? -- Somebody apparently started to map the city Nafplio in Greece, but there is a lot more track data available (go to the map, click "edit this map", then wait 20 seconds to see all the gray track points) than has currently been used for the drawn map. How can I tell if somebody is working on this, or if they want help with drawing the map? How can I find other spots where there are track logs waiting to be drawn into maps?

The long wait before the track points appear might scare new contributors away. It happens where there are very many track points, as is described below. The more track points (larger the area, smaller scale), the longer it takes.

(2) Sample reduction at load time -- It seems that the current OSM software has a problem in editing maps where there are too many track points in one place. Perhaps this is due to some software bug that is easy to fix, after which it becomes easy to handle larger numbers of track points. But a different approach is to reduce the number of track points. It is in fact easy to generate too many unnecessary track points if the GPS receiver uses a fixed sampling interval (one sample every second or every 3 seconds) and then to stand still in one point. It would be easy to filter out such duplicates when the GPX file is loaded into the database. In fact, the Garmin receiver that I'm using has a setting for "auto" interval, which means the receiver filters out all points that can be easily computed through interpolation and only saves many track points where the speed and/or direction changes. Since a timestamp is saved with every sample, this is the GPS version of "run length encoding".

Let's expand this problem. Suppose two different users, A and B, have different opinions on the coordinates of a street. User A stores one samples per second, while B stores one sample for every 3 seconds.

 A ----O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O----
 :
 B -------O--------O--------O--------O--------O--------O-------

The map maker in OpenStreetMap as of May 26, 2005 sees only the samples, not the tracks they belong to. She cannot tell if this is two tracks A and B with different sample interval, or four tracks, all with the same interval: A1, A2, A3 which all coincide and B that disagrees. She is likely to assume the latter, and treat this as vote where the A track wins. This is unfair, of course. Each track should be given an equal chance in the voting. The root of the problem is that OpenStreetMap handles samples and not tracks. One way to solve this is to mandate that everybody use a fix sampling interval of 1 second, but mandating such policies is boring. Another way is to interpolate the missing samples when the GPX file is loaded into the database. This way, the 6 samples from B would be expanded to 18, just as many as A has. Apparently, this method has the drawback of overburdening the database with too many trivial track points. As if we didn't have too many already. The third and preferred method would be to reduce the number of samples in both A's and B's track down to the essential, perhaps 3 samples each.

May 27, 2005: With some longer roads drawn, it is now possible to spot London, Oslo, parts of Sweden and Greece on the same map (center 50N,10E scale 1:25.000.000). The rest of Europe is blank.

May 26, 2005: I went driving again for some more streets. Then I modified my old Swedish wiki susning.nu so that it links not only to MapQuest and MultiMap for pages that have geo coordinates, but also to OpenStreetMap. See for example the pages on Trondheim, Manhattan, and Linköping. In my following trips I tried to set the Garmin to a fixed sampling interval of 2 or 3 seconds. This generates a lot of data points, too many really, especially when I'm standing still. Added geography includes Mjölby, Skänninge and Vikingstad, three smaller communities west of Linköping. The contours of central Östergötland are starting to appear.

May 25, 2005: I went driving and mapped some major streets in Linköping. Problem is, the only difference between 110 km/h motorways, 70 km/h throughfares, 50 km/h city streets, 20 km/h bike lanes, 12 km/h jogging tracks, and 5 km/h walk paths is their curve smoothness. The resulting map is just a mesh of thin black lines. There is also no way to tell a street crossing apart from a bike bridge leading over a motorway.

May 24, 2005: I borrowed a friend's Garmin Foretrex 201. This is a fine unit, and I think I'll buy one for myself. I set it to the "auto" sample interval, left home, bicycled three blocks to my local forrest, ran the 5 km jogging track, walked-and-ran the partly overlapping 2.5 km jogging track, then bicycled around some bike trails in and around the forrest, and then bicycled home again. This tour of 90 mintues gave me 397 points, for an average sampling interval of 13.6 seconds. To download the track log to my Linux box, I used the GPSBabel open source software version 1.2.5 (gpsbabel -t -i garmin -o gpx -f /dev/ttyS1 -F mytrack.gpx). I uploaded the GPX track log to the Open Street Map site. When I edit the map, I see a lot of dots, and have to connect them. They seem to be fewer than when I pan-and-zoom the track on the Garmin, so maybe OSM filtered out some of the points? It is now very hard to see which dots belong to which jogging track, and which belong to the bike trails. The timestamp/sequence that connected one point to the next is gone. Also gone is the time/speed/direction information that could have told me which dots were walked at 5 km/h, which were jogged at 12 km/h and which were bicycled at 20 km/h. In order to get lines on the map, I have to spend much time and effort to again connect the dots whose connections were broken by the OSM site. Even if I connect all the dots, the server software doesn't allow me to indicate which line segmens belong to which of the two jogging tracks. My 90 minutes in the forrest were well spent, and I have a fine GPX file recording of it. However, the OSM server software could easily be improved to make the map-making far more efficient than it is today.