feat: select departure and arrivial runways as part of a flight and fetch from flightdatabox

[mhlas7]

#648

@johanohly sorry about all of the PR's from me lately. I have a few weeks off between jobs and a bunch of ideas for AirTrail!

Changes

• Added a new database table to store runways referenced by the airport id
• On first start and manual airport refresh, pull the airports csv from OurAirports and populate the runways table
• Add runway selection modal to add route and edit route. The dropdown shows a filtered list of applicable list of runways for the arrival or departure airport.
• Added hooks to grab arrival and departure runways from AeroDataBox (lots of flights don't have runway data from AeroDataBox)

Screenshots

New button in the route add and edit modal

The runways modal with runways selected

Runways modal with the list of filtered runways for KSEA

When no airports are selected, a status message shows

Note

Add departure and arrival runway selection to flights with data sourced from OurAirports and AeroDataBox

• Adds a runway table and links flights to specific runways and runway ends via new nullable foreign key columns, with referential integrity enforced by the database.
• Introduces a new FlightRunwayModal component in the add/edit flight forms, letting users select departure and arrival runway ends based on the flight's chosen airports.
• Populates and syncs runway data from OurAirports CSV on startup and via the admin "Update from Source" action, which now returns separate stats for airports and runways.
• Resolves runway idents returned by AeroDataBox flight lookups to internal runway IDs and auto-populates them into the flight form.
• Server-side flight save validates that selected runways belong to the correct airport and that the selected end exists on that runway.
• Risk: runway data population now runs at server startup; failures are caught and logged rather than crashing the server, so missing runway data will not surface until the update is retried.

^{Macroscope summarized 9faddba.}

[github-actions]

Label error. Requires exactly 1 of: changelog:.*. Found: Web

[JackyHe398]

Will it be better to allow user to input runway other than the provided options for some exceptional case (e.g. database outdated). Also a manual input allowed without input airport may also be considerable for a higher flexibility. There's no (or not too many) harm to allow user doing this.

[achatman]

Rather than adding a dedicated modal for this, it might make sense to add to the existing Terminal & Gate modal. All three fields are about the airports, so a new title could be "Additional Airport Information" or something along those lines. Maybe just "Airport Details" would be enough.

[mhlas7]

Will it be better to allow user to input runway other than the provided options for some exceptional case (e.g. database outdated). Also a manual input allowed without input airport may also be considerable for a higher flexibility. There's no (or not too many) harm to allow user doing this.

The best way to implement custom runways would be to do that through the custom airports modal in settings. I'll experiment with that although it may come out in a separate PR.

[mhlas7]

Rather than adding a dedicated modal for this, it might make sense to add to the existing Terminal & Gate modal. All three fields are about the airports, so a new title could be "Additional Airport Information" or something along those lines. Maybe just "Airport Details" would be enough.

Personally I like having a dedicated modal for this but I can see the benefit of consolidating. Ultimately, this decision would be up to @johanohly.

[JackyHe398]

Will it be better to allow user to input runway other than the provided options for some exceptional case (e.g. database outdated). Also a manual input allowed without input airport may also be considerable for a higher flexibility. There's no (or not too many) harm to allow user doing this.

The best way to implement custom runways would be to do that through the custom airports modal in settings. I'll experiment with that although it may come out in a separate PR.

I am worrying there might be ppl know which runway they are using but don’t know the airport. I have a similar issue when dealing with my.flightradar24 but luckily they don’t have limitation on that two specific field (I forgot what they were). That’s why partially decomposing airport and runway (allow customize when airport omitted, or even when provided) can be a considerable idea.

[mhlas7]

Will it be better to allow user to input runway other than the provided options for some exceptional case (e.g. database outdated). Also a manual input allowed without input airport may also be considerable for a higher flexibility. There's no (or not too many) harm to allow user doing this.

The best way to implement custom runways would be to do that through the custom airports modal in settings. I'll experiment with that although it may come out in a separate PR.

I am worrying there might be ppl know which runway they are using but don’t know the airport. I have a similar issue when dealing with my.flightradar24 but luckily they don’t have limitation on that two specific field (I forgot what they were). That’s why partially decomposing airport and runway (allow customize when airport omitted, or even when provided) can be a considerable idea.

The origin and destination airports are required fields in AirTrail so it is not possible to add a flight to AirTrail that only has runway numbers.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[johanohly]

First off, no need to apologize for the PRs. I do appreciate you taking the initiative!
I've now looked through this properly. I like the idea of storing runway information, but I don't think I want to merge it in this form. The database space itself is not as bad as I initially assumed, but maintaining a global runway table adds quite a lot of sync and data lifecycle complexity for two fairly niche flight fields.
I also don't think flights should reference the current runway database by internal ID. That makes backups less portable, and historical flights could change when a runway is renamed or renumbered in the source data. Missing, outdated, and custom airports also need a manual fallback.
If AirTrail gets built-in runway fields, I think they should probably just be plain text fields stored directly on the flight. AeroDataBox could still fill them automatically, and users could enter or correct them manually. The automatic lookup would then be the main advantage over advising users to add runway information as custom fields.
Given that this would require a fairly fundamental rewrite, I'd prefer to close this PR rather than ask you to keep iterating on the current approach. Sorry, especially after the amount of work you've put into it, and thank you again for the contribution.

[mhlas7]

Understood. I have a few ideas how we could do this differently. I'll turn this into a draft and put together a design for your feedback!