Board index FlightGear Development

web GIS talking to FG to display traffic in (near) real time

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

web GIS talking to FG to display traffic in (near) real time

Postby bluecap » Thu Dec 20, 2018 7:55 pm

Hello to everyone,

I am very very new in this interesting simulator and I am amazed at the programming depth provided.

I've been thinking of developing an application basically with the following components:
- A web GIS (website) with an airport map (JQuery, Openlayers w/ static maps, PHP, Mapserver etc).
- Some traffic (aircraft, vehicles etc) displayed on the map, which I will select and give instructions (pushback, taxi, land, take off etc). The traffic commands will be appended to a file of sorts.
- FG that will display all this traffic from the position of a control tower while the commands are given in almost real time with AI traffic.

I can do the first 2 fairly easily I think. I'd like to have some "high-level" pointers of where to start looking regarding FG's interface to this. Eg should I use Nasal?

Thank you.
bluecap
 
Posts: 3
Joined: Wed Dec 19, 2018 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby Hooray » Thu Dec 20, 2018 8:59 pm

Hi & welcome,

here are a few more pointers:

http://wiki.flightgear.org/MPMap
http://wiki.flightgear.org/Howto:Making ... from_Nasal

Note that there is a dedicated mongoose based websocket interface, used by Phi: http://wiki.flightgear.org/Phi
Also, Nasal has dedicated http support - made available via the http namespace. Examples on using that can be commonly found in moving map code accessing tile servers to retrieve charts on demand.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby bluecap » Fri Dec 21, 2018 9:23 am

Thank you very much for the pointers!
bluecap
 
Posts: 3
Joined: Wed Dec 19, 2018 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby Hooray » Fri Dec 21, 2018 12:36 pm

To learn more about FlightGear's way of accessing web GIS imagery, you'd either want to look at Phi (DHTML / browser based, served by FlightGear), or look at FlightGear's 2D drawing system, which is called "Canvas" - it's primarily accessed by the built-in scripting language "Nasal".

Stuart is the one who implemented support for slippy maps, as part of his ongoing FG1000 effort:
http://wiki.flightgear.org/Canvas_News# ... lippy_Maps
Image
Image

Usually, you will want to use Nasal/Canvas for anything that you want to display/run inside the sim (main loop), whereas you want to use Phi for stuff that can/should run outside the main loop.

However, there are also ways to serve a Canvas to the browser (this has meanwhile been merged by Torsten):

http://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image


The last screen shot shows a moving map display (ND) created/rendered by FlightGear using Nasal+Canvas, and streamed over http to an instance of firefox.

Depending on your background and priorities, you can probably see by now how to implement your own idea.
If it's going to use Nasal and Canvas, you might want to consider creating a corresponding "addon" using the new addon framework.

bluecap wrote in Thu Dec 20, 2018 7:55 pm:- Some traffic (aircraft, vehicles etc) displayed on the map, which I will select and give instructions (pushback, taxi, land, take off etc). The traffic commands will be appended to a file of sorts.

I'D suggest, to also look at: http://wiki.flightgear.org/Ground_Services
Image

- FG that will display all this traffic from the position of a control tower while the commands are given in almost real time with AI traffic.


Rleibner has created a similar addon using Nasal and Canvas, for doing "GCAs" (ground controlled approaches):
http://wiki.flightgear.org/Spoken_GCA
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby Hooray » Fri Dec 21, 2018 2:14 pm

For the 2nd component of your project, let's called it the "traffic generator", there are also different ways to accomplish this.
But how to proceed with this, depends highly on your requirements. For example, if you want this to work in multi-instance setups (multiplayer, or local multi-instance fgfs setups), you will almost certainly want to use the existing multiplayer system - because there is otherwise no straightforward mechanism in place to sync/replicate scripted "traffic" across multiple fgfs instances.

When using the multiplayer system, the most straightforward mechanism is to simply "inject" your own "traffic feed" into the multiplayer server environment (fgms) via the "multiplayer protocol" - alternatively, if you able/willing to patch/rebuild fgfs or fgms from source, you could also use a modified multiplayer server and/or a custom MP protocol.

If you don't need multi-instance support, you could also use scripted AI traffic using just Nasal, we do have quite a few existing scripts doing this sort of things, some rather simple and others that have grown pretty complex over the years.

