Origin-Destination Survey Software
Ask people to type two addresses and you get refusals, bad geocodes, and no idea how they got from one to the other. Hand them a map and ask them to draw the trip, and you get real geometry — endpoints, path, and all — that lands in your GIS as GeoJSON.
The problem with address-based OD collection
Origin-destination data is the backbone of travel-demand modeling, service planning, and just about every corridor decision an agency makes. The traditional way to collect it from riders — ask for an origin address and a destination address — breaks down in three predictable places.
- Refusal. A meaningful share of respondents will not type their home address into a web form, and the ones who will are not a random sample of the ones who won't.
- Geocoding failure. Rural routes, apartment complexes, informal addresses, and simple typos all produce points that land in the wrong place, and nothing in the response tells you which ones are wrong.
- No path. Two points tell you nothing about the route taken. If the reason for the study is to understand why riders avoid a particular transfer, endpoints alone will never show it.
Drawing beats typing — especially on a phone.
A Route Creator question puts an interactive map in front of the respondent and asks them to trace the trip. On a phone that's a handful of taps; typing two addresses on the same device is a minute of frustration and a likely abandon.
- Full coordinate capture along the drawn geometry, not just endpoints
- Map Boundaries constrain drawing to your study area — state, county, place, or a polygon you draw
- Combine with Route Display to ask about a specific existing line in the same survey
- Route Ranker for prioritizing candidate alignments once you know where people go
What about the zip code?
The optional pre-survey profile step collects zip code independently of the map question. For a lot of modeling work zip-level origins are the working resolution anyway, and asking for a zip has far lower refusal than asking for a street address. TIPS can seed ZIP centroids so those responses plot on the density map alongside drawn routes.
It lands in your GIS, not in a spreadsheet you have to reshape.
Every export is two paired files: a flat CSV of the survey answers and a GeoJSON FeatureCollection of the map geometry, joined on the response.
GeoJSON geometry
Opens directly in QGIS, ArcGIS Pro, geopandas, R's sf package, and kepler.gl. No conversion, no coordinate-order guessing.
Annotated CSV
One row per response, headers annotated with the original question wording, and a verified flag so you can filter to identity-confirmed responses.
Read-only API
Pull surveys, responses, and route geometry as JSON on a schedule to feed a dashboard or a modeling pipeline instead of exporting by hand.
Working with GeoJSON route data → · Exporting and analyzing your data → · Using the TIPS API →
Common questions
- How does TIPS capture an origin-destination pair?
- With a Route Creator question. The respondent is given a map and draws the trip they took — start point, end point, and the path between them. TIPS records every coordinate along that geometry, not just the two endpoints, so you get the routing the rider believes they take, which is frequently not the one your model assumes.
- Why not just ask for two addresses?
- Address entry has three problems in practice: people will not type their home address into a survey, the geocoding fails on rural and informal addresses, and the answer tells you nothing about the path. Drawing on a map is faster on a phone, has no geocoding step to fail, and captures the route as well as the endpoints. When you do need addresses, the pre-survey profile step collects zip code, which is usually the resolution a travel-demand model works at anyway.
- What format does the data come out in?
- Two paired exports. The CSV has one row per response with all the non-spatial answers. The GeoJSON has the route geometry for every map question, keyed back to the CSV rows. GeoJSON opens directly in QGIS, ArcGIS Pro, geopandas, R's sf package, and kepler.gl — no conversion step.
- Can I restrict responses to a study area?
- Yes. Map Boundaries constrain the map to a state, county, place, or a polygon you draw yourself, so respondents cannot draw a trip that lands outside your study area. Boundary geometry can be loaded from TIGER reference data or drawn by hand.
- How many origin-destination responses do we need?
- That depends entirely on how you intend to use them — a corridor-level sketch needs far fewer than a calibrated regional model. The practical constraint is usually reach rather than statistics: the honest answer is to field through as many channels as you can (onboard QR, email panel, kiosk, employer lists) and report the geographic coverage you actually achieved alongside the counts, which the density map does for you.
- Does this replace an on-board survey contractor?
- For some studies, yes; for others it changes what the contractor does. TIPS handles instrument design, fielding, deduplication, and export. What it does not do is put staff with clipboards on vehicles. Agencies commonly use TIPS for the self-administered portion — QR codes and email — and reserve field staff for the hard-to-reach segments where intercept is the only way.
See what a drawn route actually exports as
Start a trial, build a Route Creator question, draw a trip yourself in Preview, and export it. Five minutes end to end, and you'll know whether the geometry is what your workflow needs.
Start free 14-day trial Ask a question