[Feature Offer] Flight information?

[darioackermann]

First, thanks for your great work.

When seeing planes fly-by, I always love to find out where they are flying to and I could think of adding such a feature to my local installation of tar1090, and, if it is appreciated I'd be glad to bring it to this repo as well.

What do you think? Cheers

[wiedehopf]

I'm not sure where you'll get the data that appreciates getting hit by lots of installs. Otherwise ... sure i'll take a look at your branch when you've got something.

[darioackermann]

I was thinking about OpenSky API, for example https://opensky-network.org/api/routes?callsign=EDW200E (airport information https://opensky-network.org/api/airports/?icao=LSZH). Usually we should be having the callsign

Usage of data should be fine (https://opensky-network.org/about/faq#q6) with a little reference to opensky. To prevent an explosive number of hits once the update is rolled out, I'd suggest to add an option (disabled by default) to show flight route in the label / table, additionally as caching the data.

[wiedehopf]

Maybe ask on their forum if this would be acceptable, the policy seems to imply it would be.

Also to have this in the javascript you need their response to have: access-control-allow-origin: * in the headers.

Have you tried?

A good part of this project (at least for me) has become its use on https://globe.adsbexchange.com/ That would not work with the terms but that's ok. Just make sure to put a variable into html/defaults.js that enables / disables the feature so commercial use of the webinterface doesn't collide with the API terms.

Yeah seems like the home user base would appreciate this. To reduce number of requests i'd consider only fetching this detail when an aircraft is selected. That's how the thumbnails for the pictures work.

[darioackermann]

Awesome. Yes, the CORS headers are sent :) Asking on the forum seems wise.

To reduce number of requests i'd consider only fetching this detail when an aircraft is selected.

Sounds good to me. I will also think about caching. If you have any other ideas, feel free to let me know :) Happy to PR soon ;)

[BebeMischa]

Just to cheer you guys up, I really like to see this discussion happening. Very much appreciated to see, this is laying on the kitchen table and may end in the cooking kettle ;-)

[darioackermann]

@BebeMischa 🥳

Nice!!! I was also thinking about integrating data from more well-known and big sources such as FR24, but since it would be relying on (ab?)using their private API (e.g. https://data-live.flightradar24.com/clickhandler/?version=1.5&flight=2aa5dcaa), this is probably not suited to be merged into this repo. Let's see, maybe I will end up with one PR and one fork 🍴

Additionally, using FR24 data would require a proxying-mechanism for not-logged-in users (interestingly, if you are logged in with a feeder subscription it works and CORS-headers are sent...)

But first, some more uni exams...

[darioackermann]

Unfortunately,

[...] This particular end point is not in the API documentation for a reason. It is purely for the OpenSky Explorer and for scientific use (e.g. our Covid datasets) as cleared with the numerous sources providing the data.

(thread on opensky-network)

I suppose data-fetching from FR24 is out of scope to be merged into this repo as it is messing with FR24's TOS. I might provide such a patch for tar1090 on a personal repo anyway since you wouldn't be requesting more data than looking at FR24s website directly - it should be arguable for personal, non-commercial use, especially when supplying data to FR24 already...

Closing here since an easy solution for this seems not in sight.

[BebeMischa]

:-( Fully understandable, still disappointing. But THANK YOU for trying! ;-)

[darioackermann]

Thanks. I'll think of and provide patches in https://github.com/darioackermann/tar1090-fr24data soon.