RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL Is that example meant to start with a W rather than an R? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Richard Bytheway writes: R KABC 29.650236 -96.579416 176.00 SL Is that example meant to start with a W rather than an R? Yeah, that would do the trick. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Julian Foad wrote: David Megginson wrote: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.374926 13 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.374926 13 US CA CYN San Francisco Intl It seems *awfully* redundant given that there is already the Id *and* the geographical location. I have difficulty imagining that a high enough proportion of these will be determined and maintained to make it worthwhile. I do see why you want it though, and agree it would be nice to be able to get a list of airports in my region, by name of region rather than by lat/lon. IMO, we should include all these data in seperated .xml file for each airport. In airports.tgz there should only be an international code of the airport, lat/longitude and a reffering xml file for that airport. That xml file should include all the data about buildings surrounding it, taxiways positions, parking spaces, windsocks, ATC stuff etc. FG should read the airports.tgz file completely, but seperated xml files on demand. My 5 cents:). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On Tue, 14 Oct 2003, Matevz Jekovec wrote: IMO, we should include all these data in seperated .xml file for each airport. In airports.tgz there should only be an international code of the airport, lat/longitude and a reffering xml file for that airport. That xml file should include all the data about buildings surrounding it, taxiways positions, parking spaces, windsocks, ATC stuff etc. FG should read the airports.tgz file completely, but seperated xml files on demand. If you do that then when you try to display a list of airports in the local area then you need to: 1. Calculate which airports *are* in the local area (because they're not already classicied into continents/countries/whatever). 2. Read the xml file for each one, because we don't have the name in the airport directory. This would be SLOW. There needs to be just enough info in the airports file to be able to quickly provide an index. The the rest of the details can be read from a seperate file once an airport is selected. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Norman Vine [EMAIL PROTECTED] said: David Megginson writes: Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. I hope that this data base is stored in XYZ form and not lat lon else any optimizations you make by spatial partitioning will be nullified by the trig calls required to get distances If changing the format, another consideration would be anything that might help the implementation of modern flight system emulation. I'm thinking about get nearest airport, list nearby airports with runways over x ft/m length, etc. For some reason I was thinking that lat+lon would be easier for that sort of function. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Jon Stockill wrote: On Tue, 14 Oct 2003, Matevz Jekovec wrote: IMO, we should include all these data in seperated .xml file for each airport. In airports.tgz there should only be an international code of the airport, lat/longitude and a reffering xml file for that airport. That xml file should include all the data about buildings surrounding it, taxiways positions, parking spaces, windsocks, ATC stuff etc. FG should read the airports.tgz file completely, but seperated xml files on demand. If you do that then when you try to display a list of airports in the local area then you need to: 1. Calculate which airports *are* in the local area (because they're not already classicied into continents/countries/whatever). 2. Read the xml file for each one, because we don't have the name in the airport directory. This would be SLOW. There needs to be just enough info in the airports file to be able to quickly provide an index. The the rest of the details can be read from a seperate file once an airport is selected. Yes, I thought about it more and you are correct. IOW the list of airports file should include all the coords and search criteria in it as well. The file can grow up quite a bit though, but we can trash these data when in cockpit to free ram, right? What about other flight sims? How did they solve this problem? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: David Megginson writes: Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. I hope that this data base is stored in XYZ form and not lat lon else any optimizations you make by spatial partitioning will be nullified by the trig calls required to get distances If changing the format, another consideration would be anything that might help the implementation of modern flight system emulation. I'm thinking about get nearest airport, list nearby airports with runways over x ft/m length, etc. For some reason I was thinking that lat+lon would be easier for that sort of function. Any ordering by distance is *exactly* the computation that you *don't* want todo in lat lon space as this is a trivial sgDistanceSquared() call in XYZ Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFD: Proposed Changes to Airport Data Files
I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Comments? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On 10/13/03 at 5:12 PM David Megginson wrote: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) Agree whole-heartedly with this. Things like frequency lookup can then have a nice world-map downwards clickable interface. 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Comments? I think we have to be very careful about how much data we store globally. FG has a pretty large memory footprint - I've just fired a non-debug version up and it clocks 360Meg of RAM. Really, only airports and frequencies must be stored in memory ready for use, since that is what we look up by. We could load runways on demand when the airport is known. The disadvantage being that the runways come prepackaged in the current format. I propose adding an xml facilities file for each airport with custom data that isn't needed all the time - an extended version of what Bernie's taxiway editor puts out with logical taxiways, gates, circuit direction, vfr reporting points, noise reduction regs, preferred calm rwy etc - all the stuff that is going to have to rely on users entering it since there's no central database, and a lot of it stuff that can fall back to sensible defaults. I would be very tempted to put tower and windsock in here as well, unless you know of a large database of such values. It's also confused by the fact that you probably want to render them based on that info, and would prefer one file for Terragear input? I'd also be tempted to put runways in the per-airport file, to be automatically tar'd up in FG's standard scenery directory format for the program to find, but suspect that Curt will be sending this to dev/null about now :-) A few other points - how about splitting the world-wide databases into 2 - with the split down the atlantic and down between Alaska and Siberia. Loading the other database into memory at 3 over the ocean probably wouldn't be noticed, and key Greenland etc VORs could be duplicated. Also - the taxiways really don't need to be in runways.dat - they're only used for rendering (Terragear) and slow up the loading of FG. Remember that loading text files is much slower on Windows than Linux. It would be better to split out the taxiways into taxiways.dat.gz and ship it with the base for reference but not load it IMHO. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Am Montag, 13. Oktober 2003 23:12 schrieb David Megginson: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) I agree with that. Especially because such an airport dialoge is an important feature for a flightsim and still missing in flightgear. Maybe we should also think about adding another entry, the continent. If we want to use a search by continent feature in the airport dialog, then of course, it is possible to find the continents by country. But history showed that this is not a reliable value. For example 15 years ago, you could say that the UDSSR is more in Asia instead of Europe, but when you would check for the moscow airport your programm would assume asia because of UDSSR=Asia, but that's wrong because, moscow is still in Europe. So, that's why an additional entry for continents would be probably wise. If we want to save space, we could save a number instead of the continent name and assign the appropriate name when the aiport dialog is started. Here's my proposal for the a number continent table: 1 Europe 2 Asia 3 Africa 4 Middle America 5 North America 6 South America 7 Australia So instead of: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This one: A KSFO 37.618763 -122.37492613 5 US CA CYN San Francisco Intl Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
David Megginson wrote: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl It seems *awfully* redundant given that there is already the Id *and* the geographical location. I have difficulty imagining that a high enough proportion of these will be determined and maintained to make it worthwhile. I do see why you want it though, and agree it would be nice to be able to get a list of airports in my region, by name of region rather than by lat/lon. This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Yep, lovely. Those two look good to me. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On Tue, 14 Oct 2003, David Luff wrote: Agree whole-heartedly with this. Things like frequency lookup can then have a nice world-map downwards clickable interface. Yes, it's a small addition, with obvious benefits. I think we have to be very careful about how much data we store globally. FG has a pretty large memory footprint - I've just fired a non-debug version up and it clocks 360Meg of RAM. Really, only airports and frequencies must be stored in memory ready for use, since that is what we look up by. We could load runways on demand when the airport is known. The disadvantage being that the runways come prepackaged in the current format. Splitting the info only required at scenery generation time out into a seperate file has to be a good thing - as you say, the footprint of flightgear is growing - its pointless holding redundant data in RAM. I propose adding an xml facilities file for each airport with custom data that isn't needed all the time - an extended version of what Bernie's taxiway editor puts out with logical taxiways, gates, circuit direction, vfr reporting points, noise reduction regs, preferred calm rwy etc - all the stuff that is going to have to rely on users entering it since there's no central database, and a lot of it stuff that can fall back to sensible defaults. I would be very tempted to put tower and windsock in here as well, unless you know of a large database of such values. It's also confused by the fact that you probably want to render them based on that info, and would prefer one file for Terragear input? I'd also be tempted to put runways in the per-airport file, to be automatically tar'd up in FG's standard scenery directory format for the program to find, but suspect that Curt will be sending this to dev/null about now :-) A few other points - how about splitting the world-wide databases into 2 - with the split down the atlantic and down between Alaska and Siberia. Loading the other database into memory at 3 over the ocean probably wouldn't be noticed, and key Greenland etc VORs could be duplicated. Does it buy you much if you're going to have to load both if someone searches for an entry anyway? Also - the taxiways really don't need to be in runways.dat - they're only used for rendering (Terragear) and slow up the loading of FG. Remember that loading text files is much slower on Windows than Linux. It would be better to split out the taxiways into taxiways.dat.gz and ship it with the base for reference but not load it IMHO. I was going to suggest moving all the supplementary data to this file too, but then it occurred to me that not all of it is used simply for building scenery - things like windsock info would be fine - as it can be placed when the airport tile is built, but things like circuit and logical taxiway data are required at runtime, so we'd be dragging all the redundant baggage along too. Moving all supplemental airport data to a per airport file would make sense, although it will require changes to terragear for building the airports. If it's done right though it should allow easy expansion of airport facilities. As David said, XML may be the way to go. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On Tue, 14 Oct 2003, Julian Foad wrote: It seems *awfully* redundant given that there is already the Id *and* the geographical location. I have difficulty imagining that a high enough proportion of these will be determined and maintained to make it worthwhile. I do see why you want it though, and agree it would be nice to be able to get a list of airports in my region, by name of region rather than by lat/lon. It's awfully time consuming to determine the continents on the fly though, rather than simply searching for a particular key. Yep, lovely. Those two look good to me. The problem there is that we don't need to keep a list of windsock locations in RAM all the time. *YES* we need the data - I'm just not convinced that that's the place to put it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
[EMAIL PROTECTED] writes: Maybe we should also think about adding another entry, the continent. If we want to use a search by continent feature in the airport dialog, then of course, it is possible to find the continents by country. But history showed that this is not a reliable value. For example 15 years ago, you could say that the UDSSR is more in Asia instead of Europe, but when you would check for the moscow airport your programm would assume asia because of UDSSR=Asia, but that's wrong because, moscow is still in Europe. For the very few countries that straddle continents, like the Russian Republic or Turkey (any others?), the region/state code will (hopefully) be adequate to make the distinction. If there are 10 or 20 airports that are still ambiguous because of states/regions that also straddle continents, we could put them into a special-case table if necessary. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Jon Stockill writes: The problem there is that we don't need to keep a list of windsock locations in RAM all the time. *YES* we need the data - I'm just not convinced that that's the place to put it. There's no need to load it into RAM in FlightGear -- TerraGear can use the information, and FlightGear can simply skip over it (as it does with taxiways, I hope). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
David Megginson writes: Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. I hope that this data base is stored in XYZ form and not lat lon else any optimizations you make by spatial partitioning will be nullified by the trig calls required to get distances Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