Either way, it would make sense to look at "atcpie" for anything involving multiplayer-based traffic injection, or "tanker.nas" for anything involving Nasal based (scripted) AI traffic.

http://wiki.flightgear.org/ATC-pie
Image

For the scripted option, numerous pointers can be found in any recent topic mentioning "scripted tanker", for example:

viewtopic.php?f=25&t=35004
viewtopic.php?f=40&t=35012


PS: Quoted keywords are suitable search terms for the forum/wiki respectively.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby legoboyvdlp » Fri Dec 21, 2018 2:21 pm

I'm not sure its fair on the server hosters to inject traffic into their servers. Instead, it should be possible to inject traffic onto a server hosted locally, meaning that the multiplayer servers are not overloaded.
User avatar
legoboyvdlp
 
Posts: 6840
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: web GIS talking to FG to display traffic in (near) real

Postby Hooray » Fri Dec 21, 2018 2:41 pm

Actually, I wasn't referring to any of the public MP servers - as a matter of fact, it's a common thing to set up your own MP/multi-instance environment for training purposes anyway. And it may even make sense to modify fgms accordingly, or even just use the protocol and a scripted fgms equivalent (the fgms maintenance status and code base being what it is).

Apart from that, I seem to recall that either ATC-Pie or OpenRadar (or both) had such a "traffic injection" mechanism already, based on creating custom MP packets for virtual clients, which makes sense from training standpoint.

That being said, you don't even need fgms for that to work.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby bluecap » Fri Dec 21, 2018 6:33 pm

These are very good ideas, thank you again, and I'll start studying the various subsystems all of you have proposed to get an idea of the way they do stuff I want to implement.

What I had been thinking was something like this (where "traffic" read aircraft/vehicles):

