[OSM-dev] dev Digest, Vol 53, Issue 21

[Stefan Ziegler]

Hello Nick,

you may want to look at osm3d.org and osm3d.de (two different projects).
Which programming language do you want to use?
You have good ideas. Begin with small parts of the osm data. Its easier to handle. Today also on smaller devices can be used a subset of OpenGL.
DirectX only works on Windows. 

Stefan Ziegler.

> Message: 6
> Date: Wed, 19 Aug 2009 18:10:33 +0100
> From: Nick Whitelegg <Nick.Whitelegg at solent.ac.uk>
> Subject: [OSM-dev] Thoughts for "footnav" - a 3D navigation tool for
> 	off	road users
> To: dev at openstreetmap.org
> Message-ID:
> 	<OF7D19C733.F37AF9E8-ON80257617.005CBC61-80257617.005E5904 at solent-university.ac.uk>
> 	
> Content-Type: text/plain; charset="US-ASCII"
> 
> 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
 

-- 
Diplom-Informatiker,
Homepage: http://www.stefanziegler-online.de/
Wir alle wissen mehr als das, wovon wir wissen, dass wir es wissen. (Thornton Wilder)

GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01