This document provides key information about all variables included in the Utah Moves Transportation Survey dataset. This includes:

• A codebook with all variable and value labels, searchable by data table.

• Weighted frequency tables with weighted tabulations for all categorical variables in the dataset. Tables are weighted with weekday (Tuesday-Thursday) weights.

• A dataset guide with information about data privacy, data preparation, and notes on joining tables. In many cases, referring to the original survey questionnaire also provides helpful context for the exact data collection procedures.

In addition to the items listed above, the dataset guide for the follow-up survey can be found here and the interactive data visualization tool can be found here.

The Utah Moves Transportation Survey collected data from February 20, 2023 to June 30, 2023. Data were also collected from Salt Lake Community College students in fall of 2023. Households were recruited into the survey via address-based sampling (ABS), college sampling, and supplemental convenience sampling. The survey included two parts:

1. Part one, also called the “recruit survey,” collected information about household composition, demographics, and typical travel behavior.

2. Part two, also called the “travel diary,” required participants to record their travel during an assigned travel period.

• The household completed the recruit survey in full.

• The household completed a travel diary for all participating household members on at least one concurrent weekday (Tuesday, Wednesday, Thursday).

Note that some household may be complete but not weighted if their complete, concurrent day occurred outside the weekdays listed above. Additionally, only household that are considered complete after flagging iOS trip traces are weighted. All households that are complete (is_survey_complete) prior to flagging iOS trips are included in the dataset.

The household member who completed the recruit survey is referred to as “person 1.” All household members whose relationship to person 1 is spouse or unmarried partner, child, parent, sibling, or other relative reported their travel and are considered participating household members. These persons can be identified by a value of 1 in the “surveyable” column in the person data table. Roommates/friends, household help, and other nonrelatives living in the household did not report travel, have a value of 0 in the “surveyable” column, and are not considered participating household members. As described above, households in which all participating household members completed all travel diary surveys on at least one concurrent weekday are considered “complete.”

The final dataset includes six distinct data tables. These tables include all user-input survey variables, certain survey metadata (e.g., survey completion mode), and variables derived to support data analysis.

The survey dataset contains sensitive and confidential data, including personal data. The table below lists several specific variables that are likely to contain personal data or sensitive information, however this list is not exhaustive. Combinations of additional variables may also constitute personal data.

Please follow your organization’s privacy policy, this survey’s privacy policy, and generally accepted best practices for data privacy and security.

RSG has removed any personal data used solely for survey administration from the final dataset. Additionally, survey access codes used by participants have been replaced with household IDs (hh_id) to ensure that no information in the final dataset can be identified using the passwords the participant used.

Addressed based sample (ABS) households were invited according to a geography-based sampling plan. Invited households were split into 10 groups of counties. Within county groups, households were then split into the following strata according to the 2015-2019 American Community Survey (ACS), which was the latest available data at the time of sampling.

• General: Comprised of block groups that do not qualify for oversampling strata below.

• Hard-to-Survey: Comprised of block groups in the sample frame with at least 25% of households earning less than $25,000 per year (“low income “) or at least 40% of the households identified as Hispanic and/or Black, Indigenous, or Persons of Color (BIPOC).

• Walk/Bike/Transit: Comprised of block groups in the sample frame with at least 25% of persons reporting walk, bicycle, or public transportation as their means of transportation to work or at least 10% of households owning zero vehicles.

These strata are referenced in tables in subsequent tabs in this dataset guide.

This section summarizes the methods used to prepare the data. Given that all data were collected in a “controlled” environment (e.g., survey answers are validated in real-time), data preparation was primarily focused on coding variables and deriving new fields to facilitate analysis.

Before reviewing the data for completion, RSG removed households from the dataset that met the following exclusion criteria:

• Household reported a primary home location outside the survey region. Most households dropped during initial review were excluded for this reason.

• Household reported contact information that matches other households (indicating duplicates). In these cases, RSG kept the first “household” to report their travel diary and removed the subsequent records.