I will build a website with a static map (free satellite data), showing an airport (let's say 2 or 3 tile-style zoom levels) based on technologies I know well about (Openlayers, PHP etc). I'll build some layers for stuff like: parking positions, taxi routes, runway centerlines etc, for snapping user-drawn routes of the traffic. On that map I will inject traffic and I will control it with simple Openlayers draw functions.

Every traffic injected will have some basic data about its specific characteristics, eg turn radius/speed margins, takeoff/landing speed/margins etc.

The idea is for a user to be able to give commands to traffic (eg: draw a route/"vector" on map, change altitude/speed, instruct to land/take off/go around etc) with a simple and straightforward way. The commands could also be given by more than one client, eg one showing the airport at a large zoom level, the other showing it zoomed out. All pretty straightforward up to this point.

Now, every time the user gives a command that alters the position or another characteristic of a specific traffic, this data will be be stored to a file on the server for:
- updating the traffic on all clients (obviously)
- replaying
- used by a FG instance (or more!) to actually show this change.

For starters I think that a 1/3 sec refresh rate will be enough, but don't know if it'll work. Even if everything is on the same LAN there are concurrency issues that I haven't thought of yet, so I'd been thinking that all visual results (FG) should be displayed with a very small delay used to "harmonize" all client commands.

Anyway, reading and thinking, thank you all for your help. I've seen that parts of what I'm describing have already been implemented, so they'll help me a lot.
bluecap
 
Posts: 3
Joined: Wed Dec 19, 2018 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby Hooray » Fri Dec 21, 2018 7:46 pm

Okay, I see - thanks for providing a little more information.

I think you might want to start a wiki article to introduce your idea there, and maybe add your findings to it over time, i.e. to document your whole journey there.

The point being that these projects tend to take time, and it is usually considered unfriendly to newcomers to "search the forum" or "search the mailing list". Whereas telling people to look at the wiki for additional pointers/ideas or code snippets/patches does seem to work surprisingly well.

As a matter of fact, I would suggest to see for yourself, if you'd rather be told to "use the forum search" or look at the wiki, so that you can make up your own mind whether it's worth the hassle or not.

Speaking in general, you are right that there are already many existing components in place for this, but depending on what exactly you have in mind, they may be lacking integration for the time being, or may not even be particularly compatible at the moment.

Personally, I have found the wiki to work exceptionally well - even if it's just to be used as a "dump space" to juggle different ideas while evaluating the current situation. I've seen a number of people and efforts that ended up using the wiki to do a "brainstorming", and even when/if things would ultimately stall (or just fail), such "brainstormings" can still be tremendously useful to people wanting to do similar things some time in the future (possibly months or even years after someone has moved onto other projects).

As far as I can tell, how to proceed from here on depends highly on a number of concrete questions, such as:

- if you'd like this to be specific to FlightGear or possibly other flight simulators ?
- if you would like to "control" more than a single fgfs instance ?
- if fgfs is intended to be only used for visualization purposes ?
- if you don't mind not using fgfs at all (as in using virtual traffic that may not be driven by an actual flight dynamics engine)
- if you would like to be able to run the front-end without running flightgear (think, a headless traffic server)
- if you need update rates higher than 1-2 hz
- if you want your traffic to be able to use navigation fixes (VORs, DME, waypoints etc)
- if you want your traffic to use flight plans

Admittedly, these questions may seem a bit overwhelming at first - but actually you won't have to look at many of the pointers provided above, simply because depending on the approach used, there are some implicit/inherent restrictions here, i.e. certain approaches are not compatible with certain answers.

Depending on your background, these may be no-brainers (that is, if you are able and willing to patch/rebuild source code), or that may prove to be very real showstoppers.

You are using the terms "traffic injection", and that's actually another good search term for the forum - you will find many topics discussing the pros & cons of the various approaches.

There is a quote-based summary of the limitations of the built-in AI system available here: http://wiki.flightgear.org/Status_of_AI_in_FlightGear

This was originally considered controversial by many contributors, and others suggested a better integrated system: http://wiki.flightgear.org/An_Integrate ... fic_System

To provide another high-level overview covering some of the issues of the built-in "AI traffic system", you can refer to the following wiki article, which sums up issues identified by the core developer who came up with the original AI Traffic System, and who's meanwhile also arrived at the conclusion that it would need to be re-done: http://wiki.flightgear.org/FGTraffic

For anything involving scripted AI objects, you can look at this: http://wiki.flightgear.org/Scripted_AI_Objects

But again, it doesn't make that much sense to really look at all of these pointers without narrowing down your goals/priorities, sharing your background, roadmap/time frame you have in mind - simply because many of these pointers will not make much sense to pursue depending on your ratio of hard/soft goals - so that pursuing a certain approach may sooner or later turn out to be a dead-end, simply because you were not aware of certain issues (showstoppers).

If anything, these pointers are only helpful to provide a little surrounding context to make you aware of what's possible and what isn't. But other than that, I would suggest not to spend that much time digging through all of these unless you seem to have found something that is doing almost exactly what you have in mind. Even then, it may still save you tons of time to ask more specific questions here.
Like you said, many of the things you have in mind, have already been done by people around here - so there is no need to re-invent the wheel.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby mickybadia » Fri Dec 21, 2018 9:32 pm

Hi,
As would be phrased on YouTube: "Hooray brought me here". :-) Thanks for drawing attention.

About the project, it does in a large part look like a description of the ATC-pie solo mode. That is, spawned and simulated traffic, integrated views (radar map; tower view rendered with FG) and acting as an ATC to work the traffic through standard instructions. Hooray posted the link to the project page; you should find what you need starting from there. The comparable project OpenRadar also mentioned in this thread does not provide the solo stuff because it is only concerned with human multi-player, but it does integrate radar and tower view.

However I might have missed the ultimate purpose of your project as you nowhere use the terms "ATC simulation", which capture best what ATC-pie and OpenRadar are about. Feel free to explore and report back.
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Re: web GIS talking to FG to display traffic in (near) real

Postby Hooray » Fri Dec 21, 2018 11:57 pm

Thanks for your feedback, much appreciated!
Regardless of the concrete purpose/use-case, there definitely is some overlap here when it comes to the "traffic generator" component, is this documented anywhere - or rather, are there pointers to its functionality and code/implementation anywhere ?

I suppose you are using a custom component to create MP packets directly ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: web GIS talking to FG to display traffic in (near) real

Postby mickybadia » Mon Dec 24, 2018 10:02 am

