Research

Research uses & limitations

TripLibre produces a household-travel-survey-shaped diary from one phone. That is useful for some research questions and misleading for others. This page is meant to help you decide which kind yours is, before you collect anything.

TripLibre today is a single-user app. A study with several participants means each person installs TripLibre, exports their own data and hands it over under your consent process. There are no built-in study, enrolment or upload features (see the roadmap).

What TripLibre data is good for

Use	Why TripLibre fits	Watch out for
Longitudinal mobility (N-of-1, small panels)	Continuous recording over months, with life phases to compare semesters, jobs or moves.	Collection gaps (expired install, permissions, dead battery) look like "no travel".
Trip and stay inference research	Raw fixes and motion are kept beside the inferred and corrected diary, so a new algorithm can be compared with the old one on the same input.	Edited records overwrite the engine's first answer. See Validation.
Mode classification	Every mode correction is in `audit_log`: a labelled set for evaluation or training.	Labels come from whoever corrected them, only on trips they chose to review.
Human-in-the-loop correction	The app records which records were confirmed, edited, created or deleted (`user_status`, `audit_log`).	Correction effort varies by person and over time.
Exploratory or pilot surveys	No vendor, no licence fee, HHTS-like output (person-day, trip, segment, mode, purpose, tour).	Not a substitute for a designed, weighted survey.
Teaching	Readable, tested Swift and Python; synthetic demo days in the simulator; documented metrics.	Use demo or self-collected data. Don't pass classmates' raw traces around.
Low-budget research	Only needs a Mac to build and iPhones the participants already own.	Who owns an iPhone is itself a selection filter.

Biases and data-quality limits

Who ends up in the data

Sampling and self-selection. People who install a travel-tracking app are not a random sample. Expect them to be more interested in data, technology or their own travel.
Phone access. TripLibre runs only on iPhones with iOS 17 or later. iPhone ownership varies by income, age, region and country. People without a smartphone, or who share one, are excluded entirely.
Nonresponse and attrition. Some people decline, some stop recording, some don't correct their diary. Those who keep going differ from those who stop.
Data-sharing selection. Even with full consent, participants may export only some periods, or withdraw days they consider sensitive. The days you receive are not a random subset of the days they lived.
Representativeness. Without a sampling frame and weights, totals and shares describe these participants, not a population. Report them that way.

What the sensors miss

GPS drift. Indoors and in dense downtowns, fixes wander by hundreds of metres. That can split one stay into two or invent a short trip. TripLibre filters most drift, but large venues still cause duplicate stays.
Signal loss. Underground and in some vehicles there are no fixes for minutes. Subway trips are inferred from the blackout itself; distances and routes are straight lines across the gap.
Short stops and access walks. Stops under about five minutes and very short walks are often absent unless the user stamps or adds them.
Incomplete days. If collection stops (permissions revoked, a 7-day signature expired, battery died), the day is partial. TripLibre flags trips with a gap of more than 15 minutes (has_gap) but cannot know what happened during a silence it never recorded.
Mode confusion. Bus and car look alike without transit schedules; fast surface rail can look like a car. Measured accuracy is on the Validation page.

What trajectories alone can't tell you

A GPS trace records where and when. It doesn't record:

Purpose: TripLibre guesses from the destination's place category, which you set. An unnamed place has no purpose.
Who else was there: household members, passengers, escorts, trip companions.
Driver or passenger: auto-classification says car; only a correction says car_driver or car_passenger.
Cost, unless you note it: TripLibre asks about fares and paid stops, but costs are self-reported, optional and unconverted between currencies, so expect gaps. Vehicle type and how a trip was paid for aren't recorded.
Household context: income, car ownership, licence, household size, the usual HHTS demographics.
Why not: trips not taken, constraints, unmet demand, satisfaction.

If your question needs any of these, pair TripLibre with a questionnaire, and say so in your methods.

Privacy and ethics

Location traces identify people. A few home and work locations are often enough to re-identify someone, even with names removed. Treat raw_location_points, visits, places and routes as identifiable personal data.
Ethics review. Research with other people's location data usually needs ethics or IRB approval. Plan consent, storage, retention and deletion before anyone installs the app. TripLibre does not handle any of this for you.
Export selectively, today, by hand. The Include raw GPS points switch and the 30-day range apply to the CSV and JSON files only. Every export also contains a full travel.sqlite snapshot, so for minimal sharing delete that file (and anything else you don't need) before it leaves the phone. See what an export contains.
Publish aggregates. Mode shares, trip rates and distances by group are usually safe; individual diaries, home locations and routes are not. Aggregate over enough people and days, and drop small cells.
Third parties. Places a participant visits can reveal others: a friend's home, a clinic, a place of worship.

Reporting checklist

When you publish work that uses TripLibre data, readers will want to know:

The TripLibre release or commit you built, the schema version (Settings › Database, and schema_version in every export's data.json), and the software citation.
How participants were recruited, how many started, and how many contributed usable days.
How you defined a usable or complete day, and how many days were excluded.
Whether participants corrected their diaries, and how you treated uncorrected (user_status = auto) records.
Which fields came from inference, which from corrections, and which from a separate questionnaire.
How location data was stored, de-identified and deleted.

Data dictionary: every exported file and column.
Validation: what has been measured, and how.
How inference works: the rules behind visits, trips and modes.
Privacy: what stays on the phone and what doesn't.