On 23.04.2012 13:52, Christian Schmitt wrote: > We could, if the xml parser would not simply discard any new runways that > are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this, however, always has been and still is the normal behaviour, since these XML files were only intended to provide updated airport info, not introduce completely new ones (so it's not a new bug, as someone suggested). Also see below. > The xml files are small, can be distributed easily and are very fine- > grained, meaning that FG only has to parse the data it really needs for the > current scenery path, instead of parsing a close-to 100 MB file on every > startup (only for the apt data). I think we need the complete airport data in many places, i.e. when mapping the given start airport code to a starting position, to display the list of available airports in the selection dialog, to have data for the route manager, data for scheduling AI traffic, and for the Nasal interface to nav/airport data (which James is just updating these days). These probably all rely on a complete airport list being available straight away. So, we probably can't restrict things to the current display area. What may make sense is a better, non-compressed file format though, where we only load basic data (airport names/position/runways/...) at start-up, which would probably only require a few 100K. Later, we could go back into the (database) file and load additional data on demand, such as taxiway information, etc. (Which reminds of this http://developer.x-plane.com/2009/09/scalability-and-apt-dat/ ). If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. James really needs to comment on nav data things though, since I never touched this area. >> Terrasync already syncs a global "/Models" directory, so terrasync >> scenery can use newer or updated models. We could do the same for nav >> data. > You mean to put small apt.dat/nav.dat parts into these directories? Large even. This wasn't meant as a revolution to nav data handling. But it'd be one line of change to tell terrasync to sync another directory, and probably another one or two to change the search directory for apt.dat/nav.dat, so the terrasync directory was considered before the base package. This would only help with keeping terrasync scenery/nav data in sync. It wouldn't help with individual scenery packages. But I'm not sure if mixing nav data from different scenery packages is a good idea in the first place. At least I would like to have _one_ set of consistent, preferably very latest nav data available in FG. cheers, Thorsten ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
