Re: [Opengc-devel] nav database

[Damion S. <da...@op...>]

Yes, this is a good opportunity to extend things. Basically, the way 
I've organized things now is under the "data-view" model. Because of 
the many possible map projections, it makes sense to separate apart the 
database and rendering components of navigation. Since Mercator is the 
only supported projection at the moment, and it does not vary based on 
aircraft location, it's possible to pre-compute the Northing and 
Easting coordinates of each nav object on the Mercator grid. This is 
what happens during the nav database initialization. It's then up to a 
particular nav display to decide how to draw the objects that are 
stored in the nav database.

As we move towards more complicated projections, such as the conformal 
conic, or any other projection that varies based on aircraft lat/lon, 
the transformation of each geographic object will need to be computed 
in real time. To speed this up, I've experimented with hashing 
geographic objects based on 1 degree lat/lon squares (see 
ogcGeographicHash). The 1 degree hash is what's used with the nav test 
gauge (Mercator projection), and the speed is actually pretty decent. 
Unfortunately, this hash technique is subject to the different size of 
lat/lon squares depending on latitude.

There are lots of other ways of doing this; some sort of distance based 
metric comes to mind, to avoid the problem of varying bin sizes with 
latitude.  Under this scheme you'd compute a linked list of all 
geographic objects within 200 nm of a given lat/lon intersection 
(perhaps indexed by 1/2 or 1/4 degree increments), and then look up the 
nearest linked list based on aircraft location. This would increase 
obviously increase preprocessing time and memory consumption quite a 
bit, but may be necessary to achieve suitable rendering speed. The 
other possibility is to have a companion program to OpenGC that does 
this ahead of time and writes separate files that contain the above 
information, possibly in a binary format to save space and load time. I 
anticipate that something like this will be necessary for the sectional 
data, given it's large size.

With the dynamic data you describe, I would assume we could get away 
with not preprocessing it since there will probably be much less of it 
around.

Some things that would be good to think about:

Is the "list of GeographicObjects" model sufficiently flexible to deal 
with navigation needs, insofar as representing discrete objects 
(airports, navaids, etc.) goes?

Do graphical sectionals get stored in the nav database?

Should we preprocess the nav data to disk, so that less needs to be 
stored in memory?

-Damion-


On Dec 2, 2003, at 11:32 AM, Wendell Turner wrote:

> Is there an anticipated format or structure for data that the
> nav display will use?  I've hacked some data into the old one,
> but with the re-write in progress, maybe here is an
> 'opportunity' to work on this also.
>
> Certain data available for the nav display will be static, read
> in at startup time, and possibly localized to the area (I will
> not be needing waypoints around Kuala Lumpur if I'm flying in
> Virginia, USA).  Static data (from DAFIF, etc) would include:
>   Runway endpoints, VORs, waypoints, intersections,
>   restricted areas
>
> Also, dynamic data should be available during program operation.
> This data would be received via datalink to the aircraft, or by
> other means.  This data would include
>   TIS/TCAS/ADSB targets, flight plan, active MOAs, and TFRs.
>
> Will this be an anticipated use for the nav display in
> opengcnew?  Or are these 'features' that we can program into the
> display as desired?
>
> Wendell
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>