# LA2's OpenStreetMap Diary for the 3rd Quarter of 2005

August 28, 2005: The new map editing applet is out. But does it work? And how?

August 16, 2005: Have you heard that Ben has "reimported Manhattan in a more efficient way"? I love this phrase. This could only happen on OSM! First we take Manhattan (40.78,-73.96, OSM map, g, mq, mm, wll, what?), then we take Berlin (52.52,13.37, OSM map, g, mq, mm, wll, what?)!

I'm disturbed by the fact that my Garmin GPS starts to store tracklog points before accuracy has been reached. Perhaps it is possible to process the GPX files before they are used in applications such as OSM. Looking at the beginning of a typical track segment (trkseg), the track points are:

(time)      (lat)     (long)   (elev.)   time  distance    speed    climb
1125590257  58.41562  15.64301   52.05
1125590265  58.41115  15.62546   52.05    +8    559.97     70.00   +0.00
1125590276  58.41096  15.62479   52.05   +11     24.21      2.20   +0.00
1125590287  58.41094  15.62445   52.05   +11      2.63      0.24   +0.00
1125590294  58.41092  15.62391   52.05    +7      2.76      0.39   +0.00
1125590321  58.41070  15.62206   52.05   +27     26.84      0.99   +0.00
1125590332  58.41059  15.62127   53.01   +11     13.55      1.23   +0.96

Here the first sample is in error, 560 meters away from the following samples, giving the initial speed of 70 m/sec (252 km/h) which is immediately reduced to 2 m/sec (would you survive that?). Let's look at the beginning of another track segment:

(time)      (lat)     (long)   (elev.)   time  distance    speed    climb
1126208136  56.04798  13.27376 11653.24
1126208145  56.05456  13.36062 11653.24    +9    838.48     93.16   +0.00
1126208164  56.08802  13.40379 11653.24   +19   4257.02    224.05   +0.00
1126208181  56.11791  13.44252 11657.08   +17   3803.11    223.71   +3.84
1126208200  56.15125  13.48615 11659.49   +19   4241.75    223.25   +2.40
1126208216  56.17940  13.52286 11659.49   +16   3580.48    223.78   +0.00
1126208228  56.20052  13.55039 11662.85   +12   2685.08    223.76   +3.37
1126208243  56.22689  13.58481 11667.18   +15   3352.97    223.53   +4.33
1126208261  56.25852  13.62618 11668.62   +18   4020.78    223.38   +1.44

Here we are flying 11.6 km above the sea level and the speed of 223 m/sec (800 km/h) is normal. But the first sample is in error, giving the first speed report at only 93 m/sec. Instead of a fixed threshold (speed must be less than 200 m/sec), perhaps a low-pass filter is needed. A third example:

(time)      (lat)     (long)    (elev.)  time  distance    speed   climb
1126215217  58.78449  16.92182   60.22
1126215222  58.78449  16.92184   42.92    +5      0.09      0.02  -17.30
1126215261  58.78422  16.92188   48.20   +39     34.92      0.90   +5.29
1126215267  58.78422  16.92180   48.68    +6      0.00      0.00   +0.48
1126215277  58.78422  16.92148   48.68   +10      0.00      0.00   +0.00
1126215281  58.78417  16.92135   48.68    +4      5.26      1.31   +0.00
1126215284  58.78409  16.92141   49.16    +3     10.76      3.59   +0.48
1126215287  58.78400  16.92161   49.16    +3     10.76      3.59   +0.00

Here the speed is low and normal from the start, but the elevation changes a lot in the first samples. Apparently we have a 2D fix and not yet a 3D fix. The first two samples should be discarded. After that the values are fine. Perhaps it is a good enough policy always to discard the first two samples? In this case, the elapsed time 39 seconds between the 2nd and 3rd sample is perhaps also a sign of warning (unless the speed is zero).

I dont like the idea of discarding the two first sample. I usually have tracking turned off and when I turn it on I make sure that accuracy has been reached. If the two first sampels are removed it is not known how much of the track that is removed, it depends on what kind of method you are using in the GPS to track (auto, time or distance). Do we know how other GPSes do (Magellan, Silva, ...), so they start tracking before accuracy has been reached. Do all Garmin GPSes do the same. I think some kind of sanity check should be done and only discarding samples if they seems to be invalid. /Ka-Ka