Census PUMA, tract, block group, and block shapefiles were downloaded via the R Tigris package and spatially joined to the reported home coordinates. The final reported block group may not always match the block group ascribed to the household’s sample address (which is used to determine the sample segment) for a few reasons: Sample addresses are geocoded differently than survey addresses, sample addresses sometimes are coded to a mailbox location rather than a home location, and home addresses in the survey are not always geocoded to a person’s exact home (e.g., a cross street nearby). Because a person’s reported home address is considered to be more recent and typically more accurate than the sample address, the geographic variables are derived using this address.

Households retain their initial sample segment assignment, as this is what determines their probability of being invited according to the information in the sample address file.

Survey data tables can be joined to one another as follows:

Timestamps in the location table are set to Coordinated Universal Time (UTC) time. Timestamps in the trip table are set to local time.

Locations are geocoded using a Google Maps API (rMove app) or Bing Maps API (rMove for Web). Survey participants set habitual locations by entering an address / business name or placing a marker on the map, which provides real-time geocoding of each location. All location latitude and longitude information are presented in WGS84 format unless otherwise noted in the dataset.

A survey data table cell may be missing data for one of five reasons:

• Value or response is missing due to survey logic, participant non-response, or error.

  • Example: Participants who traveled by bus were not asked if they were the driver or passenger on the trip.

  • Coded as: 995 for categorical variables, blank/NA for continuous variables

• A respondent indicated that the question was not applicable and skipped that question.

  • Example: Some participants did not share how they pay to park at work because they do not park at work (e.g., carpool).

  • Coded as: 996 (often labeled as “Not applicable”)

• A respondent indicated that their response was not on the list of provided answer options.

  • Example: Some participants did not travel by any of the modes provided in the primary mode list.

  • Coded as: 997 (Other)

• A respondent indicated that they didn’t know the answer and skipped that question.

  • Example: Some participants who made a vehicle trip and paid to park the vehicle may not remember the amount they paid.

  • Coded as: 998 (Don’t know)

• A respondent indicated that they preferred not to answer a question and skipped that question.

  • Example: Some participants chose not to provide their household income.

  • Coded as: 999 (Prefer not to answer)

Other notes about missing survey data:

• For a survey to be complete, all survey questions asked of the participant must have been answered in the app or online instrument. All households in these data have at least one complete household day (i.e., all participating household members have a complete travel diary and complete daily/proxy survey on at least one travel day).
• Continuous variables (e.g., trip distance, trip duration) are not coded with missing value codes and are instead left empty when missing to avoid interfering with statistical calculations.
• Due to the large size of the location table, missing values were left exactly as they were collected. Speed, heading, and accuracy can all potentially contain missing values that are either stored as “-1”, NA, or 0. Analysis on those fields should filter to where the values are greater than zero.

Continuous variables (e.g., trip distance, trip duration, parking cost) in the dataset may contain outliers. Data users should be aware of these outliers when calculating summary statistics (e.g., mean) for these variables.

RSG has also flagged trips with unreasonably high speeds given their reported mode (speed_flag). Trips are flagged with the following rules:

• Walk trips greater than 13 mph
• Bike trips greater than 40 mph
• Vehicle trips greater 100 mph
• Rail trips greater than 160 mph
• Air trips (e.g., airplane, helicopter) greater than 600 mph

This dataset includes a combination of variables that were actively collected via survey questions, passively collected via rMove or other metadata, implicitly assigned (e.g., administrative variables such as ID numbers), and derived or recoded (calculated from some combination of other variables). Key derived or recoded variables in this dataset are summarized below.

Household-level Derived Variables

• Completion status
• Home geographies (block group, PUMA)
• Aggregate income (based on the initial and follow-up income questions)
• Counts of persons who meet certain criteria (e.g., number of students, number of workers)
• Completion status based on A and B criteria

Person-level Derived Variables

• Completion status
• Number of complete days
• Work/school geographies (state, county, block group, PUMA)
• Percentage of person’s trips with flagged trace quality
• Number of days person has no flagged trips

Day-level Variables

• Completion status
• Number of trips per day
• Day completion status
• Percentage of person’s trips with flagged trace quality on day

