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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
