Chris Metzler writes: > > Hi. I've been thinking of ways in which I could help out with stuff for > FlightGear, given that I don't code in C++. Other than providing useful > bug reports and the occasional odd suggestion, I thought of getting my > feet wet by working on adding taxiways to airports that aren't currently > given them. I also thought I might look at airport buildings, taxiway > markers, etc., and at 3D structures for landmarks such as are present in > the San Francisco scenery. >
Hi Chris, Making better airports is definately a good thing to do! And the more folk that attempt it the better :-) > If it's at all worthwhile for me to do this, then I have some questions. > > 1. Regarding adding taxiways, I read a bunch of old emails on this list, > and it seems like there's two ways to approach this. One is David Luff's > TaxiDraw, which (as I understand it) is solely concerned with rendering > taxiways, and produces a table of taxiway information for a particular > airport that's in an appropriate format for insertion into the > Airports/runways.dat file. The other is fgsd-taxi, a modified fgsd that > produces taxiway layouts not for rendering, but for AI aircraft to follow. > Do I have this correctly? If so, does it make sense when doing the former > to do the latter, even if the AI is not yet fully implemented, thinking > that then it doesn't have to be added later? > You've got that pretty well correct. At the moment the AI doesn't understand the output from fgsd-taxi, but that should be fairly soon in coming. TaxiDraw actually started out as an AI taxiway editor similar to AFCAD, but when I saw what Bernie was doing with fgsd-taxi I put that on indefinate hold, and only resurrected it as a physical taxiway editor when the need arose. > > 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! > > 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. > > 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. 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. > > 5. My understanding is that at this point, the runways, taxiways > and aprons are drawn using stock textures for the appropriate type > of surface specified in runways.dat. Is that correct? Just out of > curiosity, how difficult is that to change on very small scales, > e.g. for a particular small area at a particular location at a > particular airport. I can imagine putting in eye candy like > stains and skidmarks and gate markings and stuff like that, such > as one sees in images like: > > http://virtual.planepictures.net/show.cgi?18008 > http://library.avsim.net/sendfile.php?SendImage=48658 > http://virtual.planepictures.net/show.cgi?22698 > > How straightforward would that be to integrate such things into > scenery? I wouldn't think it'd be too consuming of rendering > resources, but maybe it would? > > > 6. What about abandoned airstrips? Not closed runways, but > airports that don't even truly exist anymore, but can still be > seen from the air. There's a website at > > http://members.tripod.com/airfields_freeman/ > > where a pilot gives info about these things in the US.. I think it'd > be cool to be able to see these from the sky, have them available > for emergency touchdowns, etc. But I'm not sure whether anyone > else thinks that's a good idea, or what the best way of > implementing them would be (e.g just a model placed on the terrain > at a given point, or with their own listings in runways.dat, or > whatever). > 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. Some way of getting taxiway centerlines to correctly do junctions, particularly off the runway, would also be a huge bonus, but would probably require coding in TerraGear. > > 7. Are there any guidelines for maximum complexity of 3D models > for scenery? On one hand, I want to make cool things. But OTOH, > I don't want to make things which are so cool that they won't get > used because they're too apt to drag framerates down into the > dirt. > > > That'll do for starters. Thanks for any info you can give; hope > my input is welcome. > Good luck, have fun! Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
