Visitor Population

Background

The general population is focused on allocating household and person records to housing units. The group quarters process is focused on allocating group quarters persons to group quarters units. There was also a need to locate traveling public at hotel, park (camping), or other lodging locations that neither the general population or the group quarters population would be appropriate for. Adding a representation of visitor was deemed necessary for several reasons:

• Work had been done for the ABM and previous trip-based models in locating and inventorying hotels / rooms. By only considering the general population and group quarters, no trips would originate from those hotel and similar lodging locations, and ABM would not be able to test questions around changes in lodging or properly estimate the number of trips for zones with a large number of lodging units.
• Similarly, the Southern Oregon area has a fair amount of tourist travel, an example is the City of Ashland which has a nearly year round Shakespeare theater presence, and whose downtown is a tourist hotspot. The general population and group quarters alone would not properly account for the number of travelers in the Ashland area.

Therefore, a separate process was established to locate visitors that do not reside in the model area to zones within the model area.

Originally, the approach planned to use the PopulationSim tool, similar to how the general population and group quarters populations are generated. However, after testing and development with the tool, the approach of using the PopulationSim tool failed for a handful of reasons:

1. There were only several thousand visiting parties (households) specified. As opposed to using the local PUMAs as the population seed, the visitor methodology assumes that the households from the remainder of the state of Oregon (as a proxy for the remainder of the world) are used as the seed for the visiting population. This created an integerization issue for the PopulationSim tool. There are tens of thousands of PUMS records for the state of Oregon, but only several thousand records needed in the final synthetic population solution. This created a situation where many of the adjusted PUMS record weights dropped below 1.0, giving the integerization process a condition that was not anticipated, and that the tool did not handle well.
2. Very little demographic information could be found on Oregon visitors. The information basically boiled down to the number of traveling visitors by lodging type, and average party size by lodging type. These two pieces of information help provide an estimate of the number of traveling parties (households) and the number of total travelers (persons) by lodging (location) type.
3. Any households allocated by PopulationSim, needed to be heavily altered after the tool was run. This was necessary because it is assumed that travelers don't go to school, so all attributes related to being a student needed to be cleared. Additionally, only travelers on business are assumed to have an occupation. So all travelers (persons) not traveling on business needed to have their attributes related to working status and employment be cleared. This leaves only a select few attributes from the original PUMS records intact (true), so the value of using a tool like PopulationSim to allocate PUMS records to zones becomes greatly reduced and questionable.

Because of these reasons a custom series of steps was developed to allocate visitors to zones. These steps are described further in the following section.

Methodology

As described above, the PopulationSim tool was not well suited to allocate household and person records to zones for the visiting population. Therefore, a custom series of steps coded in R was developed to generate the visiting population. While this is intended to be a generic methodology that could be applied to any region, the following walk-through uses examples from the process and data used for the Southern Oregon area to help describe the overall process and methodology.

The methodology has two key steps. Step 1 is determining the number of visiting parties by zone and by lodging type based on available data, and step 2 is allocating and then altering PUMS records to MAZs to align with zonal party totals and average traveling party size (number of persons) by lodging type.

Total Visiting Parties by Zone by Lodging Type

The following information was obtained about visitors to Oregon. The information that was gathered was:

• a report on "Oregon Travel Impacts" by Dean Runyan Associates, provided to ODOT by Travel Oregon, and
• hotel room and Recreational Vehicle (RV) unit counts by MAZ provided by local RVMPO staff and guidance.

Additionally, national level lodging trends were obtained from the American Hotels and Lodging Association (AHLA).

Using that information a number of controls can be calculated after a handful of assumptions are applied. The process uses the following steps:

• Based on review of national reports and discussions, a vacancy rate of 70% is assumed for all hotel and RV units, meaning that no hotel or RV park is assumed to be at full capacity on an average weekday (the time period of the model). Therefore the MAZ level hotel and RV unit totals are multiplied by 0.7 and rounded to a whole value initially. These serve as the total number of visiting parties by hotel and RV unit by MAZ.
• The Dean Runyan report provides overnight estimates of the travelers percentage split (persons, not "households" or traveling parties) by "Hotel, Motel, STVR", "Private Home", and "Other Overnight". "Hotel, Motel, STVR" is reported as 30.6% of the total travelers for Southern Oregon. This category is assumed to be equal to the travelers in hotel and RV units identified at the MAZ level. Average party size by each of these categories is also provided. Therefore, populated hotel and RV units (70% of inventory) are multiplied by the average party size (2.4) to get the total number of travelers in Hotels and RVs for the Southern Oregon area. This total is divided by .306 (30.6%) to get the total number of travelers for the region.
• The remaining travelers ("Private Home" and "Other Overnight") are assumed to be located (staying overnight) at home locations. So that number of total traveling parties (which is determined by taking total travelers times the percentage in each grouping), divided by the average party size (2.5 and 3.4 respectively) and then allocated to household locations evenly across all households in the region.

These steps provide the total zonal level controls by Hotel, RV, Household - Private home, and Household - Other. In the next step PUMS records are allocated to each zone separately for each of these four types.

Allocating and Altering PUMS Records by MAZ by Lodging Type

At a high level the process of allocating household records is very simple. The simple description is that the weighted PUMS data for the state (minus the local, Southern Oregon, PUMAs) are randomly drawn using a random number generator and the PUMS sample weights. The households are drawn in a way to fill zones has determined in the previous step and to maintain the average traveling party (household) size by traveler type. Along the way certain PUMS fields are altered based on varying assumptions by lodging type. The final result is a subset of the statewide PUMS dataset with specific zones assigned to those records and altered fields. This process is describe in greater in the following bullets:

