[Flightgear-devel] basic.dat : Airport database update
Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
Paul Surgeon wrote: Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. I'd prefer to keep the contents of $fg_root/data read only, or at least not have the app modify anything in there. I think this should be handled some other external way. How would his field be updated for the average user? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On 12/12/04 at 6:00 PM Paul Surgeon wrote: On Sunday, 12 December 2004 17:32, Paul Surgeon wrote: Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. Paul Please disregard - Melchior pointed out quite correctly that user data should not be stored in CVS files. Your basic idea - that the user shouldn't be presented with a selection of unavailable airports, is perfectly valid though. Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. As a further idea, airports could have a country ID added during this step based on the ICAO code, and presented to the user in a far more civilised per-country selection. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On Sunday, 12 December 2004 19:14, David Luff wrote: Your basic idea - that the user shouldn't be presented with a selection of unavailable airports, is perfectly valid though. Actually I would provide the unavailable airports but if the user selects one that is not installed inform them of the issue as well as tell them which scenery file to download in order to get the airport. Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. I would make it a manual process to start with and store the data between sessions. The user can click on a button to rebuild the list if they add scenery. This can all be done from inside the airport dialog which means that there is zero performance penalty until someone tries to use the feature. However I will investigate the performance impact of an auto update based on file timestamps and if it's feasible for 12GB of data suggest it. As a further idea, airports could have a country ID added during this step based on the ICAO code, and presented to the user in a far more civilised per-country selection. That would be nice although we don't store that info yet. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
An alternative solution would be to run terrasync in the background. Ampere On December 12, 2004 12:14 pm, David Luff wrote: Your basic idea - that the user shouldn't be presented with a selection of unavailable airports, is perfectly valid though. Why not first scan FG_SCENERY path for installed scenery in either 10x10 (quicker) or 1x1 (deals with the small CVS area) degree chunks, and cache this in memory. Then test all airports against installed scenery area on load, and save the result with the airport. That should work, question is what impact on load time it would have. As a further idea, airports could have a country ID added during this step based on the ICAO code, and presented to the user in a far more civilised per-country selection. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On Sunday, 12 December 2004 20:23, Ampere K. Hardraade wrote: An alternative solution would be to run terrasync in the background. Ampere Terrsync works great for people with dialup connections who pay by the minute ... :-\ I have to connect at off peak times to get cheaper rates and 64K ISDN is not fast enough when flying at 400kts. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] basic.dat : Airport database update
On Sunday, 12 December 2004 17:32, Paul Surgeon wrote: Would there be any objections if I added an extra field (installed) to Airports/basic.dat ? What I want to do is keep a list of airports that are available world wide as well as those that are actually installed. I can either do it that way or I can create a new file containing installed airports but then I would have to cross reference between the two files. Paul Please disregard - Melchior pointed out quite correctly that user data should not be stored in CVS files. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
