Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
On 1/15/03 at 6:20 PM Bernie Bright wrote: >On Wed, 15 Jan 2003 01:45:30 + >"David Luff" <[EMAIL PROTECTED]> wrote: > >[snip] > >> ... FWIW I'm currently writing a >> program to allow the laying out of a logical taxiway and parking place >> network for AI planes to follow over an image of Flightgear's rendered >taxi >> and runways by clicking on it where intersections etc are wanted. > >The FS2002 crowd have a freeware utility called AFCAD that performs a >similar >task. It produces a structured text output file. If we could import >such a file then we could leverage a lot of existing taxiway maps for AI >traffic. That looks pretty similar to what I've been aiming for (screenshot of current progress at http://www.nottingham.ac.uk/~eazdluf/taxidraw.jpg - and yes I know its currently windoze only - its just a fast prototype proof-of-concept and I'll port it to a multiplatform toolkit if it works). It would certainly make sense to be able to import AFCAD files. However, there may be issues concerning whether the airports are placed in exactly the same location in FS2K2 and FGFS, and as regards the files, even if permission could be obtained from some authors to use their files, I would have thought that we would have to make absolutely sure that these represented their original creation, and were not an extension/modification of the FS2K2 original. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
Jon Stockill writes: > > Then, late, you can specify rules for which ones get included or > > excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are > > treated as different, mutually-exclusive airports). > > Hmmm It seems like that's just putting off the problem - but it would > mean we could actually get the data in the system. Actually, it's a virtuous circle -- it puts off the problem *and* it's The Right Way To Do It (at least, it's the way a good DBA would handle it). Never pour concrete all over your data until the last possible second. You can create a third table of virtual airports pointing to either the DAFIF or the XPlane description for each one, and this table can be manually tweaked to refine the automatic merge. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
David Luff writes: > Yes, the x-plane way really screws the rendering up now that yellow > lines are added. However, the amount of work that has gone into > specifying the taxiways and aprons at major airports must be *huge* > - it would take a long time to replicate it with a better system. Agreed -- we would need to support both, probably for a very long time. We could probably extract some intelligence from the X-plane scheme automatically, but we would still need a lot of hand-tweaking. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On Tue, 14 Jan 2003, David Megginson wrote: > Then, late, you can specify rules for which ones get included or > excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are > treated as different, mutually-exclusive airports). Hmmm It seems like that's just putting off the problem - but it would mean we could actually get the data in the system. > For now, let's just get all the airports in. The way that X-Plane > implements taxiways is just horrible -- aprons are just wide taxiways, > for example, and taxiways are always rectangles run together. Perhaps > we'll be able to think of a better system. OK, I'll work on that this evening then. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On Tue, 14 Jan 2003, David Megginson wrote: > We also have fields for this information in the current default.apt > data, but they don't seem to be filled in. Some of the UK ones certainly are. EGNM for example. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE:[Flightgear-devel] Roadmap/brain dump)
On Wed, 15 Jan 2003 01:45:30 + "David Luff" <[EMAIL PROTECTED]> wrote: [snip] > ... FWIW I'm currently writing a > program to allow the laying out of a logical taxiway and parking place > network for AI planes to follow over an image of Flightgear's rendered taxi > and runways by clicking on it where intersections etc are wanted. The FS2002 crowd have a freeware utility called AFCAD that performs a similar task. It produces a structured text output file. If we could import such a file then we could leverage a lot of existing taxiway maps for AI traffic. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
David Luff writes: > > I believe his intention/achievement > is to allow the editing of scenery superimposed over calibrated maps or > ariel photos, which would ease the task of getting the aprons/taxiways etc > in the right place. I can heartily reccomend two OpenSource packages for doing this OpenEV http://openev.sf.net OSSIM http://www.ossim.org For those into scriptable interfaces OpenEV should a treat. OSSIM is a bit more of a bear to get your head around but worth it if you want to mossaic Imagery from different sources They both have excellent shapefile support and support most of the standard raster based formats. For those on Win32 the VTerrain package has a program that can assist in automatically extracting buildings from DRGs http://www.vterrain.org/Implementation/Apps/BExtractor/index.html and another to assist in laying out the final model, roads buildings airports ect, http://www.vterrain.org/Implementation/Apps/VTBuilder/index.html Both of these programs store their results in XML files built using SimGear's EasyXML package so we should have no problem translating them Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
On 1/14/03 at 8:11 PM David Megginson wrote: >For now, let's just get all the airports in. The way that X-Plane >implements taxiways is just horrible -- aprons are just wide taxiways, >for example, and taxiways are always rectangles run together. Perhaps >we'll be able to think of a better system. > Yes, the x-plane way really screws the rendering up now that yellow lines are added. However, the amount of work that has gone into specifying the taxiways and aprons at major airports must be *huge* - it would take a long time to replicate it with a better system. FWIW I'm currently writing a program to allow the laying out of a logical taxiway and parking place network for AI planes to follow over an image of Flightgear's rendered taxi and runways by clicking on it where intersections etc are wanted. I'm sure this could eventually be extended to allow the layout of taxiway and apron polygons which could then be fed into Terragear as area polygons. Alternatively Frederic's fgsd might be another possible tool for the job - although I haven't got it running yet I believe his intention/achievement is to allow the editing of scenery superimposed over calibrated maps or ariel photos, which would ease the task of getting the aprons/taxiways etc in the right place. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
David Luff writes: > Yep, here's my stats from the program I ran to compare the databases when I > imported the atis data: > > *** STATS *** > 9873 airports in DAFIF > 16937 airports in default.apt > 1384 airports had K added to match default.apt Also note that the Alaska and Hawaii airports have a "P" prepended (PANC, PHNL) > 2 airports had a letter removed to match default.apt > 4057 airports could not be matched with default.apt > 1077 of these had no valid ICAO code or FAA host ID > * > 1247 airports with ATIS > 22567 records in com file without ATIS > 0 airports had ATIS but could not be found in the map > 98 airports with ATIS had K added to match default.apt > 2 airports with ATIS had a letter removed to match default.apt > 202 airports with ATIS could not be matched with default.apt > Total of 1045 airports added to default.atis > Total of 1286 unique ATIS frequency/locations written > done > > > Note that that's not the most recent Dafif though. Typically a lot of US > airfields needed K added to a 3 letter identifier in the Dafif to match > default.apt. I've attached the program I wrote to go through it - its very > very rough but may give you some ideas. Note that you have to be carefull > with munging identifiers to fit the two data sources - of the 6 airports > which could be matched from a 4 letter Dafif code to a 3 letter default.apt > code, only 2 of them were actually the same airfield. A similar caution > probably applies to adding 'K' - it'd be worth checking the Dafif country > code to ensure its a US airfield you're doing it to. > > > > >Also, how do we want to handle updates - I can track how everything was > >last updated now, so from an initial import of the xplane database I can > >update it with DAFIF, *but* since the DAFIF info has no taxiway data, if > >the runway positions get changed slightly the taxiways won't line up. > >Updating *only* fields with no taxiway info, or which were last > >updated/created by DAFIF data is possible. Manual updates are another > >problem - if someone goes to the effort of correcting data then we don't > >want to overwrite it with potentially less accurate info from one of the > >databases. > > > >If anyone has any ideas on how we should prioritise the information then > >I'd be very interested in hearing your ideas. > > > > Hmm, its a bit late (1.30am) to think about all that stuff now, but believe > me, you've taken on a huge, but extremely important job. I'd say maintain > multiple entries for each airfield if necessary - xplane, Dafif and manual, > and then a choice can be made at render time which to use. I'd suggest > that basics are to allow manual entries/corrections to be made which aren't > overwritten by x-plane/Dafif updates, to allow xplane/Dafif updates, and to > track where entries come from. Have fun!!! > > Cheers - Dave > > -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
On 1/15/03 at 12:39 AM Jon Stockill wrote: >On the subject of runways - I've been working on the database today. > >I can import and export the xplane database, and have some code which >parses the DAFIFT data, and compares it with the existing database, >however: > >1. Not all airfields in the xplane database are in DAFIF >2. Not all DAFIF airfields are in xplane >therefore >3. There's no single common identifier for a field Yep, here's my stats from the program I ran to compare the databases when I imported the atis data: *** STATS *** 9873 airports in DAFIF 16937 airports in default.apt 1384 airports had K added to match default.apt 2 airports had a letter removed to match default.apt 4057 airports could not be matched with default.apt 1077 of these had no valid ICAO code or FAA host ID * 1247 airports with ATIS 22567 records in com file without ATIS 0 airports had ATIS but could not be found in the map 98 airports with ATIS had K added to match default.apt 2 airports with ATIS had a letter removed to match default.apt 202 airports with ATIS could not be matched with default.apt Total of 1045 airports added to default.atis Total of 1286 unique ATIS frequency/locations written done Note that that's not the most recent Dafif though. Typically a lot of US airfields needed K added to a 3 letter identifier in the Dafif to match default.apt. I've attached the program I wrote to go through it - its very very rough but may give you some ideas. Note that you have to be carefull with munging identifiers to fit the two data sources - of the 6 airports which could be matched from a 4 letter Dafif code to a 3 letter default.apt code, only 2 of them were actually the same airfield. A similar caution probably applies to adding 'K' - it'd be worth checking the Dafif country code to ensure its a US airfield you're doing it to. > >Also, how do we want to handle updates - I can track how everything was >last updated now, so from an initial import of the xplane database I can >update it with DAFIF, *but* since the DAFIF info has no taxiway data, if >the runway positions get changed slightly the taxiways won't line up. >Updating *only* fields with no taxiway info, or which were last >updated/created by DAFIF data is possible. Manual updates are another >problem - if someone goes to the effort of correcting data then we don't >want to overwrite it with potentially less accurate info from one of the >databases. > >If anyone has any ideas on how we should prioritise the information then >I'd be very interested in hearing your ideas. > Hmm, its a bit late (1.30am) to think about all that stuff now, but believe me, you've taken on a huge, but extremely important job. I'd say maintain multiple entries for each airfield if necessary - xplane, Dafif and manual, and then a choice can be made at render time which to use. I'd suggest that basics are to allow manual entries/corrections to be made which aren't overwritten by x-plane/Dafif updates, to allow xplane/Dafif updates, and to track where entries come from. Have fun!!! Cheers - Dave parsedafif.zip Description: Zip compressed data
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
Jon Stockill writes: > I can import and export the xplane database, and have some code which > parses the DAFIFT data, and compares it with the existing database, > however: > > 1. Not all airfields in the xplane database are in DAFIF > 2. Not all DAFIF airfields are in xplane > therefore > 3. There's no single common identifier for a field Welcome to the joys of data management. I recommend putting all of the DAFIF airports in separately for now, with a different "source" field: source = xplane source = dafif Then, late, you can specify rules for which ones get included or excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are treated as different, mutually-exclusive airports). > Also, how do we want to handle updates - I can track how everything > was last updated now, so from an initial import of the xplane > database I can update it with DAFIF, *but* since the DAFIF info has > no taxiway data, if the runway positions get changed slightly the > taxiways won't line up. Updating *only* fields with no taxiway > info, or which were last updated/created by DAFIF data is > possible. Manual updates are another problem - if someone goes to > the effort of correcting data then we don't want to overwrite it > with potentially less accurate info from one of the databases. > > If anyone has any ideas on how we should prioritise the information then > I'd be very interested in hearing your ideas. For now, let's just get all the airports in. The way that X-Plane implements taxiways is just horrible -- aprons are just wide taxiways, for example, and taxiways are always rectangles run together. Perhaps we'll be able to think of a better system. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
David Luff writes: > >David Luff writes: > >> and I'd have thought that displaced thesholds and the arrows > >> pointing to them would have to be pretty high on the list of > >> features that would be expected to make it in. > > > >Do we actually have these in our airport data? If so (or if the data > >could be added) I'd be willing to work on it. The airport code is > >still relatively fresh in my mind. > > Got it. The Dafif has separate landing and takeoff distances for each > direction of each runway, and on the airports/runways I've looked at (in > the UK) these seem to correspond to the displaced thresholds. We also have fields for this information in the current default.apt data, but they don't seem to be filled in. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On Tue, 14 Jan 2003, David Luff wrote: > Got it. The Dafif has separate landing and takeoff distances for each > direction of each runway, and on the airports/runways I've looked at (in > the UK) these seem to correspond to the displaced thresholds. To be quite > honest I never realised one could use the bit with the arrows for takeoff, > although thinking about it it wouldn't make sense not to. Anyway, if you > let me know what format the data would be most useful in, then I'll write a > program to extract it from the Dafif and convert it to your preferred > format. On the subject of runways - I've been working on the database today. I can import and export the xplane database, and have some code which parses the DAFIFT data, and compares it with the existing database, however: 1. Not all airfields in the xplane database are in DAFIF 2. Not all DAFIF airfields are in xplane therefore 3. There's no single common identifier for a field Also, how do we want to handle updates - I can track how everything was last updated now, so from an initial import of the xplane database I can update it with DAFIF, *but* since the DAFIF info has no taxiway data, if the runway positions get changed slightly the taxiways won't line up. Updating *only* fields with no taxiway info, or which were last updated/created by DAFIF data is possible. Manual updates are another problem - if someone goes to the effort of correcting data then we don't want to overwrite it with potentially less accurate info from one of the databases. If anyone has any ideas on how we should prioritise the information then I'd be very interested in hearing your ideas. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
