Re: [Flightgear-devel] [Flightgear-users] Traffic Manager II
Hi Greg, On Monday 28 July 2008 17:13, Greg Hawkes wrote: My biggest problem with FlightGear's AI traffic is not the complexity of the XML files, nor the need to assign individual aircraft to flights (although anything that reduces that complexity is good). Instead, the biggest issue that I can see is that there is no way for FlightGear users to share their flight patterns with each other. Thanks for your comments. Actually, this problem is actually one of the reasons that prompted me to take action and try to devise a simpler approach. [ SNIP] One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, 2) distributing it will be a large download, and 3) I don't want my CPU burning cycles to simulate traffic on the other side of the world. Just a few random thoughts: Re: 1). Having something like a web based application, where users can commit their favorite flights, and / or remove them from the database might work here. Admittedly, entering all that data is going to be a huge job. I just downloaded the current KLM time table, and it's approximatle 150 pages, small print and two columns per page. The new format for the traffic manger is very close to that of an airline time table, so that would make it a lot easier to enter the data (i.e. no more rigid scheduling). I'm really happy that Jon Stockill is checking into this. Admittedly, I'm not much of a web application programmer, so my input in this side of things is rather limited. 2). This might not be too bad actually, especially when the output data can be compressed. The new format is quite efficient in storing flight data. :-) 3). That is never going to happen by design of the traffic manager. Only flights that are in close range are being tracked using an AIModels simulation. In traffic manager terms, each aircraft is considered to be a schedule, where flights can be added to. Distant traffic is kept in memory in the form of such a schedule, and the position of each of these (on the basis of the loaded flights) is approximated at a modest rate of one per frame. So the more traffic you add, the longer the update cycle becomes. This doesn't have any impact on performance though... :-) Of course, what I really want is to fly from anywhere to anywhere, and to see all of the corresponding air traffic along the way. Updated automatically, and in real-time. Could you add that to your to-do list, please? :-) Provided that we can assemble enough man power to build these schedules, this can already be done. :-) Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Traffic Manager II
Durk Talsma wrote: So what is traffic manager II? Well the main difference is that it will become a lot easier for users to develop their own traffic. Instead of going through a complicated procedure of compiling a sequence of flights into an xml file, the new version just requires a plain text file that specifies which aircraft are available and which flights are required to be operated. Hi Durk, My biggest problem with FlightGear's AI traffic is not the complexity of the XML files, nor the need to assign individual aircraft to flights (although anything that reduces that complexity is good). Instead, the biggest issue that I can see is that there is no way for FlightGear users to share their flight patterns with each other. For example, my local airport is Melbourne's Tullamarine (YMML), and I can create AI flights from Tullamarine to various Australian and international destinations. There are other FlightGear users modelling flights arriving at their local airports, some of which will correspond to the flights that I have modelled leaving from Tullamarine. There is no way for those users to access the flights that I have created. This means that each user creates their own AI traffic XML database, without the ability to share their efforts with other users. One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, 2) distributing it will be a large download, and 3) I don't want my CPU burning cycles to simulate traffic on the other side of the world. Another solution is similar to this, but to download only those flights for a specific airport -- or maybe for a specific region. A third idea is to download flights only for a set of airports (for example, only those airports that I frequent). Of course, what I really want is to fly from anywhere to anywhere, and to see all of the corresponding air traffic along the way. Updated automatically, and in real-time. Could you add that to your to-do list, please? :-) Regards, Greg Hawkes - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Traffic Manager II
Greg Hawkes wrote: One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, [...] I certainly don't want to cross Durk's plans. Nevertheless, given the case that Durk _does_ come to the conclusion, that having such a shared database of AI flight plans is a solution, then I think we should manage to co-locate such a DB at the given infrastructure and share the workload of maintenance among the involved people Your name is noted ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Traffic Manager II
Martin Spott wrote: Greg Hawkes wrote: One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, [...] I certainly don't want to cross Durk's plans. Nevertheless, given the case that Durk _does_ come to the conclusion, that having such a shared database of AI flight plans is a solution, then I think we should manage to co-locate such a DB at the given infrastructure and share the workload of maintenance among the involved people Your name is noted ;-) I'd started work on a db based on the current traffic manager requirements, and it was all getting rather complex. The changes you've mentioned would appear to simplify the database requirements somewhat, so I'd be happy to add something onto the scenery db system to support it. I doubt I have the time to maintain it though, so if someone wants to volunteer to keep an eye on things and prod me when changes to the db structure or front end are required then it'll make best use of the time I have available. Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
