Hi. I'd like folks' opinion about this.
Right now, Robin Peel's apt.dat, which contains the runway and taxiway
data, comes with xxx in the runway designator field if it's not a runway
(i.e., is a taxiway, an apron, etc.). FlightGear's runways.dat, derived
from same, also lists things this way.
There are some problems with this. For one thing, when it comes time to
create the airport in scenery generation, a heuristic is required to
discriminate between apron and taxiway (e.g. an apron is wider than it
is long, a taxiway isn't). If we ever wanted auto-generated
runway/taxiway signs, the info isn't there on what to call the taxiways.
Ditto if we ever wanted tower to provide taxi directions. Those things
may not happen any time soon (or ever); but if it's not much effort to
prevent it from being impossible in the future, we might as well.
And everything is complicated by the tons of very very short taxiways
one creates in TaxiDraw to create rounded corners, etc. I was working
on doing KSQL correctly in TaxiDraw, given that it's the suggested
tutorial airport in some of the user docs accompanying fgfs. That
got put aside when the most recent airport info from Robin was missing
KSQL entirely, but anyway. When I put it aside, it was up to 124
taxiways. How will creating those in the scenery generation get
handled (centerlines, etc)? How would automated taxiway signs/taxiing
directions handle those? How does taxiway lighting handle the turns
cleanly?
Meanwhile, through available charts, information on taxiway designations
is available -- in some cases (e.g. airnav.com) fairly easily. My
thought was: why not put this info in where we have it? So I was
contemplating suggesting to Robin Peel that the runway/taxiway
designator be expanded from just xxx = generic runway/apron to
something like this:
xxx = generic runway/apron (to maintain backward compatibility)
T__ = real-world taxiway, with __ containing the real-world taxiway
identifier. (do they ever come with more than two characters?)
Txx = taxiway that doesn't correspond to anything in the real-world,
and is only present for drawing purposes (e.g. for rounding
corners)
Axx = apron
This comes up because I was considering writing some utilities in
python to go back and forth between FlightGear and X-Plane data formats,
to facilitate submitting corrected airport data (e.g. generated by
TaxiDraw, which writes in FlightGear format) back up to Robin Peel.
I can just do it straight, as is; but if there's a chance of
improving this earlier rather than later, I might as well include
handling this correctly too.
Of course, this would require monkeying with TerraGear and fgfs to
handle the change cleanly, I guess, which I don't know how to do
since I don't speak C++. And maybe this is so far down the priority
list of any coders as to be unimportant. At first, I'd think it'd
require nothing more than interpreting T__, Txx, and Axx as if they
were xxx -- that is, ignoring that they're different from xxx -- so
that the data could start being corrected immediately without breaking
scenery creation at present. And I wouldn't think that'd be too hard
to do. But I don't code C++and don't know about TerraGear, so maybe
I don't know what I'm talking about.
So, do people think pursuing this is a bad idea? A good idea? An
idea that can be improved? I wanted to see what people thought
before asking Robin Peel about it.
Thanks very much,
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove snip-me. to email)
As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear
pgpwDCTw6zrFg.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
