Vision
From a travel survey of one to travel surveys within reach.
HHT Diary started with TripLibre, one transportation researcher's private travel diary. The long-term aim is to make collecting and understanding travel-behaviour data more accessible, transparent, affordable and user-controlled: an open toolkit that anyone can use without a vendor contract, a server, or giving up their location history.
Today
A personal tool, not yet a survey platform.
TripLibre for iOS records where its user goes, rebuilds each day into visits, trips and travel modes, lets the user correct it in a tap or two, and exports the result. Everything is stored on the phone. It has one user per install, no account and no server. Available
There is no way yet to enrol participants, configure a study, or collect data from more than one phone. Those ideas are on the roadmap as Planned or Exploratory.
The gap
Three groups need travel data and rarely share a tool.
HHT Diary tries to put the planner's data model, the developer's engineering and the researcher's need for transparency into one open codebase.
planners
Transportation planners
Know what a good household travel survey (HHTS) looks like: person-days, trips, modes, purposes, tours. Usually buy the collection from a vendor.
developers
Software developers
Can build reliable background location and clean exports, but rarely see survey conventions or what researchers need to defend a dataset.
researchers
Resource-constrained researchers
Students, small agencies, community groups and teachers who want travel data but can't fund a commercial smartphone-survey platform.
Principles
What every HHT Diary tool holds to.
Free
No subscription, paid tier, ads or data resale.
Available
Open source
Apache 2.0. Every line that touches location data can be read, audited and forked.
Available
Local-first
One SQLite file on the phone. No account, no sync, no analytics SDK.
Available
Privacy-first
Network access is limited and listed on the Privacy page. Data leaves only when the user exports.
Available
Transparent
Inference rules are deterministic, documented and tested. Raw data is never rewritten.
Available
User-controlled
The user decides what to correct, what to export and when to erase. Finer-grained export is planned.
Available Planned
Adaptable
Thresholds live in one config struct and a calibration harness measures changes. Study-specific configuration is planned.
Available Planned
Honest
Every page separates what exists today from what is only intended, and says what TripLibre is not.
Available
Long-term initiative
Cities with limited capacity.
Exploratory
The gap is widest in many developing cities and countries. Travel patterns there often change fastest, through rapid urban growth, new transit lines and informal transport, yet many cities have no recent household travel survey at all. A traditional survey costs a lot, commercial platforms charge licence fees and often store data abroad, and a local agency may not have the software staff to build or maintain its own tool.
TripLibre's design points at that problem. It is free to use and to change, works offline, keeps data on the phone, follows familiar travel-survey concepts, and documents every inference rule so local analysts can check and adjust them instead of trusting a black box.
It is not ready for this today. Before TripLibre could help:
- Android is a prerequisite. In many of these places most residents use Android phones, and TripLibre runs only on iPhone.
- The interface needs local languages, and place categories and modes need local options: shared taxis, minibuses, motorcycle taxis, walking as the main mode.
- Inference needs local calibration. The rules were tuned on one person in Philadelphia; dense informal transit, very different speeds and other GPS conditions will behave differently.
- A study design is still needed. TripLibre would make data collection cheaper, not representative. Sampling, recruitment, weighting and ethics review stay with the local team.
- It would need local partners who know the city, can train data collectors and can own the data.
If you work with a city or agency in this situation, an issue describing the context is the most useful starting point. The steps that would lead here are on the Roadmap.
Limits
What TripLibre is not.
Being clear about limits matters more than the vision itself.
- Not a representative household travel survey. A regional HHTS relies on a sampling frame, recruitment, weighting, household rosters and nonresponse follow-up. TripLibre provides none of that. It offers accessible basic data collection: a clean, correctable trip diary from whoever chooses to run it. A set of TripLibre diaries is a convenience sample unless a study design makes it something more. See Research uses & limitations.
- Not risk-free. Keeping data on the device removes the server, not the risk. A trace of where someone sleeps and works can re-identify them, the phone can be lost or backed up to iCloud, and an export can be forwarded. TripLibre reduces privacy exposure; it does not eliminate it.
- Not validated at research grade. Its accuracy has been measured on a small personal sample, not benchmarked against a formal ground truth across many people. See Validation.
- Not a behaviour-change app. No streaks, goals or nudges. It records and summarises.
Who it serves
Everyday users and the people who study travel.
| Who | What they can do today | What would help them later |
|---|---|---|
| Anyone wanting a private travel diary | Install from source, record, correct, export. Available | An App Store build, no Xcode needed. In progress |
| Researchers studying their own travel (N-of-1, longitudinal) | Analyse HHTS-shaped exports in Python, R, SQL or QGIS. Available | Validation fixtures and a published accuracy benchmark. Planned |
| Teachers and students | Use the code and synthetic demo data to teach trip reconstruction and HHTS concepts. Available | Tutorials and teaching datasets. Planned |
| Small exploratory studies | Volunteers export and hand over their own data under the study's consent process. Available, but manual | Selective export, study configuration and prompted recall. Planned |
| Agencies and larger studies | Read the code as a reference implementation. | A research edition with multi-device, self-hosted infrastructure. Exploratory |
| Cities and countries with limited budgets or technical staff | Read and adapt the code; nothing turnkey yet. | Android, local languages and modes, local calibration, partner-led studies. Exploratory |
How we'll get there
Two editions, one engine.
The personal edition is today's app: a private diary that stays simple. A possible research edition would add what studies need without loading those features onto everyday users. Both would share the same inference engine and data format. Nothing here expands what the first App Store version will contain.