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.