Aircraft Performance Data Corrections

[doofus]

Is I have been playing through the game the performance of the MD-80 series, MD-90 series, and B712 have seemed to be lacking. The climb out extremely slowly. I looked at the JSON files for those aircraft. The rate of climb is set too low.
The data on Eurocontrol shows that these aircraft should have climb and descent performance on par (or better than) the B738.
Which data was used to set the climb rate parameters? None of the published data supports the figures in the JSON files.

After looking around the performance figures of a lot of aircraft seem suspect and a general revision of all aircraft should be undertaken using reliable source data (e.g. manufacturer, or something Eurocontrol).

The data from Eurocontrol gives climb and descent rates for aircraft throughout different phases of flight.
E.g Initial climb (to 5000 ft) rate, climb rate to FL150, climb rate to FL240, Mach climb rate (climb to cruise),
initial descent rate (to FL 240), descent rate (to FL100), and approach descent rate.

My TL;DR questions:

1. Is there any plan to implement different rates of climb and descent throughout the phases of flight?
2. Until different rates of climb/descent are implemented, what figure should be used to climb/descent rates? Initial climb rate and approach descent rates? Some sort of composite calculated rate?
3. May I update the MD-80/90/B712 climb and descent rates to something similar to the B738 or some other rates we can agree to here?
4. Once we address issue 2, we should review and revise all the aircraft performance data using reliable source data.

Cheers,

Josh

[doofus]

I am planning on updating the performance of all aircraft based on published information from the EuroControl Aircraft Performance Database.

Why

This database is published by Eurocontrol which is a trusted name in Air Traffic Management for Europe and provides performance data for most if not all aircraft types used in this simulator. It also provides performance data for the parameters most useful for this simulator: climb rates, descent rates, weight class / WTC, approach category (APC) ceiling, takeoff runway length, landing runway length, takeoff speed, landing speed, and cruise speed. It does not have maximum speeds, but that's terribly useful for the terminal control aspect that is the focus of this simulator.

What

The aim is to update all the aircraft JSON files with the Eurocontrol data. Any gaps will be left in place unless they can be updated using data from the manufacturer. In the absence of manufacturer data, another source can be used and will be annotated in the commit comments.

The aircraft JSON file specification will be documented in the Wiki as well so all the fields will be described and how their values are derived.

But...

I've shied away from using the Doc8643 website as a source for aircraft performance data. For at least two reasons:

1. Doc8643 describes itself as:

   doc8643.com is a web application allows you to view technical data of aicrafts as described in Doc8643.

   However, ICAO DOC 8643 does not contain performance data as claimed by doc8643.com.

2. Some of the aircraft data don't seem to jive with other sources.

So...

I don't mind doing this, but if there are objections which would lead to this not being merged, then I don't want to waste my time.
How do we feel about this?

Cheers!

[eliuuk]

I do think this would be a great idea! This would especially help with the release of V3 which would see an entire turnaround of the project!

[doofus]

OK. I will start work as and when I can.

[erikquinn]

If you plan on doing them all by hand, that might be a days of painstaking work; is it possible to instead download this performance data, so it could be reformatted or perhaps we could change the parsing logic to ingest the data exactly as eurocontrol provides it? That seems like a much more feasible and permanent solution than manually maintaining all of these aircraft...

[n8rzz]

I will add, that any new additions or modifications to json or geojson files will be unaffected by all the v3 upgrades. These can still be worked on independently of v3.

If you'd like to keep tabs on v3, take a peak at #679 or http://github.com/n8rzz/atc/issues

[doofus]

@erikquinn Parsing the data from Eurocontrol would be ideal, but there are still some gaps in the data for some aircraft that would have to manually patched in. So I would still have to manually review all the files to resolve any gaps. This, I would imagine, would only need to done though as I don't expect these parameters to ever change.

[erikquinn]

@doofus Gotcha. I took a look myself, and it seems that there isn't any easy way to "download" all the data. (Disclaimer: I didn't look all that hard)

Do you know of a way to do this? If not, we may have to continue doing these things by hand. 😞

[doofus]

You could query the Eurocontrol website based on the ICAO type designator (i.e. "B738" for the Boeing 737-800 or "A333" for the Airbus A330-300):

• https://contentzone.eurocontrol.int/aircraftperformance/default.aspx?ICAOFilter=a333
  This will return filter the performance data for the Airbus A330-300
