Monday, September 28, 2020

Properties In-Depth: Part 3 - Odds and ends, tips and tricks

In the previous two posts, I have described how properties work at a high level and some groups of properties that have some sort of meaning to MyFlightbook.

In this final post on the topic, I want to discuss "odds and ends" - properties that have meaning to the system or otherwise have specific functionality, but which do not fall into any of the larger buckets previously described.

Instructors and Students

Students can give instructors permission to add flights to their logbook.  If so, then there is an additional template that is automatically applied for the instructor.  This includes two properties that the instructor is likely to want to include in the student's record: Ground Instruction Received and Name of Instructor.

When signing a flight, the instructor has the option to copy the flight being signed into their own logbook.  Naturally, this is an asymmetric relationship, so the act of copying the flight reflects this asymmetry.  During the copy, the following transformations are performed:

  • Dual time is copied to CFI time and PIC time and is then cleared.
  • If a flight review is indicated in the student's record, it is not copied to the instructor's record but a Flight Review Given property is added.
  • Ground Instruction Received is deleted and it's value is re-used in Ground Instruction Given
  • The Student's name is copied to the Name of Student property.

The flight checker also looks for a missing instructor name for flights that have dual indicated but are not signed.  (Since a signature includes the name of the instructor, having an explicit property for instructor name is unnecessary).

