[OSM-dev] Thoughts for "footnav" - a 3D navigation tool for off road users

[Nick Whitelegg]

Further to my post the other day about photographic countryside views, 
I've got some initial ideas about the features of "footnav", a 3D 
navigation tool using OSM and SRTM data aimed primarily at countryside 
users. The eventual aim (one day, and it may depend on phones being 
powerful enough which may be some time in the future) is for it to act 
like a 3D satnav on your phone, so that, say you are in a field or on a 
mountain trail, and aren't sure where to go next, you could consult your 
phone to show you the way on via a 3D, or ideally photographic view.

Anyway here is some initial, basic analysis of what might be required 
(comments welcome):

- The application would need to show a 3D view (ideally photographic) of 
the direction you're facing, with the horizon appearing more or less as in 
real life.
   The in-built compass could be used on phones which support it, if not, 
some algorithm based on previous and current GPS positions could be used, 
with   reasonable filtering of close in time or distance GPS points to 
avoid silly rapid direction changing.

- OSM ways would need to be overlaid on the 3D view, for navigation.

- If non photographic, key nodes (such as stiles, gates, fences, 
buildings, towers of various kinds) would need to be shown as 3D models. 
Thus someone of artistic bent would be useful :-)

- The 3D view would have to take into account the slope the user is 
standing on. This could be tricky. One would probably need to obtain 
previous position, current position and estimated next position, calculate 
their approximate heights using the DEM, and thus calculate a slope.

- If we want to render OSM data on top of the 3D model accurately, I'd 
imagine that each OSM node would need a "y" coordinate, i.e. height. 
Pre-processing OSM data to minimise the number of calculations at runtime, 
generating a custom input data format, would probably be the best 
approach. Each *relevant* way (i.e. a way you want to see in the 
rendering) could be converted into a vector of x, y and z coordinates 
(=lat, height, lon). The vectors could then be rendered quickly without 
the need for excessive calculations. Nodes should also be filtered in the 
pre-processing so only relevant POIs (those you want rendered) appear.

- Once all this is working, using actual real photos rather than a 
computer generated 3D terrain could be investigated.

- A 2D view should also be available.

- Features such as overlaying an OSM raster map on a DEM, such as is seen 
in commercial products such as MemoryMap, could also be useful.

How much of this I get done myself is very, very dependent on my other 
commitments (paid work and general) but I thought I'd initially share my 
thoughts, it's intended to be open source (GPL) so all contributions are 
welcome :-)

Nick