• https://contentzone.eurocontrol.int/aircraftperformance/default.aspx?ICAOFilter=aB738
  This will return filter the performance data for the Boeing 737-800
• https://contentzone.eurocontrol.int/aircraftperformance/details.aspx?ICAO=B738
  This will return the detailed performance info for the Boeing 737-800. This is probably what we would want for each aircraft as it has more parameters that are used by the simulator. It may be harder to parse though.

[eliuuk]

I went ahead and used inspect element to look at the source code of one of those pages @doofus mentioned.

The source code is very nice, in that Eurocontrol have assigned an ID to almost all the data we need for the aircraft.js file.

I would think that Javascript would be nice in this case for extracting data. What I can't seem to do is to use getElementById() with a URL, in this case, one of Eurocontrol's pages to extract some data with innerContent. However, I'm not a Javascript coder - this is what I have scavenged from the internet! Is this even possible? I don't know, but you JS people might know!

[n8rzz]

@indianbhaji what you need there is actually innerText. something like document.getElementById('gV2').innerText would do.

There isn't that much data there, though, you'd probably spend more time typing out the JS than it would take to just copy/paste it into a text editor. If you wanted to automate, what you really need is scraper. https://scrapy.org/ That runs on python, though, which can be a little challenging to set up. Its easy enough to get one running with some tinkering.

I would be sure to check their TOS, many websites frown on scraping.

[eliuuk]

@n8rzz

There isn't that much data there, though, you'd probably spend more time typing out the JS than it would take to just copy/paste it into a text editor.

True, but the JS might come useful in assisting with creating the aircraft file by automatically setting out a template with variables.

In regards to the scrapy thing - I'm not trying :p

[doofus]

If anyone is interested, they can look at my aircraft-update branch of my fork to see where I'm at and to offer suggestions.

[doofus]

As I've been updating aircraft I noticed that description of the minimum speed in aircraft_format.md describes the speed.min parameter as the "Stall Speed" (V_S). In testing it appears that this parameter is used as the takeoff speed. Takeoff speed should be the "rotate" speed, V₂. V_S and V₂ really should be decoupled as the approach speed, V_at, is usually lower than V₂. As for now, I'm using V_S for speed.min. Should this be raised as a separate issue?

[n8rzz]

My vote would be yes.

Add another issue and then I can add it to my v3.0.x feature list. I'll be refactoring a lot of the aircraft stuff anyway so this would be a good improvement to add.

[erikquinn]

@doofus Yeah, adding a V_R/V₂ wouldn't be a bad idea. The difference would likely be minimal though for the work required in terms of updating all the aircraft files. But if you're game to do it, then I don't see why not!

[doofus]

I'm already revising aircraft performance for all the aircraft in the assets directory. Can I add another key-value pair to the JSON files without the parser barfing? Will they just be ignored until the rest of the code uses the values?

[erikquinn]

@doofus Oh yeah, absolutely. I'm pretty sure it'll even be parsed into the aircraft object without any further changes. We would just have to update the physics logic to use those speeds to determine flight characteristics. But yes, you can add that in; it won't break anything in this case to have extra parameters.

[erikquinn]

@doofus just curious-- how is this coming?

[darssy]

A small piece of advice on that: aircraft performance is not a trivial task. I know that there might be lot's of work in progress but if it turns out to be a heavy task or a dead end, here is a suggestion:

• Define only 4 different performance data. One for each approach speed category (A, B, C or D)
• Then assign to one of each aircraft its approach category (This won't be difficult to be found online, it's on Skybrary).
• After that, you could make individual performance files for significant and major aircraft types for fine tuning. But until then, you will have a very good and working approximation. I mean who cares if the MD81 and B721 have the same performance? They are comparable aircraft at least from the ATCOs point of view.

Otherwise trying for every single aircraft might be a daunting process.

Just my 2 cents.

[erikquinn]

The ATC repository is being migrated to it's new home at https://github.com/openscope/openscope,
and thus, all issues are being closed. If this is still an issue with the latest version of the sim
(accessible at http://www.openscope.co), or is a feature you still think we are lacking,
please reopen the issue at the new repo.

Please note that the vast majority of these issues have been copied to the new repository, or else are covered by other issues created there. See the below screenshot for what it looks like when your issue is known in the new repo:

Thank you!

Closing this issue.