Lesson learned: acos(1.00001) is not-a-number, so better check for rounding errors.

August 15, 2005: Altea and Madrid seem to be the first mapped spots in Spain. Novara in Italy, Prague in the Czech Republic and Lausanne in Switzerland.

August 12, 2005: Did I tell you I love stats?

August 9, 2005: I upload the tracklog from my trip to the Wikimania conference in Frankfurt/Main, Germany, including the Ryanair trip back from Hahn to Skavsta. Someone else has added another tracklog in southwestern Germany (along A61?).

August 4-8, 2005: At the Wikimania conference in Frankfurt am Main, one of my main interests were mapping. I should point out that the following notes are my own very personal impressions and opinions, which is why I post them here on my user page. During my stay in Frankfurt I was able to locate four geocaches. And over lunch one day I learned that keynote speaker Ward Cunningham is both a geocacher and a degree confluence hunter.

• In his opening speech, Wikipedia founder Jimbo Wales laid out a plan for ten things he wants to make free (as in free speech) in the following decade. The first, of course, was the encyclopedia. One of the other points was maps. The audience suggested another seven points to the list, and no priorities were given.
• One paper presentation by Russell Buckley had the enigmatic title Extending Wikipedia into the Physical World. After five minutes, this appeared to pertain to cell phone access to today's Wikipedia, and not to mapping, so I left for a parallel session.
• Arnulf Christl presented a workshop titled Summarizing Activities around Open Geospatial Data projects. He is the organizer of Mapbender.org and has been posting on the OSM mailing list, so this was obviously going to be very interesting. However, the workshop turned out to be somewhat of a culture clash. Arnulf is very knowledgeable in Geographic Information Systems (GIS) and is frustrated with the anti-authoritarian (amateurish) culture in the Wikipedia community. Despite his youth and his own efforts for free GIS, he appeared like an old-school opponent, almost like "the public toilet guy" (this expression refers to former Britannica editor in chief Robert McHenry, who called Wikipedia "The Faith-Based Encyclopedia"). A lot of valuable free GIS tools and data are available, and Arnulf knows where they are and how they work. His Mapbender website demonstrates an excellent way to connect them. What he doesn't grasp yet is the way to address the Wikipedia crowd. He expected to see hundreds of developers, and was surprised to learn that they are only a handful. Wikipedia is not a tech project, but thousands of people who write encyclopedic articles, supported by a few very simple technologies. The real challenge that he faces is to boil down all his GIS knowledge to something simple enough for this crowd. Right now Mapbender would seem to average wikipedians like a jetliner cockpit to drivers who cannot even handle a manual stickshift. He mentioned that he had tried to push Google to build something similar to Mapbender, but to his frustration they had instead built the monolithic Google Maps.
The main difference is that Mapbender only provides the connection between mapping data sources; it is a "bender" and the maps come from elsewhere. Mapbender emits pages with JavaScript and the end user's browser retrieves the actual map layers from the mapping sources. To Arnulf this has advantages both in server load (the Mapbender.org website only provides a small fraction of the web traffic to the end user's browser) and in copyright (Mapbender.org doesn't redistribute the data, only the URLs to it). Unfortunately, this is a non-solution both to Wikipedia and Google. First, if Wikipedia or Google were to use a similar technique, the enormous amounts of web traffic would threaten the data sources with a "Slashdot effect" which some of them wouldn't survive. Second, if parts of the data isn't really free (as in speech), it won't do for Wikipedia. It needs to be there next year too, and it should be possible to print and redistribute on DVD. I guess Google has come to a similar conclusion: They have no problem with hosting the huge server load themselves, but they would have a problem with relying on cost-free third party sources that might go away.
• From Switzerland, Tobias Dahinden gave a workshop in German on Kartengestaltung in Wikipedia - eine Aufforderung für bildschirmgerechte Kartengraphik (Map drawing in Wikipedia - a call for correct mapping on screen). He had been looking at the large number of maps already in Wikipedia, mostly as JPEG images, and identified some easy ways to improve them. He displayed various mistakes that automated GIS software typically make, and where a human experience in map making is called for. He also demonstrated, somewhat unrelated, how GIS data can be collected by GPS, where he plotted track log points on top of an existing street map, showing how inaccurate samples deviated more or less from the given road. Perhaps the line maps produced by OSM could be used in this way? When one person in the audience mentioned that an art project in Amsterdam had demonstrated GPS sampling a few years ago (meaning Amsterdam Realtime -- User:Sxpert: could we get their data ? -- 2005-08-12 email sent), I finally got the chance to mention and briefly demonstrate openstreetmap.org at the very end of the workshop.

July 25, 2005: Testing a wiki template:city, useful for entries in a list like the one below. But where should this list be stored? -> See Gazetteer section, above.

July 24, 2005: When adding points and lines, the current ("pre-pre alpha") map editing applet works pretty good, except that it is ugly and user-unfriendly. But when it comes to moving and removing points and lines, it has some very annoying bugs. I've never got the unlink button to work. The only way to remove lines seems to be to remove points. You would believe that removing one point would remove all lines connecting to it. And it looks that way in the editing applet. But the map viewer still displays the lines, until both end points of the line are removed. This makes it virtually impossible to remove one line segment in the middle of a long track. Moving a point at first seems to work OK, but when you zoom and pan around inside the edit applet, the point appears and reappears both at the old and new position, especially when an end point of a line segment falls outside of the current display. Closing the applet (browser's back button) and restarting it (edit link) doesn't clean up this mess, so apparently the double positions are stored in the server. For example, how do you clean up a mess like this?

