Additional Fields

[adepssimius]

Speaking with a friend who is a fellow aviation and data enthusiast, he recommended some additional data points to track.
Are you interested in these being incorporated and do you have a preference for how?

Tail number
Airline
(I do see the existing, somewhat stale PR for these #56 )

Check boxes for Go Around, De Ice, Mid flight Holding Pattern

a grouping indicator for flights that are part of a single trip (this would probably be a larger change to restructure some of the data)

Additionally there were some interesting statistics he derived from his existing data:

Just some thoughts to gauge interest and start to structure these into actual issues that can be implemented.

[pbogre]

Could you elaborate on the "Go around, De Ice, Mid flight Holding Pattern" checkboxes? I'm not sure what those are supposed to mean.

For grouping flights by trips, that does require some work but it's not a crazy amount. All that would need to be done is a trips table with some basic info and an optional trip_id column in the flights table. There would also need to be UI changes to support trip CRUD, and although this is a nice suggestion I think it goes beyond my vision for Jetlog to be a simple flight tracker, since trips are separate in a way. However if I see a lot of interest in such a feature I might consider it.

I do agree that the current statistics are quite lackluster, and I would like to make more use of it. I like the "Days since last flight" plot, I also think that it could be cool to have an airport view page where you can see information about an airport and all of your flights that departed from or arrived to said airport. This is something I'll keep in mind. (I have opened an issue about this last suggestion, see below)

As for the tail number and airline, those are definitely something that I want to implement, but the main issue comes from finding a good and up-to-date database of airlines. A decent amount of effort went into this feature already in that PR, and I don't mind picking up what @moshobo left to get it done.

[adepssimius]

Go around, de-ice, and holding pattern are intended to record if you ended up doing a go-around, had de-icing done, or ended up in a holding pattern before landing for a given flight.

Personally I think go-arounds would be an interesting data point to track, given that I have had relatively few of them happen.

De-icing and holding patterns are less interesting to me personally, but they could be interesting data points to collect to figure out how frequently your departures are delayed from a given airport due to de-ice and how often your landing is delayed at a given airport due to crowded airspace.

Another that might be interesting to me is to mark turbulence on the flight and if you had good views, for instance to figure out for a given flight what side do you need to be on for the views.

I'm mainly wanting to start a conversation about what your vision for the app is and if these things fit.

[pbogre]

I see what you mean by de-ice/go around/holding pattern now, I think those are pretty specific fields to be recording but the general idea is to record whether or not the flight had some kind of delay? In that case I could add a simpler and more catch-all field called had_delay or something that you can use in these situations. For more specific details you can always use the notes field, though that won't allow any statistics to be done, but you could filter for flights that had a delay and then see the notes for those, or even see how many flights in a certain airport had any kind of delay without that delay being as specific as de-icing or whatever.

Turbulence or nice view could be interesting, but when adding all these 'mini'-fields the question becomes how it's going to look like in the UI, because you might end up with a lot of clutter with all these checkbox-like fields. I suppose I could hide them under a "more options" tab and that would mostly solve the clutter problem. I'm not opposed to these extra fields, I'd just have to figure out how to implement them without negatively affecting people who don't care for them.

[adepssimius]

They probably make sense as a tagging system, where you can add arbitrary tags to a flight rather than as distinct fields on the flight. A tags table and a flights-tags pivot could be used to add whatever arbitrary user managed data and would provide flexibility for many different use cases.

[pbogre]

Although that is a good suggestion, in my experience I found that many applications that implement such a tagging system, or anything where the user can customize which fields are recorded by adding new ones, it ends up increase the code complexity by quite a bit and all for the benefit of the few users that would want to record their specific situations.

This doesn't mean that I'm against the ability to track whatever you want to track, I'm just against the ability to add fields yourself. Instead, I think this tracking should work on top of the fields that are already present, if that makes sense. For example, all of this could be easily implemented with a search in the notes field, so that you could filter flights where the notes contain "delayed", "de-icing", "nice view", ... This would put the responsibility on the user rather than Jetlog, and all I would have to add to the code is a simple filter on the notes field. This could be further enhanced by saving a few of these word-filters in the browser, so that you can have a list of quickly accessible filters for notes.

For example, if you decided to include the words "nice view" in the notes of flights that you thought were nice, Jetlog could perform statistics on those flights the same way as if there had been a dedicated nice_view field in the database, except that it is immensely simpler at the implementation and conceptual level. An example use case would be where the user wants to find all flights landing at airport A which had a nice view, and see what side they were sitting on for those flights. This could be done in the (soon-to-be-added) airport page for A, with a filter for notes containing "nice view", and in the result you can see for each flight what side you were sitting on.

Of course this is just an example of a way this could be implemented, it's just that I am opposed to giving the user the ability to add whatever fields they want because then that might end up with people wanting custom types for those fields, and increasingly complicated types for these, and so on until it becomes extremely complex e.g. to support backward compatibility, imports and exports, etc.

Let me know what you think of this, and I hope you understand my concerns with stuff like the tagging system

[adepssimius]

My concern with relying on the notes field to store that kind of data is that it denormalizes the data. While you can relatively easily concatenate a set of tags onto the start or end of a notes field, the other way around is impossible.

If nothing else, a json field to store structured notes might be a good solution. (Yep, let's turn this into an unstructured db project built in a relational db lol!)

Allowing users to put what is essentially structured data into an unstructured field has bitten me in the ass several times with apps I have inherited. I have previously also taken a middle ground approach where I allowed free-form text in a field but a typeahead returned a distinct list of all previously used values for that field that matched what the user was typing. The data still ended up denormalized despite very few users, the typeahead, and forcing entries to uppercase.

[pbogre]

I hadn't considered that problem. Although i'm reluctant to create a JSON field, I guess that's a good solution for this.
Though JSON might be somewhat overkill for some simple tags, what do you think about a field dedicated to tags where they must be entered comma-separated and case-sensitive?

e.g. "nice view, de-icing, delay"

I believe SQLite is capable of splitting strings like this, and this is just enough structure for tags, as opposed to JSON which is much more powerful. Something similar to this is how i've seen it done in many situations, for example Github uses it for repository tags.

[pbogre]

I have moved this to a discussion since I think it fits better the purpose of this post, and because I want to experiment with this Github feature :)

[adepssimius]

Thanks! I didn't know that was even a thing.