Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New retrieve_runway_list dervices runway data from OurAirports db #7

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

dnouri
Copy link
Contributor

@dnouri dnouri commented Jun 28, 2020

The last commit in this PR implements a new function retrieve_runway_list that derives runway data from the OurAirports db. I've added a check for VABB to verify that the three points rwy, rwy2, and gate are reasonably close to the original, for all runways. TODO: I need to run the GA detection against the full VABB period using the derived runway data derived from OurAirports. See my comment below.

This PR actually includes commits from all the other PRs I've been working on (#3, #4, #5), because it was becoming a hassle keeping these separate. The individual commits hopefully give an idea about the intention behind changes. You're free to close up the other PRs and just look at this one, or you can merge the other ones, and then this one. Whatever suits you best. :-)

I've been having lots of fun working with your code! I have a few more ideas for changes that I want to make. Also, trying this out on other airports, it looks like it generates duplicates, i.e. go-arounds detected from the same aircraft with only minutes between the detections. This should be trivial to address.

dnouri added 5 commits June 26, 2020 17:57
- pd.Timedelta does not like to be initialized with `tz` argument,
failing with "Cannot pass a datetime or Timestamp with tzinfo with the
tz parameter. Use tz_convert instead."  My understanding is that since
all timezones are UTC throughout, it should be safe to drop this
everywhere.

- flph.fuzzylabels returns a list for me, and so I explicitly convert
it to an np.array before applying fancy indexing with `labels[pts] =
'GND'`.  Before, this would error with "list indices must be integers
or slices, not tuple".

- The existing glob pattern did not seem to work for the new way of
saving pickles into subdirectories of `outdir`.  Instead I'm now
applying to separate glob patterns that will pick up pkl files from
the `INDATA/` directory and its subdirectories.

- I'm creating the output directories for plots and data if they do
not exist already.

- The plotting functions mysteriously saw a `GN` label.  I'm really
not sure if this is the right thing to do here, but I simply assumed
that this was the same as `GND` and added another entry to the
colormap accordingly.  This may be really a symptom of a bug that
should be fixed in another place.

- In proc_fl, set `odir_np` also when do_save==False, because it's
used later on.
This includes the ability to configure the metars file via the
command-line.  The loading of the metars file has been moved to the
main process to enable this.
@dnouri
Copy link
Contributor Author

dnouri commented Jun 28, 2020

So I compared the output of the GA detects between the VABB as it's defined in OS_Airports/VABB.py and as it's derived from OurAirports:

--- GA_MET_NEW-orig.csv	2020-06-28 11:47:47.828459117 +0200
+++ GA_MET_NEW.csv	2020-06-28 11:59:47.914397435 +0200
@@ -5,5 +5,5 @@
 800614,SEJ480,2019/08/15 07:00:02,2019/08/15 06:59:01,27,269.1636246745776,1861.3343323203817,19.089583057468218,72.9275956587358,417,0.0,0.0001788456729393156,2.2687858665378375e-06,0.00013845506336710578,0.025804533701889253,28.0,24.0,11.0,0,240.0,1200.0,0,3000.0,1007.0
 800c94,IGO5383,2019/08/14 19:09:15,2019/08/14 19:16:31,27,269.1636246745776,2018.2862929274004,19.08925719180349,72.90522349964489,421,0.8827586206896553,0.00013714195288017518,2.6227756487117477e-06,0.00020145036121007928,0.02313173769827369,28.0,26.0,9.0,0,240.0,1800.0,0,3000.0,1007.0
 800d91,SEJ6352,2019/08/16 13:43:20,2019/08/16 13:39:18,27,270.8126515942537,996.6066875476146,19.08921063956568,72.87660910866478,224,1.6055459438389728,0.009992128047261012,1.549487612451061e-06,0.00013680133514794545,0.02243818669639377,29.0,25.0,10.0,0,240.0,1800.0,0,3500.0,1005.0
-800bb5,IGO753,2019/08/19 11:13:35,2019/08/19 11:09:44,27,314.127542877098,1796.9245306558291,19.074686341366533,72.88320090553978,670,2.0902312471749784,0.016032441235725073,9.847464217591327e-05,0.00010430283433264013,0.03055050463303893,30.0,25.0,10.0,0,260.0,2000.0,0,6000.0,1008.0
+800bb5,IGO753,2019/08/19 11:13:35,2019/08/19 11:09:44,32,314.127542877098,1796.9245306558291,19.074686341366533,72.88320090553978,670,2.0902312471749784,0.016032441235725073,9.847464217591327e-05,0.00010430283433264013,0.03055050463303893,30.0,25.0,10.0,0,260.0,2000.0,0,6000.0,1008.0
 800bf3,GOW544,2019/08/19 19:19:43,2019/08/19 19:17:40,27,268.8228551140179,1839.5546388092991,19.089111328125,72.89678846086775,495,1.188450164333132,0.006178363282028493,2.5110457160730994e-06,0.00020218713282695646,0.018569533817705187,28.0,25.0,6.0,0,280.0,2000.0,0,3000.0,1009.0

The only difference is with the second-to-last flight, where using the OurAiports data yields a different runway number 32 (instead of 27), which incidentally appears to be the correct one here:

image

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant