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

Add Functions and Table Structure to Allow Ground Positions #42

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

Conversation

jacob-y-pan
Copy link

Initial commit for enabling ground positions. Adds columns to positions
table and ground_position message handler in db-updater, and then add
ground_positions endpoint on fids_backend and also attempt to add ground
position path to maps endpoint.

BCK_6624

Initial commit for enabling ground positions. Adds columns to positions
table and ground_position message handler in db-updater, and then add
ground_positions endpoint on fids_backend and also attempt to add ground
position path to maps endpoint.

BCK_6624
db-updater/main.py Outdated Show resolved Hide resolved
fids/app.py Outdated Show resolved Hide resolved
fids/app.py Outdated Show resolved Hide resolved
fids/app.py Outdated Show resolved Hide resolved
fids/app.py Outdated
],
"path": [
f"color:0x0000ff|weight:5|{coords}",
f"color:0xff0000|weight:5|{coords_gp}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a flight, what you'll tend to see are a group of ground_positions (pre-departure), then a group of positions, and then another group of ground_positions (post-arrival). Ideally this could be represented on the static map with a dual-colored, 3-part line. To represent that, you'd need to figure out where to split up the ground positions so that they can be in 2 separate lists.

You might be able to use time gaps in the ground position list to determine this, or perhaps the flight's actual departure and arrival events.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what "perhaps the flight's actual departure and arrival events" means, though I will look at that. Is it possible to even use the coordinates of the locations and determine if it's closer to the destination or origin, or is that too expensive / complicated considering there's no geolocation API being used (thinking of the hackathon haha) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be more specific, you could cheat (a little) and just say "we're calling every position we have with a time before the flight's departure or after the flight's arrival a ground position". You unfortunately won't have airport coordinates readily available, and even if you did, we're not really trying to distinguish between start and end of flight, but between "in the air" and "on the ground".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For those flights that have all 3, would we be able to see the ground positions lines? It seems like if the flight is very far the small positions on the ground would barely be visible (I'm kind of seeing that when looking at various flights for pre-departure routes), so maybe expand the map or something like that?

fids/app.py Outdated
Comment on lines 269 to 277
# Do ground positions
ground_positions = list(_get_ground_positions(flight_id))
if not ground_positions:
abort(404)
bearing_gp = 0
if len(ground_positions) > 1:
coord1 = (float(ground_positions[1].latitude), float(ground_positions[1].longitude))
coord2 = (float(ground_positions[0].latitude), float(ground_positions[0].longitude))
bearing_gp = trig.get_cardinal_for_angle(trig.get_bearing_degrees(coord1, coord2))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't need to do this twice, just determine the bearing of the most recent position/ground_position.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe to assume that if the most recent is ground_position the second most recent will also be ground_position?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There might be a case where you happen to have the first ground position after a plane has touched down, meaning the second most recent would be from airborne. It might be useful to have a function that grabs all positions in time order and just works with those at first, later splitting them up by air/ground when needed.

jacob-y-pan and others added 5 commits August 11, 2022 16:59
Remove comments

Co-authored-by: Chris Roberts <NasaGeek@users.noreply.github.com>
Remove testing

Co-authored-by: Chris Roberts <NasaGeek@users.noreply.github.com>
Add comment clarification

Co-authored-by: Chris Roberts <NasaGeek@users.noreply.github.com>
Previous check for if it was a ground_positions data point just checked
if ground_air was null, now using if its value is "G". Also added
functionality to get top 4 positions and return the top 2 for bearing.

BCK_6624
When trying first 4 coordinates without distingushing them between
ground_positions and positions, bearing was incorrect, so just took the
latest pair between the first two of the two types. Also fixed
coordinate fetching so map has mix but also show plane having both
positions and ground_positions distinguished.

BCK_6624
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.

None yet

2 participants