Video mapping
From OpenStreetMap
Video mapping might work, but this mapping technique has never been used to great effect in the project by anyone yet as far as we know. It is used commercially by NavTeq and Yotta DCL.
Contents |
Manual Video Mapping
Mount a video camera (or digital camera in "movie" mode) somewhere in your car, and leave it recording for the duration of your journey.
Afterwards, note the timestamp of anything interesting in the video (e.g. "Shops on the left between 1:32 and 1:37") and correlate that with the GPS tracklog.
Problems:
- The video will be rather boring to watch!
- It would take as long as the car journey itself, except that you could fast-forward some bits.
- Obviously this would only enable you to map features which were captured on the video. If you can't see a street sign on the video, then you've failed to map that street. Pointing sideways or at a 45 degree angle might improve the view, but then you only get features of one side of road (unless you double up on cameras!) Street sign are often only on one side of the junction, meaning they might only be visible on the view behind the car. More cameras??
- Video storage space (e.g. tape length) might be a limiting factor.
Advantages:
The interesting thing about this idea, is that at the time of doing the journey, it's easier than any other mapping technique. You dont need to stop and start at all. You're leaving all the work to do later. You set the video and GPS going, and then forget about it. In fact you could set it going recording your mother's car journey.
Another advantage is that details like bus stops and telephone boxes will all get captured on a video. Pen & paper mappers find these things quite tedious to make notes of. Photo mapping makes it fairly easy, but you still have to go to the trouble of taking a photo.
Machine recognition
It might be possible to do some machine recognition on video footage, to automate or semi-automate the process of extracting relavant data for OSM
Information a computer would need:
- Video footage
- GPS Position and speed (correlated by time stamp of DVI video and GPS track)
- View angle of camera (focal length and that stuff)
- Angle of offset from motion of travel (which is constant)
[Match moving http://en.wikipedia.org/wiki/Match_moving] is a technique from movie special effects which can be used to automatically estimate the parameters of the camera, including it's motion. By best-matching this data with the GPS, you will be able to fill in gaps in the GPS signal and produce a more accurate trace.
Basic recognition of features
Probably the simplest machine recognition we might attempt, would be to identify things like phone boxes, post-boxes, post-office signs etc. Then there's more difficult things like street signs and pub signs.
A semi-automated solution could extract static images of interesting looking features, and then present these as a set of timestamped (and GPS correlated) photos to be processed manually with our Photo mapping tools. This eliminates the need to watch video footage, but leaves a fair bit of manual work still to do. It lowers the need for accuracy of the machine recognition, which makes it more feasible.
Video Radar
This is an idea for a form of video "radar" that could determine distances from video mounted on a moving vehicle.
Core idea: A human seeing a video take from the window of a moving vehicle can visually estimate distances to buildings and other features based on their apparent motion. Could a computer connected to a video camera and GPS do this automatically?
Based on motion of objects in the video, distances could be determined by computer. To what accuracy remains unknown.
Problems: moving objects like cars could confuse the system.
Output of system: A series of "echo returns" from buildings, stationary objects (and road markings?) forming a 2D map.
Alternatively, a user could click on paused video and the system would estimate the lat, long of that point.
Follow up idea. 3D model with texturing
If the above system is implemented, 2D surfaces could be recognized and stored. This would produce a 3D model of a neighbourhood with texturing!
This would involve a serious amount of development. Occlusion would be a nightmare.