• The first step processes the raw statewide PUMS data in the same way the PUMS data is processed for the general population. A single year (2010) income field needs to be generated; housing type and employment fields are re-formulated and standardized for the ABM; blank records are altered to standard value codes; along with a handful of other cleaning steps (such as removing the local area PUMAs from the full state sample). After the initial processing is done the PUMS records move into the draw phase.
• The "draw" phase is a little different for each lodging type. The first type described is for business travelers in hotel rooms and is the most complicated (with the most alterations to the original PUMS data). From the traveler data obtained it was learned that approximately 40% of hotel visitors are staying for business on the average weekday and that the average party size for business travel is 1.5 persons. This information led to the following steps to establish the PUMS record "pool" to draw from:
  • The households needed to have at least one worker
  • The household records were then split into 2 pools, one pool of 1-person households and one of greater than 1-person households.
  • The households in each pool were then given a probability range based on their weight, where households with a larger weight got a larger proportion of the range from 0-1. Separate proportion ranges were developed for the 1-person household pool and the greater than 1-person pool, where each pool's household proportion range was from 0-1, where each household in each pool got a small "slice" of that range from 0-1 (the size of the slice being directly proportional to the households PUMS weight).
• The process then loops through each zone and each traveling party. The process tracks average party size. In this case the average party size was 1.5. If the average party size for the households pulled so far was above 1.5, the process would only pull records from the "pool" of household that was only 1-person (lowering the average party size). If the average party size for the records pulled was lower than 1.5, the process would pull households with more than 1 person. Either way, after a household record was pulled the persons in the household would be checked to make sure that at least one member of the household was older than 18 and worked greater than 35 hours per week (a full time employee non-student). If no one in the household met that criteria, that household was discarded and another household was drawn. It's important to note that given the simplicity of this approach and the little demographic information known about the travelers, it was decided not to code additional complexity in only drawing a household once. So there's nothing in the process that stops the same PUMS record from being drawn multiple times. However the likelihood of this condition should be low, as there is approximately 10 times the number of PUMS records available than the number of visitor records needed.
• After the household (party) is selected, additional processing is applied. For the case of these business travelers, if it was a 1-person household drawn, the step above already determined that the only person in that household (party) was a full time worker. Therefore, all the fields of the PUMS record are used as is and the process simply adds that record to the visitors household and person tables with the appropriate assigned MAZ and TAZ. If there was more than 1-person in the household (party) the processing of the PUMS data is more complicated:
  • A simplification is made and it's assumed that only up-to two people will travel together for business on an average weekday. So for business travel, the party size can be only 1 or 2. For 2+ households, the number of people indicator for the household is dropped to 2. Additionally, it's assumed that only one of these people is traveling for work and the other is traveling for pleasure, so the number of workers in the household is set at 1.
  • The vehicle count for the household is limited to 1. It's assumed that if the household has no vehicles that they might similarly find ways to travel around with no vehicles while traveling. So they are left as a zero car household (which the ABM might alter based on accessibility). If the household has some number of cars the household is limited to 1 while traveling (which again, the ABM might alter).
  • Next the worker in the party is chosen. All of the full time (greater than 35 hours per week) working adults (older than 18) are identify and then a random number is drawn to identify who the traveling worker is. Of the remaining people another random number is drawn to determine who the traveling guest will be. The persons for that household record are order by worker than guest, and the guest is cleared of all worker and student attribution.
• The altered household and person records are then appended to the running tabulation of visitors and the average party size is updated, which dictates if the next part will be a 1-person household or greater.

After this is completed for all the business travelers for all the zones the process then moves to do similar steps for; leisure travelers in hotel rooms, leisure travelers in RV parks, and leisure travelers staying as guests in existing homes. All of these totals by zones come from the previous step of determining total visiting parties by zone by lodging type. The following are some of the slight differences between these traveling types and the extra steps that were performed for business traveling households:

• Depending on the average party size the split between the two "pools" varies. The average households for leisure travelers in hotel rooms, RV park travelers, and housing guests are assumed to be 4, 2.4, and 2.5 respectively. Because of this the split is assumed between 1-2 and 3+ person households, where 1-2 person households are in pool one and 3+ person households are in pool 2. The pool to draw from is then selected based on whether the average party size is above or lower than the average party size specified by lodging type.
• Checks on worker and students attributes are not made for the other traveling types. However, it is assumed that no one in these other non-business traveling parties works or goes to school. For that reason, after the household records are pulled all persons are cleared of their working and student attributes, and the household number of workers field is set to zero.
• Similar to the assumption with business travelers, the number of vehicles in the household is reduced to either zero or one; zero for households with zero vehicles, and one for households with more than 1 vehicle. As with business travel, it's assumed that households with no vehicles at home might tend to travel with no rented vehicles, and households with more than one vehicle at home are assumed to be reduced to one rented vehicle while traveling (again the ABM might update the vehicle choice / number assumption).

Other than those differences the process is very similar, households are drawn from one of the two pools depending on the accumulated average party size, the attributes are updated as noted above, zones are assigned as households are drawn, and these households are added to the running visitor household and person tables until all traveling units by lodging type have been drawn.

After all households are drawn, a complete set of visitor household and person records are saved out, which are then added to the general population and group quarters tables as described under the population synthesis discussion. The full combined household and person records of general population, group quarters and visitors (all formatted consistently) are then used as the input to the ABM.