Keeping statistics - one way of doing it

So you want to keep track of your rides and, once you’ve managed to get safely back home, do something “useful” with the data you’ve collected? If yes, read on…

This work-in-progress page is based on the notes Prino has used since he started recording his rides on 16 June 1980 @ 7:47. The notes are pretty simple, you can obviously adapt them to your own requirements.

A possible form to record data

../images/liftnote.png
Prino’s liftnote
The forms Prino uses to record his data look like this and properly spaced you can put three columns with four rows on a sheet of A4 (210x297mm) paper. Fitting three columns on a US “Letter” size sheet (215.9x279.4mm) of paper might be possible if the column widths are reduced. Prino saves his notes in 17-ring binders.

Need a translation?

The key to the detail of the produced statistics is the Opmerkingen section. It’s simply called Opmerkingen as you are unlikely to add specific comments to all of your rides…

For those of you who don’t want to go to the trouble of creating the forms yourselves? There are ready-made versions available here and on that page you can also find some additional “technical” hitchhiking resources.

The fields

What follows is a description of the various fields on the above form. There is one field that might seem to be missing, “Waiting Time”, but it should be obvious that it’s automagically included as the difference between the arrival time of one ride and the departure time of the next ride, and in those cases where something happens in between, the Opmerkingen section comes to the rescue.

Datum (Date)

Pretty obvious.

If you use the ISO 8601 format (YYYY-MM-DD), it’s easy to extend this to rides spanning multiple days by modifying the format into YYYY-MM-DD/DD.

Vertrek (Departure) / Aankomst (Arrival)

Again pretty obvious.

The three columns contain the Tijd (Time), KM-stand (Odometer) and Plaats (Location) of departure and arrival. In cases where no odometer is available, or where it doesn’t work, you can use Google maps to determine distances, Prino has found that it is usually accurate to the nearest kilometre.

The unnamed row below “Aankomst” contains the total time and distance of the ride.

Snelheid (Speed)

The contents of this field depends on individual preferences. Prino puts the real speed in it, i.e. the distance divided by the actual driving time, which is the arrival time minus the departure time minus any time recorded for stops.

Opmerkingen (Miscellaneous notes)

This is a free-format field that you can use for any purpose you like. Why free format? Easy, it’s unlikely that you would need a specific format for all of your rides, e.g. why include specific headings for rides that cross borders or span more than one day, when the number of such rides is likely to be pretty small compared to “normal” rides.

Here’s a non-exhaustive list of things Prino has been using this field for:

There are probably lots of other things you might want to put into it.

If the Opmerkingen section is too small (and Prino has had rides with a dozen stops and going across five borders in two days), he usually continues on the back of the form.

Storing the data on a PC or other device

This is likely to be the most important decision you will have to make. There are (at least) three options:

  1. a (structured) text file, to be processed by a user-written program
  2. a spreadsheet
  3. a database

Each of these options has its pros and cons, here are some details:

Text file

Prino uses the text file option with a few programs he has written himself. The advantage of using this format is the fact that it allows him total flexibility, but it has a pretty big disadvantage in that you have to think very carefully about the format you plan to use: it should be able to cater for future changes without you having to completely rewrite your programs. The format used by Prino, described later, was developed over about 28 years and despite that fact that he has moved to a new format after a few years, the result of not giving the format enough thought initially, is rather cryptic due to more additions since adopting it!

A spreadsheet

If you’re well versed in spreadsheets (or if not, try LibreOffice, it’s free) you might want to consider using one to process your data. It will have the big advantage that you can insert or delete columns in your source data and the program will automagically update the references in all other cells and/or sheets. Combined with the many conditional functions, you should (probably) be able to produce any statistics you like, although some of the more esoteric ones Prino’s program creates might be pretty hard (or even impossible, but never say never) to replicate.

If you want to use Prino’s input file format as described below, but would also like to use a spreadsheet to generate tables that lift doesn’t generate, you can use dat2csv to generate “lift.csv”, which contains a reduced, information about country- and day-splits, and in-ride stops is removed, subset of the data in “lift.dat”.

A LibreOffice “Calc” spreadsheet you might use as a starting point, but which heavily relies on the format of the input file used by Prino, is lift & v100+.ods.

A database

