Hi Dave.  Thanks very much for your reply.

On Fri, 14 May 2004 23:37:58 +0100
David Luff <[EMAIL PROTECTED]> wrote:
> Chris Metzler writes:
>>
>> 2.  The taxiways that *are* listed in the Airport/runways.dat,
>> typically for major airports, don't have taxiway identifications
>> listed.  For example,
>> 
>> A KSQL     5 CYN San Carlos
>> R KSQL 12   37.511856 -122.249524 138.09  2599    75 NARHN NYVN    0  
>>  0 NYVN    0    0
>> T KSQL xxx  37.511303 -122.249374 134.68  2600    75 YCB
>> T KSQL xxx  37.510796 -122.250015 134.68  2600    75 YCB
>> T KSQL xxx  37.511108 -122.251083 134.68  2000   200 YCB
>> 
>> TrackArtist.cppAccording to the explanation of the format on Robin
>> Peel's site, those "xxx" should give a taxiway identifier.  I presume
>> that FlightGear doesn't use them at the present; but I can imagine
>> that they might be in the future, for ATC or AI, or for default
>> taxiway signs (in the absence of signs placed as 3D models in the
>> scenery).  If these are known, such as through an airport chart,
>> should they be put in?  If so, in what format (e.g. left-justified,
>> right-justified, zero padded, etc.)?
> 
> AFAIK, FlightGear can render taxiway signage based on a text field in
> one of the files (.stg?) - it shouldn't be too hard to adapt one of the
> tools (either TaxiDraw or fgsd) to output it to the .stg or whatever
> files it lives in.  Doing it for the base airports would be the way to
> start since then it can go into CVS, then think about the logistics of
> storing the generated data for worldwide airports!

Well, I'm probably talking out of my behind here, and maybe this isn't
an issue.  But I would naively think that having fgfs (or TerraGear or
whatever) place signs on the basis of taxiway identifiers in the
runways.dat file could be pretty tricky, if the taxiways were done with
TaxiDraw.  The tutorial suggests laying down lots of short-length taxiways
in an effort to make curved contours around junctions and turns; I can
imagine those curved contours having a zillion signs around them as a
result, if the signs were just laid down on the basis of all the taxiways
present in the runways.dat file.


>> 3.  Where should the taxiway data go?  The TaxiDraw tutorial
>> mentions sending them to Robin Peel, for inclusion in the complete
>> airport data.  Is that still the case?  Various things I've read
>> in the archives here gave me the impression that these days,
>> FlightGear is compiling its own airport data files from the DAFIF,
>> rather than getting them from Robin Peel's compilation.  The fact
>> that the files in Airport/* are similar to, but not exactly the
>> same as, those described on Robin Peel's website, seem to support
>> that perception.  Is that true?  If it is, then where should the
>> taxiway info be sent to, so FlightGear can use it?
>
> Please hold off temporarily from sending it to Robin - he can't import
> the FlightGear format datafiles that TaxiDraw outputs to his master
> database.  I'm midway through adding X-Plane data format support that he
> can handle to TaxiDraw, and will update the tutorial to reflect that
> when it's working and a new release is out.  Hopefully in a few weeks.
> 
> However, it shouldn't be underestimated just what a *huge* task it is to
> maintain worldwide airport data files.  Although noises have been made
> on the list about maintaining our own, realistically we are likely to be
> getting our data from Robin from the forseeable future IMO.

OK, so I interpret your last bit as saying that my interpretation
of what I saw in the archives is incorrect, and that the airport data
is still coming from Robin Peel.  Presumably, then, it goes through
some post-processing on the FG end to result in the basic.dat and
runways.dat files?  (since those files are similar, but not identical,
to the way it's provided by Robin, according to his web page)  And
presumably it's that difference that you're referring to above when
you note that he can't import the stuff TaxiDraw outputs -- because
it's in FG's form, rather than his original form?  Just making sure
I understand how this all works.


>> 4.  Is the information in the airport files considered to be 100%
>> accurate?  I occasionally see differences between runway lengths
>> listed in runways.dat and those listed in other sources, such as
>> U.S. state Department of Aviation databases, or U.S. FAA references
>> (reproduced at airnav.com).  The differences are rarely large --
>> less than 20 feet typically -- but it makes me wonder what's right
>> and whether there may be other discrepancies and so on.
> 
> A database that large will never be 100% right.  The use of background
> photos in TaxiDraw seems to indicate to me that a lot of the smaller
> airports are actually positioned up to several hundred meters
> incorrectly by the DAFIF data.

The biggest discrepancy I've noticed yet is the placement of Meigs Field
in Chicago; but while its placement isn't authentic, neither is its very
existence anymore (unfortunately), so . . .


> Sometimes the DAFIF is definately wrong,
> sometimes user-submitted data is wrong, sometimes the available aerial
> photos have been outdated by new developement.  It's just a case of
> making it as good as it can be.

Well, yeah.  I guess what I was wondering was whether there's some
sort of "conflict resolution" procedure.  If another source gives
other information, is the DAFIF data assumed to be correct because,
well, you gotta pick something.  If there are *two* sources which
agree with each other but contradict the DAFIF data, do you go with
that?  If you personally know the placement of an airport is wrong
and can correct it, should you try?  I'm just wondering what one
should do (if anything at all) upon encountering stuff that seems
wrong.


> There's lots of room for improvement to the airport modelling.  I guess
> that ultimately artistic orientated folk will start doing custom scenery
> for certain areas, rather than relying on the automated processing of
> compiled data as we do at the moment.  Adding buildings to all the
> base-area scenery airports would make a hell of a difference, and the
> results could go in CVS.

Yeah.  I'd like to do this; I'm using it as an excuse to learn Blender.
The problem I have at this point is good source photos.

As a side note, I confess I found kinda funny the bit on the Wiki that
encourages people to go out and take lots of good photos of the buildings
at their local airports and other landmarks.  I read that to a variety of
other people and they all had the same reaction I did:  "in the U.S., at
this time, you better clear it in advance or people will get suspicious
of you and ruin your day trying to make sure you're not a terrorist."

-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

Attachment: pgpGwZFRYzPvW.pgp
Description: PGP signature

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to