Trip-level Variables

• Trip speed
• Trip path distance (based on the GPS location data)
• Trip origin and destination geographies (state, county, block group, PUMA)
• Departure time (imputed in some cases)
• Trip purpose (imputed in some cases)
• Mode type and purpose categories
• Access and egress flags
• Indicator variable flagging trips with trace quality issues
• Intermediate metrics (e.g., pt_density) used to flag trip trace quality

Trip Departure Time

In some cases, the rMove app may have detected the start of a trip after its true start time, which can yield invalid or extreme values for trip duration and speed. In these cases, the fields depart_date, depart_hour, and depart_minute were adjusted for “late pickup” conditions using the following approach:

• Departure time was imputed using the median speed between all locations along the trip, excluding the origin point, and the distance between the origin and the next point on the trip. For trips with fewer than three recorded locations, imputed departure time is set three minutes earlier than the original departure time to compensate for rMove’s 3-5-minute ping interval. Note that some trips that are the result of split loop trips may only have three or fewer points but will use the imputed depart time from before the loop trip was split and thus may not be included in this rule.
• If the imputed departure time overlaps with the previous trip’s arrival time, the previous trip’s arrival time was instead used as the departure time. Regardless of the number of locations along a trip, if the imputed departure time was later than the initially reported departure time, the imputed departure time is set to the original departure time. User-added trips as well as long distance passenger mode trips are also set to the original departure time, as user-added trips are not subject to “late pickup” conditions, and long-distance passenger modes are often plane trips where all collected traces contain speed information from other modes and thus are less reliable (as rMove cannot collect locations when a phone is in “airplane mode”).

Duration and speed are calculated based on the imputed departure time.

Trip Purpose

Respondents report the purpose of the trip destination in each trip survey. The origin purpose is derived from the destination purpose of the previous trip, except for the first trip in the travel period or where an rMove trip occurs after a trip with item non-response. For the first trip in the travel period, the origin purpose can be inferred from “begin_day” in the day table.

When purpose was not asked because an analyst split a user-reported trip during data cleaning (creating a new destination along a trip), purpose values are derived where possible based on proximity (within 150 meters) to estimated home, work, or school locations. If the location is not proximate to home, work, or school locations, the purpose is set to “other.”

The purpose category variables (o_purpose_category, d_purpose_category) contain aggregated purpose values based on the type of purpose at the origin/destination of each trip. Dataset users are welcome to perform their own recoding of the purpose categories as well.

Trip purposes have been imputed in cases where a purpose reported by the user is assumed to be inaccurate based on information about that person’s reported habitual locations and other trips (primarily to home, work, and school locations). The trip purpose imputation approach was applied to all rMove trips in person-days with at least 1 complete trip and no more than 10 incomplete trips. (“Incomplete” trips are trips for which the respondent did not answer the trip-specific survey questions about purpose, mode, etc. for the given trip.)

The approach was to apply various “tests” in logical sequence to trips for which the stated purpose is not consistent with the location type based on the reported habitual locations. In general terms, the tests were designed to:

• Check the respondent’s reported destination purpose when it conflicts with the destination location type. (The details of the tests depend on the trip purpose, with different criteria used for change-mode trips, escort trips, linked transit trips, trips with home destinations but other reported purposes, etc.)
• Identify cases where respondents swapped the order of two or more trips when reporting their details.
• Identify cases where respondents may have omitted a trip and shifted remaining reported trip details by one trip when reporting the rest of their trips.
• Fill in missing data by sampling destination purposes from other trips made to the same locations, either by the same respondent or by other respondents.

Joint / School Trip Detection and Imputation

Households with children that participate via the rMove app are asked to proxy-report travel information for children under 18. These types of trips are often underreported in surveys and must be imputed to provide a more complete household travel survey dataset. There are two primary types of known missing trips in raw datasets:

1. Joint Trips: Trips on which a member is present (based on other household members’ records) that are not copied to the member’s travel diary.
2. School Trips: Non-reported school trips on days when a parent reported that a child attended school.