What was written about spreadsheets also holds true for databases. Not having used any PC database programs, Prino cannot recommend any, but there are plenty of free ones, LibreOffice “Base” and MariaDB, to name just two of the more well known ones. Creating your statistics will mean writing queries (most likely in the fairly easy to learn language SQL), but given the non-procedural nature of this language, some results that can be created with a self-written program or a spreadsheet may be hard or even impossible to recreate.

Prino’s original program

As mentioned above, and being a programmer by profession, Prino selected the first method of storing the data, a text file. The first 60(!) versions of his program were written in Turbo Pascal (V3.01a) and until about version 20 they used “Version I” of a simple CSV file with the data. It could handle rides passing through multiple countries and spanning more than one day, but did not know anything about ferry crossings, stops, or time-zones, to name but a few of the things that arrived later…

Given that the old format became obsolete a long time ago, it’s not interesting to go into the nitty-gritty of it, but its output mimic’ed his manually created five tables per trip, containing:

Simple, uncomplicated and one might assume that most hitch-hikers would leave it at this…

Prino’s current program

The current program is written in Virtual Pascal V2.1.279 (or PL/I, should you want to run it on IBM’s z/OS). It is licensed under the provisions of the GPL V3. The “authenticity” verified WinRAR archive containing the sources and executable files can be found as “lift32bit.rar”.

Data format used by Prino’s current program

The “simple” format was used until the end of 1994. Due to the fact that Prino wanted to add some additional statistics to the output files, it was changed into something a bit more logical, although some people might find otherwise. (And they are right, it’s a right-royal mess due to more additional requirements, and Prino would like to simplify some of the more esoteric uses of punctuation, but that’s unlikely to happen anytime soon as he has a list of additional tables he would like to add first)

The current format, split into two parts to avoid scrolling, looks like this:

....v....1....v....2....v....3....v....4....v....5....v....6....v....7....v....8....v....9.. 999, 9999, AAA, 99999.9, HHH.MM, 999.9, NAT, TYPE, CTY, HH.MM, S, HH.MM, HH.MM, YYYY-MM-DD | | | | | | | | | | | | | | a b c d e f g h i j k l m n ..v....0....v....1....v....2....v....3....v....4....v....5....v....6....v....7....v....8....v....9....v....0....v , 999999.9, xx, DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD , AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | | | | o p q r

and the fields used in it are:

Col   1 -   3 (“Trip”)
Col   6 -   9 (“Ride”)
Col  13 -  15 (“Day”)
Col  18 -  24 (“Distance”)
Col  27 -  32 (“Time”)
Col  34 -  40 (“Velocity”)
Col  43 -  45 (“Nationality”)
Col  48 -  51 (“Type”)
Col  54 -  56 (“Country”)
Col  59 -  63 (“Wait”)
Col        66 (“Split”)
Col  69 -  73 (“Departure time”)
Col  76 -  80 (“Arrival time”)
Col  83 -  92 (“Date”)
Col  95 - 102 (“Odometer”)
Col 105 - 106 (“Departure type”)
Col 109 - 155 (“Place of departure”)
Col 159 - 205 (“Place of arrival”)

Notes:

 [1] Prino uses Distinguishing Signs used on Vehicles in International Traffic (Local copy) and the List of international vehicle registration codes on Wikipedia. Due the fact that three of these have changed after Prino encountered them for the first time, he still uses “GB” for Great-Britain, “SF” for Finland, and “ROU” for Uruguay, rather than the current “UK”, “FIN”, and “UY”.

 [2] Given that Prino has never encountered a triple crossing with a backward moving time-zone (e.g. F-GB at midnight), he doesn’t expect the program to handle them, and, as yet, has no interest to test hypothetical cases. (And don’t even think about quadruple(!?) crossings)

 [3] Prino never records the waiting time before the first ride of the day, unless the first ride of the day happens to be one that continues directly after the last ride of the previous day, without any intervening (sleep?) stop.

 [4] The normal “.” separator in the waiting time must be replaced by a “:” (colon) for those waits caused by the departure from a ferry terminal where you haven’t been able to get a ride on the ferry (and may have had to wait until the next ferry…)

 [5] Multiple split lines may be present, but they must be grouped, and the groups must be in “#”, “*”, “!” order!

 [6] The normal “.” separator in the departure time must be replaced by

 [7] Non-stopping (i.e. drive-through) border crossings must not record an arrival time, unless the time-zone changes.

 [8] The normal “.” separator in the arrival time of a time-zone changing border crossing must be replaced by

 [9] The places of departure and arrival must be UTF-8 encoded and their length is (currently) limited to 47 bytes!