July 22, 2005: Tel Aviv. It also appears that User:Sxpert has uploaded track logs from last year, passing (in Norway) Oslo, Moss, (in Sweden) Strömstad, Tanum, Munkedal, Vänersborg, Uddevalla, Stenungsund, Kungälv, Göteborg, Kungsbacka, Varberg, Falkenberg, Halmstad, Ängelholm, Helsingborg, Landskrona, Malmö, (in Denmark) Copenhagen, Rødby, (in Germany) Puttgarden, Lübeck, Bremen, Osnabrück, (in the Netherlands) Meppen, Utrecht, S-Hertogenbosch, Eindhoven, (in Belgium) Gent, Liège, (in Luxemburg) Luxembourg, (in France) Thionville, Metz, Nancy, Lyon, Valence, Avignon.

July 19, 2005: Helsinki. This means the Finns have found OSM and will soon dominate the scene, as they tend to do.

July 13-15, 2005: Oops, OSM goes through a major facelift with (1) roads drawn as white lines with black borders, (2) NASA satellite backdrop images, and (3) scales that have to be recomputed (new scale = old scale * 3.0e-9). All links on this page have been updated.

July 8, 2005: I upload a track that connects, at Norrköping, my map with that of Sxpert.

July 5, 2005: User:Sxpert has uploaded a long track that goes from France (Grenoble, Lyon, Auxerre, Paris, Cambrai), through Belgium (Nivelles, Bruxelles, Antwerpen), the Netherlands (Middelburg, Rotterdam, The Hague, Amsterdam, Groningen), Germany (Oldenburg, Bremen, Hamburg), Denmark (Esbjerg, Billund, Skjern, Århus, Odense, Korsør, Copenhagen), along the east coast of Sweden (Malmö, Simrishamn, Ronneby, Kalmar, Oskarshamn, Söderköping, Norrköping, Nyköping, Södertälje, Stockholm, Norrtälje, Gävle, Söderhamn, Hudiksvall, Sundsvall, Timrå, Härnösand, Örnsköldsvik, Umeå, Luleå, Haparanda), east into Finland (Rovaniemi) and further north to Norway (Kirkenes and almost to Nordkap). I helped to map parts of this track. The map of north-western Europe is no longer just a few dots (London, Oslo, Trondheim, Linköping), but some long contour lines are starting to appear. It is still impossible to tell which road is which.