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
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]
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
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
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
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
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
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
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
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
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'
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
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
[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
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,
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
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
17 matches
Mail list logo
