Data collection when you travel at high speeds

From OpenStreetMap Wiki
(Redirected from High Speed Mapping)
Jump to navigation Jump to search

What is "high speed mapping" and why would we want it

In parts of North America there are fairly large distances between towns, often filled with smaller "farm roads" in-between. In some situations it is not practical to stop and photograph/waypoint each sign post. It may also be useful for recording/confirming the lane structure of motorways/freeways.

At any significant speed the data is not going to be geo-locationally correct, at 120 km/h you're traveling 33 m every second. The location that your GPS outputs might be delayed, and there are pretty significant issues in getting synchronization between recorded (audio or photo) data and GPS track log.

However, if you're just trying to tag roads traced from other sources such as aerial photography, this idea might just work.

Safety

If you don't realise that you should be safe whilst driving, please shred your driving license now and do us all a favour!

Photo mapping isn't a very safe thing to attempt while driving. If you're the passenger, this can work well. This really depends on road conditions. It will be safe in some situations, and not in others.

Audio mapping seems like the most practical solution while driving. Use a voice recorder (or PC/Laptop doing the same) and then to relate this to the GPS track log afterwards. There is support for audio recording in JOSM, which can handle either short snippets of audio or a long recording lasting the length of the track.

Use short and descriptive comments

Main article: Data_collection_using_short_descriptive_comments#Examples

You should try to start your comment at the point of intersection of the feature, that way the timestamp will be as close as possible. As mentioned these positions are not going to be spot on, but will be close enough to identify features.

The solution?

The basic idea is to use Manauton to automatically record separate sound files at each point (with encoded click track/time stamp) using it's autonomous mode which triggers on sound level. Then pass these wave files through a parser which will compare time stamp with gps track and spit out a series of gpx waypoint files which can be open with JOSM.

I had to patch Manauton to get it to build and to alter the format of the time stamp. I had to patch GpsEventSync to allow input from the stdin (using input file name '-').

After which the following command does the 'biz'.

 interpretclick sample.wav | sed '/Z$/ a\00:00' | ges track.gpx - sample.gpx

There is still an issue that GpsEventSync produces a GPX file with the last point repeated, however the GPX file does load into JOSM

[disclaimer - still to be tested in the field, after fixing a very noisy wheel bearing :-( ]

--Mungewell 02:49, 2 April 2008 (BST)

Comments

What about a video camera? It provides more information than a voice recorder, you don't have to pay attention to anything but the road, and it records things that you missed. Andrewpmk 00:54, 27 March 2008 (UTC)

The problem with video, is that it's low(ish) res, will probably be pointing at the wrong thing and will take ages to filter through as there would be no reference points. It also takes a lot of space to store resultant files. --Mungewell 00:57, 2 April 2008 (BST)
See also Video mapping -- Harry Wood 11:55, 18 November 2008 (UTC)

I think the incresaed availability of dashcams and improvements to services like Mapillary have changed things a little since this was written. "High speed" photomapping can be OK if done with a proper mount. --InsertUser (talk) 13:09, 1 March 2020 (UTC)