[10] Lines must not contain trailing blanks, but completely blanks lines, consisting of just a CR/LF, are allowed.

[11] Although the data is in CSV format, all positions are fixed!

[12] Lines starting with “{” in column 1 are treated as comment or meta-data. A description of the meta-date format can be found below.

[13] Columns containing numerical data or times must be right aligned, columns containing text must be left aligned, and if the textual data is shorter than the column width, the separating comma may follow it without intervening blanks, except for the departure location.

[14] The “Odometer” data is (currently) completely ignored by the main lift program.

[15] Lines longer than 255 characters are (currently) completely ignored by the main lift program.

Metadata

As Prino didn’t want to make the format of the data even more complex than it already is, he decided to allow for comments and meta-data to be embedded into the input file. Both comments and meta-data start with a “{” and can be up to 255 characters long.

The (currently) defined, but only partly used types of meta-data are:

Col         1
Col         2…
Time-zone information
The meta-data contained in lines starting with “{Z-” or “{Z+” provide information about the time-zones for the countries passed in a trip. The difference between the two variants is that time-zone information following a “{Z-” completely replaces the current set of countries/time-zone pairs, whereas “{Z+” will add additional countries/time-zone data pairs, or replace existing ones. The option can be used in multi-zonal countries, or in trips that span the change from winter- into summer-time, or the reverse.

Up to 31 country/time-zone data pairs immediately follow the “{Zx” and consist of eight characters,

Note that if a trip spans more than 31 countries, time-zone data for additional countries can be added via “{Z+” meta-data.

Partner data
The meta-data contained in lines starting with “{<” and “{>” provide a means of embedding data from (a) hitchhiking partner(s) in your own data, provided the partner data is an exact subset of your own data.

The “<” character must be followed by ␣tttt␣rrrr␣dddd␣-␣name-of-partner where

indicates a single blank character
tttt
is the value that will be subtracted from the “Trip” to give the actual trip number for the partner
rrrr
is the value that will be subtracted from the “Ride” to give the actual ride number for the partner
dddd
is the value that will be subtracted from the “Day” to give the actual day number for the partner
name-of-partner
will be used by the get-aud program when data for a specific partner needs to be extracted

The “>” character must be followed by ␣-␣name-of-partner to indicate the end of the embedded data.

Interruption information
The meta-data contained in lines starting with “{I” provide a means of embedding information for use in h-h2html, such as non-hitching breaks, or even addtional html!

The use of the “I” character is further explained in the notes following the description of that program.

Google short URL
The “H” character is currently not used by any programs. It is followed by the trip, ride, Google Maps short URL, departure and arrival locations and the distance between them returned by Google Maps. In data for more recent rides, the full Google Maps URL is also included to prevent loss of data should Google become even more evil in the future - nearly all of the original five character short URLs, many of them encoding non-trivial deviations of the routes followed, in “lift.dat” are no longer working…

Due to the fact that the routes may contain privileged information, “{H” tags are no longer included in the archived copy of “lift.dat” that Prino makes available on his Google Drive.

Click here for the current format, which may be subject to change!

In the following indicates a single blank.

Col   1 -   3 (“ID”)
  • “{H␣”

Col   4 -  11 (“Trip/Ride”)
  • the trip and ride this URL meta-data belongs to, in the format “ttt.rr:␣”, where both “ttt” (the trip) and “rr” (the ride), separated by a “.”, have leading zeros.

Col  12 -  49
Col  50 -  97
  • the departure location, left aligned in a field with a length of 47 bytes, followed by a single “␣”, for the above short URL it would be “Raststätte Lappwald Nord......................␣” on Autobahn A2 in Germany.

    And note that you will count only 46 characters before the “␣”, the “missing” one is caused by the fact that the “ä” is encoded in two bytes using UTF-8, if you would look at the data in raw (byte) format in a hex-editor like HxD, they might show up as

    • “ä” (“ANSI”)
    • “├ñ” (“DOS/IBM-ASCII”)
    • “√§” (“Macintosh”)

Col  98 - 145
  • the arrival location, left aligned in a field with a length of 47 bytes, followed by a single “␣”, for the above short URL it would be “Raststätte Rhynern Nord.......................␣” on Autobahn A2 in Germany.

Col 146 - 156
  • the length of the route followed, in the format “dddd.d␣km␣␣”, where leading zeros may be replaced by blanks, for the above short URL it would be “␣270␣␣␣km␣␣”.

Col 157 - eol
UTF-8 encoded departure or arrival location
The “U” character is currently not used by any programs. It will (at some time in the future) be used to allow the use of UTF-8 encoded locations that exceed the current 47-byte limit.

The format of “{U” metadata is:

{U␣x␣CC␣????a, where

indicates a single blank character
“x”
can be either “d”(eparture) or “a”(rrival)
“CC”
is the 2-character ISO 3166-1 country code
Split-year trips
The meta-data contained in lines starting with “{V” provide a means of embedding offsets that are required to normalise the ride and day number for processing by lift, as the program cannot natively handle trips that start with a ride or day other than 1 and 1.

This meta-data should not be entered manually, it will automagically be added by datsplit, the program that is used to split the input file for lift into separate files per trip and per year.

The “V” character must be followed by ␣rrrr␣dddd where

indicates a single blank character
rrrr
is the value that will be subtracted from to the “Ride” to give the internal-use-only ride number for this trip
dddd
is the value that will be subtracted from the “Day” to give the internal-use-only day number for this trip
For Prino’s eyes-only information
The meta-data contained in lines starting with “{^” allow Prino to add personal notes to some of his rides, such as names and (email) addresses of his drivers. A simple invocation of “sed” with a command-line of -i “/^{\^.*$/d” input-file will quietly remove these lines from the file that is publicly accessible. Which means you will never see such lines!
z/OS using EBCDIC
The lowercase “ascii” string metadata is only required if the input file is transferred to z/OS which uses EBCDIC rather than ASCII/UTF-8, and the resulting output needs to be transferred back, via the same procedure, to the original ASCII/UTF-8 based system.

The explanation for the above is rather technical, but it boils down to the fact that there are at least three ways,

  1. FTP,
  2. IND$FILE, an IBM proprietary protocol, and
  3. the Work Station Agent (an IBM tool supplied with ISPF, the z/OS “IDE”),

of transferring data between the ASCII/UTF-8 realm and z/OS. All three allow lossless transfers from and to z/OS, but all use (in many cases) different translate tables for ASCII control characters (0x00..0x1F) and characters between 0x80..0xFF (many of which are used to encode UTF-8 characters). Using the ASCII metadata allows programs written in PL/I (and COBOL) to detect UTF-8 characters no matter which transfer procedure was used. Feel free to email me if you want a full explanation.

The results of Prino’s current programs

The current programs produce rather a lot more output than the five tables per trip! In fact the main program now produces eight files and an optional additional post-processor program that translates the output into .RTF format creates two additional files with two tables sorted in various other orders. The programs and files, assuming their default names, they produce are:

The main program, lift

Disclaimer: Much of the code in lift was written before Prino implemented support for time zones, and even now he does not record the odometer reading at the “correct” midnight for those rides that span multiple days!

As a consequence, the following tables might contain erroneous or misleading data:

For the moment, and that moment may well last forever, Prino has given up finding a solution for this problem, other than forgetting about timezones, and using a clock set to UTC…

lift produces eight files, described in the following sections.

“summ.h-h” - A general summary

This file contains more than 100 tables, some of them broken into several parts because they would otherwise require A3 or A2 size paper. (Total below doesn’t count individual tables of sets). Here’s the full list:

  1. two tables of totals for every trip
  2. a table of totals for all distances
  3. a table of totals for all types
  4. a table of totals for all countries
  5. a table of totals for all nationalities
  6. a table of totals for all speeds
  7. (up to) five tables of totals for all waits
  8. two tables of ferry related waits (*)
  9. three tables of pick-ups
  10. a table with the distribution of hourly departure times per weekday

  11. a table with the first and last ride for all distances
  12. a table with the first and last ride for all types
  13. a table with the first and last ride for all countries
  14. a table with the first and last ride for all nationalities
  15. a table with the first and last ride for all speeds
  16. two tables of waits per trip, split in short and long waits
  17. a table of waits per country, split in short and long waits
  18. a table of waits before departure times (also s & l split)
  19. a table of waits per weekday (also s & l split)
  20. a table of waits per month (also s & l split)
  21. a table of waits per year (also s & l split)
  22. a max/min/average summary for all rides
  23. a max/min/average summary for all days (See disclaimer)
  24. a max/min/average summary for all types
  25. a max/min/average summary for all nationalities
  26. a max/min/average summary for all countries
  27. a table of rides per country, split in internal and border crossing rides
  28. a table of rides per country, split in native and “foreign” drivers
  29. two tables of longest (km/#r) consecutive distance per country
  30. four tables for the max/min speed & max/min rides for a given number of distances
  31. four tables for the max/min speed & max/min distance for a given number of rides
  32. four tables for the maximum number of rides exceeding a number of selected velocities, maximized for the number of rides and the distance,
  33. four tables for the maximum number of rides exceeding a number of selected lengths, maximized for the number of rides and the distance,
  34. a max/min/average summary for all weekdays (See disclaimer)
  35. a max/min/average summary for all months (See disclaimer)
  36. a max/min/average summary for all rides per year
  37. a max/min/average summary for all days per year
  38. a table of distribution of distances per trip
  39. a table of distribution of velocities per trip
  40. four tables for the max/min speed & max/min trips for a given number of distances
  41. four tables for the max/min speed & max/min distance for a given number of trips
  42. four tables for the maximum number of trips exceeding a number of selected velocities, maximized for the number of trips and the distance,
  43. four tables for the maximum number of trips exceeding a number of selected lengths, maximized for the number of trips and the distance,
  44. a table of distribution of distances per day (See disclaimer)
  45. a table of distribution of speeds per day (See disclaimer)
  46. a table with the first and last day for all distances (See disclaimer)
  47. a table with the first and last day for all speeds (See disclaimer)
  48. four tables for the max/min speed & max/min days for a given number of distances (See disclaimer)
  49. four tables for the max/min speed & max/min distance for a given number of days (See disclaimer)
  50. four tables for the maximum number of days exceeding a number of selected velocities, maximized for the number of days and the distance,
  51. four tables for the maximum number of days exceeding a number of selected lengths, maximized for the number of days and the distance,
  52. a table with totals per weekday (See disclaimer)
  53. a table with totals per month (See disclaimer)
  54. a table of general totals per year
  55. a table with first/last ride/trip per year
  56. a table with usage of days per year
  57. a table with pickups on days per year
  58. a table with pickups per weekday per month
  59. a table of totals for consecutive days (See disclaimer)
  60. two tables of totals for 24 hour periods
  61. a table of totals for 365 (or 366, if the period contains 29 February) day periods (See disclaimer)
  62. a table of minimum number of rides needed for selected numbers of nationalities
  63. two tables (trip/year) with the number of calendar days, types, countries and nationalities of drivers met during the trip/year, split in total and “new”
  64. four tables (two per type, two per nationality) with
  65. a table of pickup times per 6-hour interval per country
  66. two (ride + day) sets of three tables with 10% information about rides/days, distances, and times
  67. a table of DTV (+ L=) per type (“Thumb”, “Ask”, or “Other”) of pickup
  68. a table of waits per type of pickup, split in short and long waits
  69. six tables (three per country and year) for each type of pickup, split into internal and external rides
  70. a table with indicators which countries have been hitched-in or hitched through and with locals or foreigners
  71. three tables showing the progressive maxima for distance, time, and velocity
  72. four tables (two for foreigners, two for natives) showing the progressive longer numbers and distances covered by both
  73. two tables (per type & nationality) for the longest non-stop ride and the distribution of number of stops
  74. a table of progressively longer distances per calendar day for a single country
  75. a table showing the distribution of the number of borders crossed for rides starting in a given country
  76. a table showing the longest (distance wise) and fastest rides crossing a set number of borders

“lift.h-h” - Detailed summaries per trip, type, country, nationality, and year

This file contains detailed summaries per trip, type (of driver/vehicle), country, nationality (of driver), and year. It contains a section for each of these entities, split by “Totals per type/country/nationality/year” separator pages.

The “per trip” section

The “per trip” section contains four pages per trip:

Page 1
  1. a table with totals per day (See disclaimer)
  2. a table of totals for all distances
  3. a table of totals for all types
  4. a table of totals for all countries
  5. a table of totals for all nationalities
  6. a table of totals for all speeds
  7. a max/min/average summary for all rides and days (See disclaimer)
Page 2
  1. a table of totals for all waits
  2. a table of the statistical waiting time distribution
  3. a table of all in-ride waits per category (*)
  4. a table of all ex-ride waits per category (*)
  5. a table of waits per country, split in short and long waits
  6. a table of successively longer distance per 24-hours
Page 3
  1. three tables of pick-ups
Page 4
  1. a max/min/average summary for all types
  2. a max/min/average summary for all nationalities
  3. a max/min/average summary for all countries
  4. two tables detailing distances per country

The “per type” section

The “per type” section (currently) contains two pages per type (of driver/vehicle), containing the following seven tables:

Page 1
  1. a table of totals for all distances
  2. a table of totals for all countries
  3. a table of totals for all nationalities
  4. a table of totals for all speeds
Page 2
  1. a table of progressively longer rides for this type
  2. a table of progressively faster rides for this type
  3. a table of DTV (+ L=) per type (“Thumb”, “Ask”, or “Other”) of pickup
  4. a max/min/average summary for the type

Note that the “per type” section individual per-type pages do not contain a totals-per-type table, as it would contain just a single line with the totals for that particular type. Instead the type is merged into the heading of the totals-for-all-distances table.

The “per country” section

The “per country” section (currently) contains one page per country travelled in, containing the following five tables:

Page 1
  1. a table of totals for all waits
  2. a table of the statistical waiting time distribution
  3. a table with the distribution of departure times
Page 2
  1. a table of DTV (+ L=) per type (“Thumb”, “Ask”, or “Other”) of pickup
  2. a table of waits per type of pickup, split in short and long waits
  3. a table of progressively longer distances per calendar day for this country
  4. a table with the longest/fastest rides starting in this country and crossing successively more borders
  5. a max/min/average summary for the country, containing two rows, one for the non border-crossing rides, and one for the border-crossing rides

Note that this section does not include a totals-per-country table. Like in the “per type” section, the country is merged into the heading of the first table on the page.

The “per nationality” section

The “per nationality” section (currently) contains one page per nationality of driver, containing the following seven tables:

Page 1
  1. a table of totals for all distances
  2. a table of totals for all types
  3. a table of totals for all countries
  4. a table of totals for all speeds
  5. a table of progressively longer rides for this nationality
  6. a table of progressively faster rides for this nationality
  7. a max/min/average summary for the nationality

Note that the “per nationality” section individual per-nationality pages do not contain a totals-per-nationality table. It follows the format of the two previously described sections, and merges the nationality into the heading of the first table on the page.

The “per year” section

The “per year” section (currently) contains six pages per year, containing the following tables:

Page 1
  1. a table of totals for all distances
  2. a table of totals for all types
  3. a table of totals for all countries
  4. a table of totals for all nationalities
  5. a table of totals for all speeds
  6. a max/min/average summary for all rides and days (See disclaimer)
Page 2
  1. a table of totals for all waits
  2. a table of the statistical waiting time distribution
  3. a table of all in-ride waits per category (*)
  4. a table of waits per country, split in short and long waits
Page 3
  1. three tables of pick-ups
Page 4
  1. a max/min/average summary for all types
  2. a max/min/average summary for all nationalities
  3. a max/min/average summary for all countries
  4. a table that summarizes the distance per country, split in non border-crossing and border-crossing rides
Page 5
  1. a table with the longest consecutive distance inside each country visited in the year
  2. a table with all per-country segments for the whole year
Page 6
  1. a table of totals for all distances per day (See disclaimer)
  2. a table of totals for all speeds per day (See disclaimer)
  3. a table with totals per weekday (See disclaimer)
  4. a table with totals per month (See disclaimer)
  5. a table with progressively longer 24 hour periods
  6. a table with the total period in days hitched during the year

Like in all previous sections, the year is merged into the heading of the first table on page 1 of each “per-year” page.

Additional notes regarding the “lift.h-h” file

“days.h-h” - Per day summary

This file contains a single table with a line for every calendar day of every trip, detailing

A follow-up program, dayform, will process this file, putting the original single column data into four columns of 70 rows. It also sorts the file into three additional orders, Distance, Time and Velocity. If the data is required to be in .RTF format, this program is required.

“trip.h-h” - Formatted input data

This file contains the input data into a neat table, omitting the odometer, place of departure and arrival columns. lift will paginate trips that do not fit on a single sheet of A4 paper.

“week.h-h” - Weekday per year summary

This file always contains the following two tables,

  1. a table with the number of times and distance/time/velocity hitched on every weekday (Mon to Sun) for every year, and
  2. a table of pickups and distance/time/velocity per weekday per day of the month (+ totals).

However, if the input file contains more than 1,000 rides, the second table is split out into an additional 12 tables, one per month, replacing the pickups by number of days hitched.

“mnth.h-h” - Month per year summaries

This file contains five tables with monthly data,

  1. a table containing days hitched and distance per month per year, (See disclaimer)
  2. a table cumulating the results of the previous table, giving a running total per year, (See disclaimer)
  3. a table detailing the total distance per calendar day per month, (See disclaimer)
  4. a table detailing the first use (or not) of all 366 calendar days, and
  5. a table simply containg a list of days hitched, distances, time and velocities for every month. (See disclaimer)

Like the first table in “week.h-h”, the first four tables in this file do not contain time or velocity data.

A follow-up program, mnthform, will process this file, merging the first four originally-split-in-half tables, and putting the original single column data of the fifth into four columns of (up to) 70 rows and sorts this table into four additional orders, Days, Distance, Time and Velocity. It also produces five additional pages with per calendar month tables sorted in days, distance, time, verlocity, and average distance per day per month. If the data is required to be in .RTF format, this program is required.

“ntop.h-h” - Top-N tables

This file contains sets of three Top-N tables:

  1. three top-50 tables for all rides (for distance, time, and velocity)
  2. three top-10 tables for each trip, type, country, nationality, and year (ditto)

In those cases where there are less than 10 rides in a trip, for a type, in a country, for a nationality, or in a year, the Top-10 may actually reduce to, in some cases, a Top-1, which is then repeated three times for distance, time, and velocity…

“xtra.h-h” - stuff

This file contains currently two tables that should really be in “summ.h-h”, but due to the fact that they are in landscape format, with lines much longer than the self-imposed 121-character line length limit of that file, they are in this file.

The two tables in this file are

  1. a table containing the details of the ride where Prino reached a “milestone” in number of rides
  2. a table containing the details of the ride where Prino reached a “milestone” in the hitched distance

An optional program, newlift

The set of programs contains an optional program, newlift, which can be used to remove all data that does not relate to the current trip from

which is kinder to trees, if you insist on also keeping the results on paper.

Two more, somewhat less optional, programs, dayform and mnthform

dayform is a post-processor for lift. It takes in “days.h-h”, and spits it out in a multi-column (4x70) format. It also sorts the input file into three additional (distance, time, and velocity) orders and outputs those in the same multi-column format.

mnthform is another post-processor for lift. It takes in “mnth.h-h”, merges the first four per-six-months tables, and converts the single column per-month data into a multi-columnar (4x10n, n=1..7) format, creating a set of ten tables,

  1. Months in Year order,
  2. Months in Days order,
  3. Months in Distance order,
  4. Months in Time order,
  5. Months in Velocity order,
  6. Months in Days per month order,
  7. Months in Distance per month order,
  8. Months in Time per month order,
  9. Months in Velocity per month order, and
  10. Months in average distance per day per month order.

Note that newlift actually modifies the “lift.h-h”, “ntop.h-h”, and “trip.h-h” files, whereas dayform and mnthform will spit out the result of processing “days.h-h” and “mnth.h-h” into new files, “days.h-c” and “mnth.h-c”.

Last updated on 24 January 2023 (Use of “Nat” for “ex-ride” waits)

Free counters!