The traffic generators in ATC-pie (teacher-controlled traffic in tutoring sessions + AI traffic in solo sessions) both indeed pack ACFT's data into FGMS-formatted "MP packets" to send to the connected FG views. See ext.fgms module if you want code. Besides, both ATC clients do something similar to "connect" (UDP) to FGMS servers: they build MP packets for themselves to send regularly to the server, containing their position and, of course, a zero velocity.
In all of these cases the most useful documentation to know what/how to pack data is that of the MP protocol.
mickybadia
 
Posts: 405
Joined: Tue Sep 24, 2013 9:12 am

Re: web GIS talking to FG to display traffic in (near) real

Postby drR0ckso » Wed Dec 26, 2018 2:18 am

It's also poor form to unleash 17 copies of FlightGear onto a single server:

24.12.2018 17:03:26 New LOCAL Client: EZY48E@xx.xxx.xxx.xxx:51261 (A319) current clients: 42 max: 65
24.12.2018 17:03:26 New LOCAL Client: KLM1608@xx.xxx.xxx.xxx:62558 (B738) current clients: 43 max: 65
24.12.2018 17:03:26 New LOCAL Client: SVA993@xx.xxx.xxx.xxx:59119 (B744) current clients: 44 max: 65
24.12.2018 17:03:26 New LOCAL Client: UAL844@xx.xxx.xxx.xxx:50664 (B773) current clients: 45 max: 65
24.12.2018 17:03:26 New LOCAL Client: DAL74@xx.xxx.xxx.xxx:57504 (B764) current clients: 46 max: 65
24.12.2018 17:03:26 New LOCAL Client: KLM625@xx.xxx.xxx.xxx:65172 (B744) current clients: 47 max: 65
24.12.2018 17:03:26 New LOCAL Client: RYR1136@xx.xxx.xxx.xxx:49785 (B734) current clients: 48 max: 65
24.12.2018 17:03:26 New LOCAL Client: VLG1374@xx.xxx.xxx.xxx:52544 (A320) current clients: 49 max: 65
24.12.2018 17:03:26 New LOCAL Client: MPH7122@xx.xxx.xxx.xxx:53530 (B744) current clients: 50 max: 65
24.12.2018 17:03:26 New LOCAL Client: UAE149@xx.xxx.xxx.xxx:55295 (B773) current clients: 51 max: 65
24.12.2018 17:03:26 New LOCAL Client: SWR40X@xx.xxx.xxx.xxx:58519 (A320) current clients: 52 max: 65
24.12.2018 17:03:26 New LOCAL Client: CCA68@xx.xxx.xxx.xxx:63497 (B744) current clients: 53 max: 65
24.12.2018 17:03:26 New LOCAL Client: DAL422@xx.xxx.xxx.xxx:57006 (B772) current clients: 54 max: 65
24.12.2018 17:03:26 New LOCAL Client: AFL407@xx.xxx.xxx.xxx:53220 (T154) current clients: 55 max: 65
24.12.2018 17:03:26 New LOCAL Client: IBE160P@xx.xxx.xxx.xxx:51883 (A320) current clients: 56 max: 65
24.12.2018 17:03:26 New LOCAL Client: MSR757@xx.xxx.xxx.xxx:53459 (B738) current clients: 57 max: 65
24.12.2018 17:03:26 New LOCAL Client: DLH506@xx.xxx.xxx.xxx:49794 (A319) current clients: 58 max: 65

That resulted in a 3.8 Mbit/s stream for an hour, far above what the average load of the server is. It is beyond paradoxical why someone chose a server in Atlanta, GA, USA to test this from an IP address in Sweden when London, France, and Germany are so much closer.

mpserver01 typically sees 10 Mbit/s, but since the multiplayer services are many and geographically disperse, the impact to each is less. Further, the protocol itself isn't compressed, so this results in 64-128 kbit/s for each user connected.

If you want to do things like this:

1) Do not do it in Production.
2) Do it on your own server and look at the impact first. No testing in Production!
3) It is possible to link multiplayer servers. The interserver link bandwidth required is not nearly as great as the bandwidth required by the client.
I speak only for myself.
drR0ckso
 
Posts: 31
Joined: Fri May 12, 2017 3:14 am


Return to Development

Who is online

Users browsing this forum: No registered users and 4 guests