Finally, if you are doing autofill and the entry has a defined lesson start/end period (from Lesson Start to Lesson End) and you have Dual or CFI time indicated in your flight, then the excess of lesson time minus flight is added to Ground Instruction Received (if you're a student - i.e., you logged Dual time) or to Ground Instruction Given (if you are the instructor - i.e., you logged CFI time).

Paired Times and Values

There are a variety of "paired" properties that indicate a start/stop.  On the main flight form is hobbs time, which the system knows about intrinsically (and because it's based on clock time, the system can perform computations using hobbs start/end).  
 
But there are others, and the system knows about these as well:
  • Tachometer Start/Tachometer End.  A useful tip here is that the starting tach value can often be auto-filled by clicking the cross-fill arrow (website) or by pressing-and-holding (mobile apps).  This cross-fill looks across your flights in the flight's selected aircraft and finds the highest value; this is then used to initialize the starting tach value.
  • Block Out/Block In - Technically this defines the time you can log for a flight, though many people use hobbs time as an approximation.  Block Time can be used as a source for auto-filling total time (on the mobile apps) or for auto-fill; and as a sort criteria if present and needed; as a substitute for departure/arrival time (if not otherwise specified), and in part 117 currency computations.
  • Lesson Start / End - As described above, these denote the start and end of a lesson so that ground instruction time can be estimated.
As mentioned in my prior post, all of these pairs have an obvious semantic requirement that the start value must be before the ending value; the Flight Checker looks for most of these. 

Other tips and tricks

  • You can set up auto-fill options for a given aircraft to automatically copy your name to the Name of PIC property for any flight in that aircraft. 
  • If you go to the Visited Airports page and add "df=1" to the URL, then clicking "Estimate Distance" will fill in the Distance Flown property for each flight (if not already present), using either attached telemetry or great-circle distance for the route.  Use with care!
  • If you use any anonymous aircraft, then the Aircraft Registration property will automatically be available.  You can put the tail number of the aircraft you're flying on that flight into that property if you like.
  • The Additional Flight Remarks property allows you to record additional short comments for a flight; these are automatically suppressed from print layouts.

Properties In-Depth: Part 2 - Properties that mean something

In my previous post, I discussed the basics of how properties work and how the system can work with so many properties without having any understanding of what they mean.  But properties are also used to allow MyFlightbook to be smarter about your logbook, and obviously that requires knowing some of the true semantics or meanings of various properties.

There are two ways that the system knows about a particular property's semantics.  One is by straight enumeration: it knows that a specific property has a particular meaning.  But sometimes there are many properties that all need to be treated in the same way.  For example, there are numerous types of landings that are described by properties.  Because of this, the flags attribute of the property-type (described in my last post) is used to identify that a property has a particular meaning, without having to care about the specific property.  

Whether by flag or by enumeration, the system uses these properties for a variety of functionality, which I'll describe below.  I will not try to provide here an exhaustive list of properties that have some semantic meaning to the system, but rather I will describe the functionality that is provided.

By far, the most common semantic use of a property isn't really even properly considered "understanding" of the property; it's just a mapping from imported values.  MyFlightbook can import from a wide variety of electronic logbook formats, and so it needs to know, for example, that the field in a given format that corresponds to the name of the PIC for a flight needs to go into MyFlightbook's "Name of PIC" property.  These mappings are, kinda by definition, all done by enumeration (i.e., by knowing precisely which property type to map to an incoming value).  MyFlightbook can also import debriefs from CloudAhoy, which contains a set of maneuvers performed on a flight (stalls, slow flight, and so forth); this as well requires mapping to specific known properties.  

In a similar vein, many properties are "known" in order to map to the correct fields for various print layouts.  E.g., many layouts have a spot for the PIC's name, which is in the Name of PIC property, and the glider layout relies on a set of properties being flagged as glider launch types to compute the total number of launches.  You can also exercise a fair amount of control over printing of properties.

Two other large group of properties are Landings and Approaches.  There are currently more than 60 kinds of landings you can log and 40 kinds of approaches.  Because the model of logging landings (approaches) is to log the total number of landings (approaches) and then to log various subsets of these (e.g., how many of the landings were short fields, how many where on water, and so forth).  

Currently, the only use for knowing that a property is a landing is in the flight check feature, where I make sure that you don't describe any subset of landings that indicates more than the total landings.  Since there are so many different kinds of landings, and this functionality doesn't need to know what a given landing type means, landing properties are indicated by a flag.

Approaches work in a similar way to landings, except a little bit more strictly: I check that your total approach count is equal to or greater than the number of described approaches, and treat it as an error if not.  E.g., if you log 1 ILS approach and 1 VOR approach, you'd better have 2 or more approaches in your total approach count.  I can do this because the approaches that are flagged as such are mutually exclusive (an approach can be an ILS or a VOR approach, but it can't be both), whereas landings are not mutually exclusive (a landing can simultaneously be a short field and a soft field, for example).

Many properties indicate satisfaction of periodically required reviews.  These include a large set of properties that satisfy the flight review requirement - e.g., logging a "Flight Review" obviously counts, but so does passing most checkrides.  There are also properties that indicate that an instrument proficiency check (IPC) has been satisfied, or that a PIC proficiency check (as mandated by 61.58) has been satisfied.

The various checkride properties serve an important second purpose: they are used to determine what ratings and privileges you hold.  You can see these by going into your profile and going to Pilot Info->Certificates.

The next big set of properties cluster around currency computations. These include:

  • Takeoffs - Night 61.57(b) requires both night takeoffs and full-stop night landings.  If (as many pilots do) you only log the landings, MyFlightbook will show you as being night current, but will warn you about missing takeoffs.  If you log any takeoffs using this property, the system will see that you use and and will be strict about enforcing their presence in computing night currency.  The mobile apps will automatically add this property if they detect a takeoff inside your night currency window (which in the US is sunset + 1 hour to sunrise - 1 hour).
  • Takeoffs - Any While MyFlightbook is lax about requiring logged takeoffs for basic 61.57(a) currency, there are other currency computations such as SIC currency (61.55) where it is more strict.
  • Landings - Touch and go (Night) - While night-time touch-and-go landings don't count for anything in the FAA 61.57(b) world, they do count for night currency in other parts of the world.  This is also used to determine "Day" landings, which are computed as "(Total Landings) minus (full-stop night landings + night touch-and-go landings)". 
  • Flight Duty Period Start / End and Duty Time Start / End are used in  Part 117 computations.
  • Night Vision Takeoff/landing/hovering/Departure & Arrival/Transitions/Proficiency Check/Time. These 7 flags help the system determine tasks required for night vision currency.
  • Ground Instruction Given is used for 61.217 computations.
  • Part 135.293 Knowledge Test, Part 135.293 Competency Check, Part 135.299 Flight Check, Part 135.297 Instrument Proficiency Check.  These should be pretty self-explanatory.
  • UAS - 107.73 - Aeronautical Knowledge Test, UAS - 107.74 - Training Course.  Also, hopefully self-explanatory.
  • SIC Recurrency Training (61.55(b)) Ditto.
  • Glider - Instrument Maneuvers and Instrument Maneuvers for passengers.  These two flags help identify tasks required for glider IFR currency

There are also properties that serves as modifiers to 61.57(a) and (b) computations: if a flight has Pilot Monitoring (Whole Flight) attached, then the entire flight is excluded from 61.57(a) and (b) computations; likewise, if you use Landings - Monitored, Day, Landings - Monitored, Night, or Takeoffs - Monitored, Night, then the takeoffs/landings indicated are excluded from 61.57(a) and (b).

There are several properties that are useful for creating custom currency rules, but which are otherwise meaningless to the system.  These include Base Checks, Night Vision Goggles Time, Night Vision FLIR Time, High Altitude Landings, Front Seat Hours, Back Seat Hours, Hoist Operations, Takeoffs (of any sort), UAS (Unmanned Aerial System) Launches, UAS Recoveries, Night Touch-and-go landings, Glider Tows, CAP5 checkrides, CAP 91 checkrides, FMS approaches, Enhanced Vision Approaches, and Special Authorization Approaches.  The system obviously needs to be able to recognize these approaches in order to perform the computation, but does not otherwise have any understanding of why they are being used.

The next cluster of properties are primarily important for computing progress towards ratings.  Some of the main ones here include:

  • Solo Time.  Many ratings require solo flight.  If any non-zero solo flight is indicated for a flight, then MyFlightbook assumes that up to that much time may be credited towards any solo requirements.
  • Duties of PIC (DPIC) and Instructor On Board.  For commercial ratings, these two properties used together can substitute for solo time.
  • Checkride - Private PIlot.  Wait, that's a requirement?  Well, it's more of a marker, really.  For a commercial rating, much of the experience is supposed to be received AFTER receiving a PPL, so if the system sees this in your logbook, it will ignore those training items that occurred before it.
  • Military Co-pilot Time, Co-pilot Time, Flight Engineer Time.  These can contribute towards ATP ratings.
  • CFII Time, Instructor Time (Instrument) - contribute towards DPE ratings.
  • Landings - Towered Airport, Landings - Night, towered airport, Takeoffs - Towered Airport, Takeoffs - Night, Towered Airport.  Hopefully self-explanatory
  • Maximum Altitude - Used for lighter-than-air ratings

The final cluster of properties that are known to the system are used for the Check Flights feature - looking for potential problems or lack of best practices with flights.  Some key properties for check flights are:

  • Simulator/Training Device Identifier - If you log time in a simulator, you are generally supposed to log the identifier of the simulator as well.  Of course, multiple simulators of the same model from the same manufacturer are essentially indistinguishable, one should record the identifier for a given device; this property logs the identifier for that device.  It is available by default whenever a simulator is selected as the flight aircraft.
  • Deadhead - deadhead flights are ignored from flight checks.
  • Approach Name(s)  When logging approaches, one is generally expected to log details of the approach.  The approach description helper on the mobile apps helps to create this property, and the flight checker ensures that it is present for simulator entries. 
  • Safety Pilot Name, Examiner Name - Like the Approach names, these should be logged when somebody serves as a safety pilot or examiner.
  • Cross country fields: cross-country (at least in the US) is a complete mess.  But you can specify the range (in nm) of a cross-country property using a set of fields like Cross-country Time Over 50nm.   Check Flights will compare the distance from the route-of-flight with the declared distance and ensure that they are consistent.
  • (Various Date+Time Fields) - Check flights will check that when there are paired date/time fields (such as Block Out/Block In) that they are appropriately ordered.

Phew.  That's a lot, but alas there's more.

In my next post, I'll talk about additional properties that don't fall into any of the buckets above, but which are useful to know about.

Properties, In-Depth: Part 1 - Goals and Basic Design

 

In a previous blog post,  I discussed a bit about properties for flights, but I think there's actually a lot to talk about here so this is the first in a series of posts about properties in a bit more depth.

I should also start by apologizing for the name "properties"; it's a holdover from the software world where "objects" have "properties"; you can think of it as synonymous to an attribute, or a field of data.  It's really simply a chunk of data that you can attach to a flight: every flight has a set of core fields (total time, PIC time, date, etc.), and zero or more properties that may or may not be present on any given flight. 

Basic Goals

There are really three goals for properties.

One is to enable extensibility of the system without having to make code changes.  Since properties are defined in the database itself, it's a simple update to the database to create new properties.  This helps a lot for the very frequent scenario of a pilot who requests a custom field for one purpose or another.   

But there are problems with custom fields.  One of the very basic is that the semantics of a user-defined field are generally unknown to the system, so it is hard to avoid mistakes or to enforce good data practices; after all, we're all pilots and should be focusing on flying; only I should need to worry about the data.  But another problem is that the odds are really good that if one pilot needs to track something, that another pilot also needs to track the same thing, or something very similar.  Why reinvent the wheel? 

So the second goal of properties is to help keep things orderly and broadly useful across the MyFlightbook community.

The third goal of properties is to enable customization of the logbook to match different flying needs.  A GA pilot typically records different (but overlapping!) data with what a military pilot records, which is different from what an airline pilot needs to track, and so forth.  I discuss this in a bit more depth here and here.

How do they work?

At its core, a property is simply a piece of data attached to a flight that is linked to a property-type.  The property itself is a simple essentially naked piece of data; it is the property type with which it is associated that determines how it is entered, displayed, and otherwise behaves.

The property-type defines the abstract property; this is what you see in the list of properties that are available for a flight, and as of this writing there are nearly 700 of them in the system.  Many properties can be associated with a single property-type.  For example, if you log Solo Time on a dozen flights, that's 12 different values that are each associated with a single shared "Solo Time" property-type definition.

A property-type encapsulates the following:

  • The Title for the property (what you see in the list of available property types).  An example might be "Solo Time"
  • The formatting for how to display the property's data.  E.g., if you have 90 minutes of solo time on a flight, it might display "Solo Time: 1.5", "Solo Time: 1,5", or "Solo Time: 1:30", depending on your locale, or whether you use decimal or HH:MM notation for times
  • A description for the property (this is shown in the little pop-up help tip for the property)
  • Any sort order rules.  E.g., "Block Out" sorts after "Block In", but since you log Block Out first, it makes sense to show that first.
  • The data type for the property (discussed below)
  • Any semantic flags for the property (discussed below).

The data type and flags provide a first level of semantics for the property - how should the property be treated?  For the most part, the system is ignorant of the true meaning of a given property; out of the nearly 700 property types, there are only about 120 or so that are even known by the code, and probably half of those are simply mappings for importing fields from other logbook programs.  But the data type and flags allow the system to work intelligently with all of these properties even without knowing anything about what they mean.

A property-type can be one of 7 data types:

  • Integer.  This is a whole number, and is typically used for things you count like landings or approaches.  With exceptions noted below, these are also summed and displayed in totals by default.
  • Decimal.  These are positive real numbers, typically used for time.  E.g., Solo Time.  Like integers, these are also summed and displayed in totals, and are shown using the formatting appropriate for your settings, including HH:MM.  Any of these properties that is a time (see below) can be cross-filled from the "Total Time" field by pressing-and-holding it (on the mobile apps) or by clicking the little arrow next to it (on the website).
  • Currency.  This is just like decimal except that it is assumed to be a monetary amount.  An example is Fuel Cost.  Note that the specific currency (dollars, euros, yen, etc.) is NOT specified, so it's up to you to use consistent units.  This is formatted using your locale's currency conventions, so "3.1" will show as $3.10 in the US or £3.10 if you use UK settings.
  • True/False.  This is something that is true for the whole flight or not.  An example is a Flight Review or a Checkride.
  • Date. A date, without a corresponding time.  Interestingly, at the moment I don't have any date property-types, but I'm ready if the need ever arises.
  • Date+Time.  A date with a corresponding time, assumed to be Zulu.  An example is Block Out.  These are formatted using your locale's date conventions and are adjusted from UTC to your timezone if you've specified a preferred timezone (website) or have checked the "Use Local Time" option in the mobile apps, but they are always stored as UTC.  As a result, the displayed value can change if your time zone changes.
  • Text. This is free-form text, such as the name of the PIC or the name of the instructor.

The semantic flags identify additional semantics for the property so that the system can be more intelligent in handling it without having to know anything really about what it is and how it works.  Any given flag can be set or not set independently from any other flag.  

Broadly speaking, a given flag either identifies some aspects of how the property behaves but without any particular interpretation/meaning, or it indicate that the property belongs to a group of properties that do have some specific semantic meaning, but where it is not important for the system to know which exact property type it is.

The flags in the first group (identifying how the property behaves) are the following:
  • Exclude from totals.  By default, numerical types (integers, decimals, and currency) are summed and shown in totals, but this doesn't always make sense.  For example, it makes sense to see the total amount  you spent on fuel to track your total spend, but it makes no sense to add the price of a unit of fuel in one flight to the price of a unit of fuel on another flight.
  • Not a time.  By default, numerical types are assumed to be times and hence respect your preference for decimal vs. HH:MM display.  But not all decimals are time.  For example, fuel consumed or distance flown are straight up numerical values.  This flag suppresses HH:MM for such properties.
  • No Autocomplete.  Text properties remember values you've used previously to make it easier to re-enter frequently used values like your student's name or the name of the PIC.  But autocomplete doesn't make sense for properties where re-use is unlikely or rare, such as "first time to airport" or "approach name(s)".
  • All Capitals.  Some text properties, by convention, should be all in uppercase.  "First time to airport" and  "Runways Used" are examples.  These properties display their text in all uppercase letters. 
  • Exclude from Previously Used.  By default, when you use a property, it shows up for subsequent flights on the assumption that you're likely to use it again.  For example, most of us never get to experience the thrill of a carrier landing, but if you record one, there's a really good likelihood you'll be recording more.  But many properties - particularly those indicating (many) checkrides or sign-offs - are ones you'll never use again, so those have this flag and are excluded from the previously-used property list by default.  They're still available to you, you just have to find them in the list.
A note on units: we obviously all use the same measure of time (hours and  minutes) around the world, so a time is always in hours, although it may be displayed in decimal or HH:MM format (e.g., an hour and a half is either 1.5 or 1:30, but those are just two expressions of the same time value).  But decimals that are not times and currencies can have different units: a per diem might be in dollars/day or euros per day, a speed might be knots or mph or km/h, and so forth.  These properties are effectively unitless in MyFlightbook.  Pick a unit to use for it and stick with it.

The remainder of the flags actually identify that a given property has some sort of meaning to the system, so I'll discuss those in my next post.

Hopefully, that explains how I can add new properties to the system with a trivial amount of effort, and without having to change code, and how nearly 700 property types can play nicely together in a system that is truly oblivious to what most of them mean.

Saturday, September 5, 2020

Google Photos integration

Some of the coolest feature ideas come from users.  Today I'm launching one such feature: Google Photos integration.  The idea is pretty simple: pull from your Google Photos collection any images/videos from the date of your flight.

The UI is a little rough (particularly since Google has been giving me the runaround on permission to use their logo on the site), but here's basically how it works:

You can set up integration with Google Photos in Profile->Preferences->Sharing.  You click to enable it, and this will take you to Google Photos, where you'll sign in if needed and approve permission for MyFlightbook to pull images. Once you grant permission, you'll be redirected back to MyFlightbook.  Note that you can revoke this permission at any time. 

Once you’ve done this, you get a little red download arrow next to the “drop files here” space on the flight editing screen:

 

When you click this, MyFlightbook will fetch thumbnails of images/videos from the date of the flight (as entered in the date box on the flight editing screen.)

It fetches in batches; you can click to fetch more (see the circled area below)

 

Each thumbnail has a green plus sign above and to its right.  Click on that to import the full-resolution image/video to your flight.  Google strips any location geotags from the image, but if your flight has appropriate telemetry attached, then I use that to interpolate add a geotag to the image again.