Chris Metzler writes:

> On Fri, 14 May 2004 23:37:58 +0100
> David Luff 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
> >> 
> >> According 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.

What I meant was adapting TaxiDraw (or fgsd) to allow the user to specify where the 
signs would go, and the designation on the sign, and then export the appropriate 
format file.  This would not be the runways.dat format, but instead one of the scenery 
files that designates where objects are placed - I believe it's .stg.  There is 
apparently already support for taxiway signage in .stg files (I think) - I believe it 
was done in the KJSC photo-scenery demo.  I'd be happy to add the code to TaxiDraw if 
you wanted to use it for this, it's something I've been thinking about already.  As 
you say, automatically placing them via the runways.dat designations could be a 
nightmare, although I guess it's possible that you could add names only to 'proper' 
taxiways that required signage.  It would still be a job to get them placed 
automatically without them overlapping other taxiways or runways, and that would 
probably require coding in TerraGear.

> 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.

Curt and Robin know how this stuff works better than myself, but I believe that Robin 
has export filters to export his data in our basic.dat + runways.dat format, but no 
import filters.  I believe he keeps the raw data in a database, and exports in either 
X-Plane or FG format, but only imports in X-Plane format.  There are some details on 
his website, the address of which eludes me at the moment.

> > 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.

Once again, I'm not sure, but I believe that Robin takes the DAFIF data as his primary 
source, and wants folk submitting manual alterations to be absoluty explicity clear 
that they know what they are doing if they want to move runways away from the DAFIF 
locations.  There are some words about this on his web page.

> > 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 far as I can tell, a lot of US GA airports have large numbers of fairly generic, 
low, white or light-grey hangars.  It would be very good to get some of these into the 
default GA airports, and wouldn't really require fancy textures from photos.

Cheers - Dave

Flightgear-devel mailing list

Reply via email to