RE: [Flightgear-devel] Georegistered imagery
Terraserver.homeadvisor.msn.com has aerial photographs of the US and Alaska down to 1m resolution (though most of it is 10yrs old, for obvious reasons). Most of the US and Alaska, at least. No, we can't get photo-scenery for Groom Lake. They get the photographs from USGS, but I can't find out if it's possible to just grab the lot. I take it that it isn't, though they also seem to have colour-infrared photographs available. I'm not sure how much a non-US national can help if anybody wants the data. Giles Robertson [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Jon Stockill [mailto:[EMAIL PROTECTED] Sent: 25 May 2004 15:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Georegistered imagery Corrubia, Stacie K wrote: Is it possible to bring in either raw or TIFF imagery to the flight gear environment? The imagery has been georegistered and is part of a set of stereo pair images used to create 3-D models and DEMs. Can the imagery data (as well as 3-models and high resolution DEMs (3 meter DEMs) be overlaid on an existing lower resolution dataset already in the environment? Now I've stopped drooling and repeatedly saying 3 meters! I'll reply :-) All the flightgear scenery is preprocessed using the tools available at www.terragear.org. If you're wanting to create high resolution scenery then this is where you'll need to start. There's a tutorial here: http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html That will cover the basics. The code for the positioning of photographic images is very under-developed, and not really in a usable state yet. It can be made to work reasonably effectively but imposes a very high load on the graphics subsystem as flightgear does not yet support texture paging. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] keyboard mapping
Hi Guys The other day I stumbled on the keyboard map for FG, can't find it at present,and I noticed quite a few keys that have not been alocated yet. I was wondering if a block of say ten keys could be put aside and labeled aircraft specific for things like tail hooks, A/C doors, refueling booms and other things I can't think of now. Because as models become more complex modelers will want to add more features to there models. Cheers Innis _ FOXTEL Digital - Your ticket to cinema at home: http://ad.au.doubleclick.net/clk;7718915;9123289;x?http://www.foxtel.com.au/Campaign/channelchoice.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SID, STAR, and airway data
In February Erik Hofman mentioned that Robin Peel maintains a database of airway data, for shared use between x-plane and FlightGear. I was wondering if there's also a database of SID and STAR procedures that we could use? The reason I'm asking is that these might be extremely useful in developing AI traffic. IIRC, the airway database is currently not included in the cvs base package. Where would I be able to find it? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] keyboard mapping
Innis Cunningham wrote: Hi Guys The other day I stumbled on the keyboard map for FG, can't find it at present,and I noticed quite a few keys that have not been alocated yet. I was wondering if a block of say ten keys could be put aside and labeled aircraft specific for things like tail hooks, A/C doors, refueling booms and other things I can't think of now. Because as models become more complex modelers will want to add more features to there models. Cheers Innis _ FOXTEL Digital - Your ticket to cinema at home: http://ad.au.doubleclick.net/clk;7718915;9123289;x?http://www.foxtel.com.au/Campaign/channelchoice.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel There was a previous thread on this topic, but it died out. I suggested that a nice convention would be to use the CTL modifier for all keystrokes that are defined by aircraft. This way, when a user adds to or modifies their keyboard.xml file locally they won't have to worry about conflicts with aircraft that define their own keystrokes, and vise-versa for the aircraft designers. A nice way to reinforce this would be to put a comment at the top of the CVS keyboard.xml explaining it so that anyone who modifies the file, in CVS or locally would understand it. We could also put a small routine in whatever loads aircraft files that spits out a polite warning when someone defines a non CTL key explaining that at some point it may cause a conflict. I think that there is already stuff out there that does not conform to this, but if enough people here agree, I would be happy to chase down all those potential conflicts and mitigate them. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Georegistered imagery
A good updated version of the Scenery Tutorial is here: http://glennm.orcon.net.nz/flightgear/fg-scenery-tutorial2.html Not sure why this has not been adopted on the main site. Earlier in the year I had some success with a simple method of placing photo scenery here are some results: http://freespace.virgin.net/mamaloucos.circus/Flightgearweb/index.html Pressure of work has kept me away from Flightgear for a while which is a shame so have made no further progress. Happy to explain how this was done if anyone is interested. There is no theoretical limitation to the coverage achievable by this method. Apparently the potential limitations are to do with the dynamic loading of textures and a need for a scenery LOD system. As an update I have been trying to get something in writing from coch media and getmapping to confirm the usability of the aerial imagery in the getmapping series CDs under the eula. This is what I had used to create the above scenery. There's been several emails between us, but no decision as such, have chased them again today. Mat ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
Durk Talsma wrote: In February Erik Hofman mentioned that Robin Peel maintains a database of airway data, for shared use between x-plane and FlightGear. I was wondering if there's also a database of SID and STAR procedures that we could use? The reason I'm asking is that these might be extremely useful in developing AI traffic. It would be better than what we have now, but it wouldn't be realistic. SIDs and STARs are fallback procedures in case of lost comms -- in real life, ATC has never had me fly one all the way through, and most of the time, my arrivals and departures bear little resemblance to the SIDs or STARs, even when they were part of my initial clearance. The reason they don't work in real life is that everyone is flying at a different speed. There's typically one STAR for every arrival direction (often centred around a major intersection or navaid), but ATC has IFR traffic ranging from 100 kt Cherokee 140s to 180 kt twins and turboprops to jets flying just barely under the 250 kt low-altitude limit (or not, in the case of some military jets). They also have to get departures off the runway in-between arrivals. Obviously, they cannot send us all in on the same route even if the STAR does have separate altitudes for jets and props, so the STAR usually gets abandoned not long after the initial fix. Jets and turboprops typically get vectored to a long final (say, 15 nm or more), while slow twins and singles get turned in just before (or sometimes on top of) the final approach fix so that they'll spend the minimum amount of time clogging up approach path. IIRC, the airway database is currently not included in the cvs base package. Where would I be able to find it? DAFIF has a complete airway database. I actually used it once for real-life flight planning when I had my notebook with me but couldn't get online and had left my charts in the plane. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New airport data: whither KSQL?
Hi. I just downloaded the new airport basic/runways files from CVS (thanks Curt!). I noticed that KSQL is no longer in the files at all. The airport itself still seems to exist in the real world (hehe). Was it removed from Robin Peel's data? Or was it never there, and was an airport that we've been adding after the fact? Thanks, -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 pgpySqFRv5tPu.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New airport data: whither KSQL?
Chris Metzler wrote: Hi. I just downloaded the new airport basic/runways files from CVS (thanks Curt!). I noticed that KSQL is no longer in the files at all. The airport itself still seems to exist in the real world (hehe). Was it removed from Robin Peel's data? Or was it never there, and was an airport that we've been adding after the fact? Hmmm, it looks like this got dropped for some reason from Robin's latest database. I will report it and hopefully it will be back soon. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports basic.dat.gz, 1.5,
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Airports In directory baron:/tmp/cvs-serv21708 Modified Files: basic.dat.gz runways.dat.gz Log Message: Updated airport, runway, taxiway, windsock, beacon, and tower data. Curt, would you _please_ :-) manually change LFZZ/Chambley in basic.dat and runways.dat to some useful code _before_ the next scenery release ? LFZZ is the default code for all French airfields that are not further specified - which results in multiple entries in Robin's database that are named LFZZ. I've found two possible codes for Chambley Airbase. LCHM according to http://dss.ucar.edu/datasets/ds900.0/data/pre73 and FX01 on http://www.fortunecity.com/marina/harbourside/2145/id28_m.htm Maybe Frederic has a suggestion which one to prefer hello Frederic ;-) I started pointing Robin to the existence of this airfiled in spring 2002 !!! (see ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/FX01.apt). Two years have passed since but unfortunately he still refuses to apply a unique code to Chambley which makes this airfield pretty useless in FlightGear :-( Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Many duplicates in the new airport data.
Hi. The new airport data has duplicate entries for a lot of airports. It looks like in some cases, data for airports changed -- runways got moved or rotated, new taxiways got added, etc. -- so an entire new set of data for the airport went in, while the old one was still listed. There are some duplicates that look exactly the same -- perhaps they changed in something not listed in runways.dat, such as their radio freqs. This is not simply duplicate use of the ZZ identifiers, but actual full airports that are in there twice. I don't know whether duplication where the position is exactly the same is an issue. But there are places where things aren't the same in the layout. KMHT (see example below) is gonna look a mess with its old and new runway lengths and orientations, and two sets of taxiways superimposed and offset. Just a heads up . . . -c A KMHT 266 CYY Manchester R KMHT 06 42.935836 -71.439677 42.33 6841 150 NAPHN NYNN00 NYPN 00 T KMHT xxx 42.931114 -71.431625 156.00 4300 130 YAB T KMHT xxx 42.925583 -71.436569 66.00 4000 130 YAB T KMHT xxx 42.931805 -71.435310 156.00 4000 110 YAB T KMHT xxx 42.931263 -71.430687 156.10 2670 380 NCN T KMHT xxx 42.940689 -71.431801 43.00 2200 120 YAB T KMHT xxx 42.926876 -71.438171 64.00 1900 700 YCB T KMHT xxx 42.929546 -71.433479 68.00 1800 130 YAB T KMHT xxx 42.932934 -71.437500 158.00 1700 290 YCB T KMHT xxx 42.927471 -71.443481 106.00 1630 150 YAB T KMHT xxx 42.925320 -71.431679 116.00 1600 220 YAB T KMHT xxx 42.940266 -71.436165 144.00 1500 120 YAB T KMHT xxx 42.935638 -71.436806 66.00 1260 130 YAB T KMHT xxx 42.929443 -71.436340 0.00 1100 300 YCB T KMHT xxx 42.925850 -71.441040 153.00 1050 220 YAB T KMHT xxx 42.923245 -71.442749 138.00 1000 500 NCN T KMHT xxx 42.937389 -71.434685 6.00 1000 150 YAB T KMHT xxx 42.932259 -71.433815 95.30 1000 120 YAB T KMHT xxx 42.925449 -71.436043 133.00 850 100 YAB T KMHT xxx 42.935490 -71.438438 116.00 700 120 YAB T KMHT xxx 42.925133 -71.428879 16.00 700 120 YAB T KMHT xxx 42.941887 -71.436493 18.00 660 110 YAB T KMHT xxx 42.924339 -71.438042 66.00 600 400 NCN T KMHT xxx 42.943146 -71.436714 157.00 600 300 NCN T KMHT xxx 42.928639 -71.447319 129.00 600 120 YAB T KMHT xxx 42.924458 -71.431519 62.00 600 100 YAB T KMHT xxx 42.941704 -71.438599 68.00 570 110 YAB T KMHT xxx 42.924015 -71.432846 66.00 500 400 NCN T KMHT xxx 42.924572 -71.435051 90.00 500 380 NCN T KMHT xxx 42.927948 -71.447006 78.00 500 130 YAB T KMHT xxx 42.925495 -71.433723 36.00 500 100 YAB T KMHT xxx 42.928154 -71.448319 130.00 440 130 YAB T KMHT xxx 42.943142 -71.429634 135.00 400 120 YAB T KMHT xxx 42.942337 -71.430580 131.00 400 120 YAB C 42.933514 -71.439232 0 B 42.936390 -71.440507 1 W 42.929454 -71.449136 1 W 42.942218 -71.430215 1 [ snip -- Manchester, England's airport is inbetween ] A KMHT 266 CYY Manchester R KMHT 17 42.930124 -71.432686 156.59 9244 150 YAPHN YYPS 3330 YYPC 8500 T KMHT xxx 42.931114 -71.431625 156.00 4300 130 YAB T KMHT xxx 42.925583 -71.436569 66.00 4000 130 YAB T KMHT xxx 42.931805 -71.435310 156.00 4000 110 YAB T KMHT xxx 42.931263 -71.430687 156.10 2670 380 NCN T KMHT xxx 42.940689 -71.431801 43.00 2200 120 YAB T KMHT xxx 42.926876 -71.438171 64.00 1900 700 YCB T KMHT xxx 42.929546 -71.433479 68.00 1800 130 YAB T KMHT xxx 42.932934 -71.437500 158.00 1700 290 YCB T KMHT xxx 42.927471 -71.443481 106.00 1630 150 YAB T KMHT xxx 42.925320 -71.431679 116.00 1600 220 YAB T KMHT xxx 42.940266 -71.436165 144.00 1500 120 YAB T KMHT xxx 42.935638 -71.436806 66.00 1260 130 YAB T KMHT xxx 42.929443 -71.436340 0.00 1100 300 YCB T KMHT xxx 42.925850 -71.441040 153.00 1050 220 YAB T KMHT xxx 42.923245 -71.442749 138.00 1000 500 NCN T KMHT xxx 42.937389 -71.434685 6.00 1000 150 YAB T KMHT xxx 42.932259 -71.433815 95.30 1000 120 YAB T KMHT xxx 42.925449 -71.436043 133.00 850 100 YAB T KMHT xxx 42.935490 -71.438438 116.00 700 120 YAB T KMHT xxx 42.925133 -71.428879 16.00 700 120 YAB T KMHT xxx 42.941887 -71.436493 18.00 660 110 YAB T KMHT xxx 42.924339 -71.438042 66.00 600 400 NCN T KMHT xxx 42.943146 -71.436714 157.00 600 300 NCN T KMHT xxx 42.928639 -71.447319 129.00 600 120 YAB T KMHT xxx 42.924458 -71.431519 62.00 600 100 YAB T KMHT xxx 42.941704 -71.438599 68.00 570 110 YAB T KMHT xxx 42.924015 -71.432846 66.00 500 400 NCN T KMHT xxx 42.924572 -71.435051 90.00 500 380 NCN T KMHT xxx 42.927948 -71.447006 78.00 500 130 YAB T KMHT xxx 42.925495 -71.433723 36.00 500 100 YAB T KMHT xxx 42.928154 -71.448319 130.00 440 130 YAB T KMHT xxx 42.943142 -71.429634 135.00 400 120 YAB T KMHT xxx 42.942337
Re: [Flightgear-devel] Many duplicates in the new airport data.
Yes, there are some inconsistancies with Robin's latest data ... many of these have been reported, hopefully he will clean these up and do a new db release soon. Curt. Chris Metzler wrote: Hi. The new airport data has duplicate entries for a lot of airports. It looks like in some cases, data for airports changed -- runways got moved or rotated, new taxiways got added, etc. -- so an entire new set of data for the airport went in, while the old one was still listed. There are some duplicates that look exactly the same -- perhaps they changed in something not listed in runways.dat, such as their radio freqs. This is not simply duplicate use of the ZZ identifiers, but actual full airports that are in there twice. I don't know whether duplication where the position is exactly the same is an issue. But there are places where things aren't the same in the layout. KMHT (see example below) is gonna look a mess with its old and new runway lengths and orientations, and two sets of taxiways superimposed and offset. Just a heads up . . . -c A KMHT 266 CYY Manchester R KMHT 06 42.935836 -71.439677 42.33 6841 150 NAPHN NYNN00 NYPN 00 T KMHT xxx 42.931114 -71.431625 156.00 4300 130 YAB T KMHT xxx 42.925583 -71.436569 66.00 4000 130 YAB T KMHT xxx 42.931805 -71.435310 156.00 4000 110 YAB T KMHT xxx 42.931263 -71.430687 156.10 2670 380 NCN T KMHT xxx 42.940689 -71.431801 43.00 2200 120 YAB T KMHT xxx 42.926876 -71.438171 64.00 1900 700 YCB T KMHT xxx 42.929546 -71.433479 68.00 1800 130 YAB T KMHT xxx 42.932934 -71.437500 158.00 1700 290 YCB T KMHT xxx 42.927471 -71.443481 106.00 1630 150 YAB T KMHT xxx 42.925320 -71.431679 116.00 1600 220 YAB T KMHT xxx 42.940266 -71.436165 144.00 1500 120 YAB T KMHT xxx 42.935638 -71.436806 66.00 1260 130 YAB T KMHT xxx 42.929443 -71.436340 0.00 1100 300 YCB T KMHT xxx 42.925850 -71.441040 153.00 1050 220 YAB T KMHT xxx 42.923245 -71.442749 138.00 1000 500 NCN T KMHT xxx 42.937389 -71.434685 6.00 1000 150 YAB T KMHT xxx 42.932259 -71.433815 95.30 1000 120 YAB T KMHT xxx 42.925449 -71.436043 133.00 850 100 YAB T KMHT xxx 42.935490 -71.438438 116.00 700 120 YAB T KMHT xxx 42.925133 -71.428879 16.00 700 120 YAB T KMHT xxx 42.941887 -71.436493 18.00 660 110 YAB T KMHT xxx 42.924339 -71.438042 66.00 600 400 NCN T KMHT xxx 42.943146 -71.436714 157.00 600 300 NCN T KMHT xxx 42.928639 -71.447319 129.00 600 120 YAB T KMHT xxx 42.924458 -71.431519 62.00 600 100 YAB T KMHT xxx 42.941704 -71.438599 68.00 570 110 YAB T KMHT xxx 42.924015 -71.432846 66.00 500 400 NCN T KMHT xxx 42.924572 -71.435051 90.00 500 380 NCN T KMHT xxx 42.927948 -71.447006 78.00 500 130 YAB T KMHT xxx 42.925495 -71.433723 36.00 500 100 YAB T KMHT xxx 42.928154 -71.448319 130.00 440 130 YAB T KMHT xxx 42.943142 -71.429634 135.00 400 120 YAB T KMHT xxx 42.942337 -71.430580 131.00 400 120 YAB C 42.933514 -71.439232 0 B 42.936390 -71.440507 1 W 42.929454 -71.449136 1 W 42.942218 -71.430215 1 [ snip -- Manchester, England's airport is inbetween ] A KMHT 266 CYY Manchester R KMHT 17 42.930124 -71.432686 156.59 9244 150 YAPHN YYPS 3330 YYPC 8500 T KMHT xxx 42.931114 -71.431625 156.00 4300 130 YAB T KMHT xxx 42.925583 -71.436569 66.00 4000 130 YAB T KMHT xxx 42.931805 -71.435310 156.00 4000 110 YAB T KMHT xxx 42.931263 -71.430687 156.10 2670 380 NCN T KMHT xxx 42.940689 -71.431801 43.00 2200 120 YAB T KMHT xxx 42.926876 -71.438171 64.00 1900 700 YCB T KMHT xxx 42.929546 -71.433479 68.00 1800 130 YAB T KMHT xxx 42.932934 -71.437500 158.00 1700 290 YCB T KMHT xxx 42.927471 -71.443481 106.00 1630 150 YAB T KMHT xxx 42.925320 -71.431679 116.00 1600 220 YAB T KMHT xxx 42.940266 -71.436165 144.00 1500 120 YAB T KMHT xxx 42.935638 -71.436806 66.00 1260 130 YAB T KMHT xxx 42.929443 -71.436340 0.00 1100 300 YCB T KMHT xxx 42.925850 -71.441040 153.00 1050 220 YAB T KMHT xxx 42.923245 -71.442749 138.00 1000 500 NCN T KMHT xxx 42.937389 -71.434685 6.00 1000 150 YAB T KMHT xxx 42.932259 -71.433815 95.30 1000 120 YAB T KMHT xxx 42.925449 -71.436043 133.00 850 100 YAB T KMHT xxx 42.935490 -71.438438 116.00 700 120 YAB T KMHT xxx 42.925133 -71.428879 16.00 700 120 YAB T KMHT xxx 42.941887 -71.436493 18.00 660 110 YAB T KMHT xxx 42.924339 -71.438042 66.00 600 400 NCN T KMHT xxx 42.943146 -71.436714 157.00 600 300 NCN T KMHT xxx 42.928639 -71.447319 129.00 600 120 YAB T KMHT xxx 42.924458 -71.431519 62.00 600 100 YAB T KMHT xxx 42.941704 -71.438599 68.00 570 110 YAB T KMHT xxx 42.924015 -71.432846 66.00 500 400 NCN T KMHT xxx 42.924572 -71.435051 90.00 500 380 NCN T KMHT xxx 42.927948 -71.447006 78.00 500 130 YAB T KMHT
[Flightgear-devel] Chris Waltham on Aeronautics and Fluids
A couple of interesting 'links' here http://www.physics.ubc.ca/%7Ewaltham/aero.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
On Wednesday 26 May 2004 19:15, David Megginson wrote: The reason they don't work in real life is that everyone is flying at a different speed. There's typically one STAR for every arrival direction (often centred around a major intersection or navaid), but ATC has IFR traffic ranging from 100 kt Cherokee 140s to 180 kt twins and turboprops to jets flying just barely under the 250 kt low-altitude limit (or not, in the case of some military jets). They also have to get departures off the runway in-between arrivals. Obviously, they cannot send us all in on the same route even if the STAR does have separate altitudes for jets and props, so the STAR usually gets abandoned not long after the initial fix. Jets and turboprops typically get vectored to a long final (say, 15 nm or more), while slow twins and singles get turned in just before (or sometimes on top of) the final approach fix so that they'll spend the minimum amount of time clogging up approach path. David, Thanks for your real-life perspective. Let me just add a little bit of back ground information about my request and add a little bit of a perspective from a software development point of view. During the last couple of weeks, I finished a first draft of a traffic manager for FlightGear. The traffic manager is a subsystem that generates AI Aircraft, by calling David Culp's AIModel code. Curently, this is done on the basis of a time table stored in a database, but this could be easily be expanded to randomly, or heuristically generated traffic. David and I have exchanged some ideas on how to integrate the traffic manager with the AIModel system, and in the mean time, David Luff and I have talked about some possibilities of implementing ATC in this system (Please correct me if I'm wrong guys). So, initially I proposed to develop the FlightGear AI traffic system roughly guided by the following schedule, or at least that's probably how I would approach the problem if I had to do this myself. 1: Write a top level traffic manager 2: Make sure the traffic manager can create AI Aircraft entities (for visuals, radar contact, and a more detailed simulation of the route taken). 3: Make sure the whole system works without worrying about the details (e.g., separation conflicts, parking problems, or approaches and departures. Just let every aircraft make a straight out straight in) 4: Add SID/STAR support 5: Add code to detect and predict separation conflicts. 6: Add support for more sophisticated parking/taxiing. 7: Add FIR support With each additional step, the system would become more complex and add sophistication. Also, the role of air traffic control would become more sophisticated with each additional step. However, as reality turns out to be more diverse and complex than schedules, I'm currently working pretty much on points 1 trhough 4 simultaneously. The traffic manager runs fairly well now on my system and it is capable (albeit still very crudely), of communicating with the AIModel code. There are a few issues that we need to solve, but in my opinion this could be done best after I've submitted the initial code, because then all parties involved can have a look at it. Point three, is the one that I'm currently spending most of my evening hours on. All the flights that I've listed sofar in the traffic manager's database require a flight plan, and I still need to create a few of these . In future versions, it's likely that a lot of these flightplans can be created dynamically, but we're currenly not yet at that stage. And this is also where my question came from: We need to create these plans anyhow, so if we could pick the approaches or departures from a database, instead of hand typing them, that would speed up the development of this system by quite a bit. Now, points 4 and 5, are specifically interesting with regard to your real world experience. The way I currently see AI traffc in FlightGear is that it is accomplished by three subsystems running in parrallel. The first system is the traffic manager, which determines when and where traffic should be generated. The second system is the AI Model manager, which actually generates the aircraft, and flies it according to the flight plan it has been assigned. The third subsystem, the ATC manager, has the important role of monitoring all traffic and the authority to modify the routes taken by each AI aircraft, for example by changing it's waypoints. If properly implimented, and provided that the combined IQ of this developers list can make the ATC manager smart enough, this could then lead to the situation that you describe: The standard procedures are a theoretical requirement, but in practice, more often than not, the ATC module decides to give instructions that are more appropriate for the local situation. However, until we are at that point of sophistication, I would rather see some standard approach and departure patterns
Re: [Flightgear-devel] SID, STAR, and airway data
Durk Talsma wrote: However, until we are at that point of sophistication, I would rather see some standard approach and departure patterns being used than nothing at all. I agree. Unfortunately, you will find that many SIDs consist of something along the lines of - fly runway heading - maintain 3,000 ft unless otherwise advised by ATC - expect vectors on course Similarily, many STARs simply provide an altitude and a starting point, and then state that the pilot should expect vectors to the runway. Neither will be too useful for AI work, I'm afraid. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Deb-a-day reference to FGFS
http://www.livejournal.com/users/debaday/ Tuesday, May 25th, 2004 flightgear - Flight Gear Flight Simulator This thing is huge. This package comes to our attention from Paul, a student at Griffith University in Australia. Paul says that this very large OpenGL flight simulator requires eleven CDROMs worth of data to deliver all of the world scenery. Check out the package dependencies: libc6, libgcc1, libglut3, libstdc++5, plib1c102, simgear0, libgl1, libglu1, xlibs, zlib1g, and fgfs-base. That's a lot of heavy duty stuff for someone like me who runs headless Debian servers for living. The upstream source for this package can be found on SourceForge. Note that the package description doesn't really help with making the decision on whether you'll want to install this or not: Flight Gear is a free and highly sophisticated flight simulator. This package contains the runtime binaries. But checkout the upstream source for pretty pictures. I'm going to try it out on Mac OS X myself. More information on this package can be found on the Debian web site. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Deb-a-day reference to FGFS
On Wed, 26 May 2004 14:32:43 -0700 (PDT), Alex wrote in message [EMAIL PROTECTED]: http://www.livejournal.com/users/debaday/ ..they've also done whitespace. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Many duplicates in the new airport data.
On Wed, 26 May 2004 14:47:36 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Yes, there are some inconsistancies with Robin's latest data ... many of these have been reported, hopefully he will clean these up and do a new db release soon. Thanks, sorry, didn't know these were known . . . -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 pgp4j3K7bP8P5.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] itoa? sprintf?
What is the best way (most supported, cross-platform) to turn an integer into an STL string type? Or, even an ASCII char[]? It seems that itoa() is not totally common. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] keyboard mapping
Hi Josh Josh Babcock writes I think that there is already stuff out there that does not conform to this, but if enough people here agree, I would be happy to chase down all those potential conflicts and mitigate them. I think that would be a good idea there seems to be enough room on the keyboard to keep every one happy. Then the modelers would know what keys they could use without running the risk of screwing up other parts of the keyboard. Josh Cheers Innis _ Play Origin SMS footy trivia to win $5k. Go to http://mobilecentral.ninemsn.com.au/mcheadtohead/home.aspx ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] itoa? sprintf?
Jon Berndt wrote: What is the best way (most supported, cross-platform) to turn an integer into an STL string type? Or, even an ASCII char[]? It seems that itoa() is not totally common. snprintf() is in ISO C99 but not ANSI C -- you could check to see if all of the target platforms have it. ANSI C sprintf() should also be OK, since you can predict the maximum length for an integer, but the security heads might want to chime in here. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
