[DATA] SKW 3370 is changing

[dirkhh]

Url of request https://api.adsbdb.com/v0/callsign/SKW3370

Why was the data wrong SkyWest changes route on many of their flights fairly frequently. This one is currently used for both directions of Seattle / Rogue Valley, but starting on Thursday it will switch to Seattle Glacier Park

Additional context I really don't know what the best way is to deal with flights like that... especially the increasingly common practice that both directions of a city pair have the same flight number...

[mrjackwills]

Yeah, the database is kind of static, it was based on data from a specific point in time, so for flightroute callsigns that change their origin and/or destination, we'd need to work out what the best option would be

[dirkhh]

I think there are several separate issues.

One is that flight plans change, typically at least twice annually. The second is that more and more airlines do the weird round-trip with the same flight number.

Those two I have suggestions how to deal with. This may require some additional changes for the database and the API, though. Once you have that, empower the community to submit changes in an easily digestible format and I think you'll find many people willing to contribute.

What's harder to fix is those weird special flight numbers... And of course the airlines like Southwest that apparently sometimes have three of even four hops with the same flight number...

For those two cases a first suggestion would be to have a special return value that indicates the issue, instead of returning an incorrect route.

But one step at a time, I guess.

[mrjackwills]

At the moment I haven't got an easy way to alter data, other than going directly into the database and executing raw SQL queries.

So I think I should code something up, that can run on a regular frequency via a Docker container in the same network. It would read a simple CSV file (flightroute, Optional<flightroute_icao>, Optional<flightroue_iata>, origin, Optional<midpoint>, destination) and update the data, as well as clear any cached data. Should be easy enough to create, and then just update the CSV file, based on any submitted GitHub data issues, on a regular basis? On first thoughts, in my mind, that's the most efficient, read laziest, way to do it.

Wondering whether the data issue template should ask for two sources, just to make sure that we input the correct data, and, again, efficient/lazy for me.

As for api changes, it's a v0.x.x release, so I am happy to change the response data, but as you say, would need to work out the best way to convey data about these special, or frequently changing, flights

[dirkhh]

So one thing I noticed while playing around with all this, is that https://github.com/vradarserver/standing-data contains CC0 licensed flight data. And they have a neat web UI that allows you to update their data as you see discrepancies (just submitted a few to them to see how long it takes for that to make it into the GitHub data). Given the CC0 license of the GitHub data, I of course think that this would be a great opportunity to collaborate and get the best data for everyone... so a tool that could ingest what they have and (at a minimum) flag what you have in your database would be a neat thing to play with :)

In the meantime, I'll be happy to submit issues that I see either here on GitHub or as a CSV or in any other format that's convenient for you. Fundamentally I am excited about the idea of good, free data available for a community of plane spotters / trackers. And anything I can do to help (within reason) I'm happy to do.

Speaking of "playing with" things... purely hypothetically speaking... if someone made a silly mistake while working on an app using your API and had it runaway make API requests to your API and as a result had their IP address blocked for about 100 years (rough estimate, based on your formula on the website)... how many positive contributions do they have to make to get that block removed? Or should they just change IP addresses by rebooting their fiber modem and move on with life?

askingForAFriend 😇

[mrjackwills]

Thanks for the link, yeah sounds like a great opportunity to collaborate. Will spend some time this weekend to look and think about it all.

As for blocking, email me you ip address, and I'll unblock it. I check the logs, maybe weekly, and any abusive looking ip addresses I completely block via nginx.

[dirkhh]

done

[mrjackwills]

There's now adsbdb_updater, which should make the task of keeping flight routes up to date painless.

I have already run it against the input.csv found in the repository

[dirkhh]

NICE. I like it. I am two thirds through a system to identify routes that are likely incorrect, based on adsb info people collect.

This might turn out into a very useful tool to then create such input.csv. I'll keep you posted.

[mrjackwills]

The standing_data, at first glance, seems substantially more detailed, a quick SQL query on the adsbdb data, I found 1763 flights that start "DAL", whereas there are over 3000 in that dataset.