While the purpose of this imputation effort is primarily to impute child school trips, a necessary step is to first impute missing joint trips in general. Thus, the imputation process is broadly cleaved into two stages. First is to detect and associate joint trip records with each other to determine which proxy reported trips are missing if any. Then if the person still does not possess a school trip after the joint trip proxy reporting imputation, and should have one based on school day attendance, then individual outbound and inbound trips are synthesized for that person.

The process to impute each trip type is described below.

Joint Trip Detection and Imputation

To identify and impute missing joint trips, RSG first performs a joint trip detection process to match trip records across household members. Because smartphones traveling at the same time may detect information slightly differently, this process is not exact. User-added trips (which may include inexact times and locations) add to the complexity. To best match trips across members, RSG uses a threshold of trips that depart/arrive less than 15 minutes apart and start/end from locations under 100 meters away. From this group, a list of trip pairs forms a network graph that can be used to identify unique joint trips as being a fully connected subgraph clique (i.e., two or more trips that completely overlap with each other).

Once all trips are associated into sets of unique joint trips, the missing joint trips can be identified as the difference between the number of joint trip records and the total reported household members in a unique joint trip. For example, if a joint trip has only three trip joint records but the joint trips report four household members, then one trip record is missing.

These missing trips can then be imputed by copying the trip attributes from a host trip. The host is determined as the person with the lowest person number in the household. The one caveat is that the trip purpose cannot always be imputed if the purpose of host trip is “escort”, which is common for missing child trips. To mitigate this, purpose is imputed if the destination is a known fixed location, such as home or school. A buffer radius of 100 meters is used to check if the destination is associated with one of those known fixed locations.

School Trip Detection and Imputation

Missing school trips cannot be copied from a host trip and must be entirely synthesized. The origin and destination are assumed to be the home and school locations, and the departure and arrival times are randomly sampled from the distribution of school trip departures and durations in the data itself. Two trips are synthesized for each missing school day, one for outbound and one for inbound trips. The trip mode is assumed to be the typical mode to school as reported in the survey. If the mode is “drive,” there are no escort trips, and they are not driving age, it is assumed that the child is a passenger by someone outside the household (e.g., carpool).

On March 27, 2023 Apple released iOS 16.4, which included changes to background location tracking. This release impacted many apps like rMove that collect location information in the background. In some cases, iPhone users with iOS 16.4 or later collected irregular trip traces in rMove. RSG has since updated the rMove app and monitoring scripts to avoid similar inconsistencies in future data collection.

To identify these trips and flag for potential data exclusion, RSG used two metrics: point density and point distribution.

• Point density (pt_density) refers to how many location points were collected per minute.
• Point distribution (point_dist_index) refers to the number of percentage points greater than expected for the largest distance between two points in the trip, assuming an equal distribution between points. For example, if in a 1000-meter trip with 10 segments between points the largest distance between two points is 150 meters, the point_dist_index would be 5 ((150-(1000/10))/1000)*100).

Trips under two miles are flagged (trace_quality_flag) if pt_density is less than 1.5 points per minute. Trips greater than 2 miles trips are flagged if pt_density is less than 1.5 points per minute or if point_dist index is greater than 40.

In addition to this dataset guide, data users can interact with the data and generate custom analyses here.

With this tool, users can:

• View additional data summaries (e.g., mode share by household income)
• Create custom cross tabs/tables
• Create custom maps
• View origin and destination flows
• Learn more about how the survey data was collected and how to interpret the findings

Mode_type synthesizes mode_1 to mode_4 down to a single, easier-to-use variable for analytical purposes (so that data users can avoid always referencing all modes on a multimodal trips). The table below shows the full crosswalk of which detailed modes correspond to which mode_types. Higher values of mode_type are prioritized over lower mode_type values in the derivation. For example, transit trips, with mode_type 13, are prioritized over walk trips, with mode_type 1. When transit trips were unlinked using the Google API during cleaning, the non-transit legs of the trip were recoded using Google’s suggested mode (most frequently “walk” or “car”).