Transcript
JD: Good afternoon, and welcome to Behind the Numbers: Exploring Transportation Statistics, hosted by the Bureau of Transportation Statistics and the U.S. Department of Transportation. My name is Jennifer Davis, and I will be your facilitator for this session.
JD: Before we get started, we have a few “housekeeping” items to note:
- This webinar is being recorded, both the presentation and the audio, and will be posted online for future reference in 1-2 weeks. Everyone registered for today’s session will receive an email with a link once the information has been posted.
- All participants have been placed in “listener only mode”, otherwise known as mute. As back-up, we ask that everyone go to the top of their screens and click off the green audio icon.
- If you have a question for a presenter, feel free to type it into the “chat” box in the lower portion of your screen, and we will do our best to answer as many questions as we can during the allotted time. If time runs out, any questions we don’t get to will be addressed in the online presentation posting.
JD: Now, on with the show! Today’s topic is BTS Border Crossing and TransBorder Data. We are pleased to have with us:
- Mr. Steve Beningo, with the Bureau of Transportation Statistics at the US Department of Transportation, and
- Ms. Melissa Fanucci, with Whatcom Council of Governments in Washington State
JD: We will begin this afternoon with Steve. Steve is an International Transportation Specialist with the Bureau of Transportation Statistics, where he manages the TransBorder Freight Data Program, which involves data on U.S. trade with Canada and Mexico. In addition, Steve works on border crossing data; serves as the Secretary of the Transportation Research Board’s International Trade and Transportation Committee; and functions as the BTS liaison on the Intelligent Transportation Systems Joint Program Office’s Data Capture and Management Program. Before joining BTS 12 years ago, Steve spent 12 years with the Federal Highway Administration.
JD: And so with that, Steve, take it away!
SB: Slide 1: So my topic will be on Border Crossing Data and Freight Data, and then Melissa Fanucci with the Whatcom Council of Governments will talk about how her organization uses our data.
Slide 2: First of all, the agenda. First a brief introduction about the border, then border crossing entry data, and then freight data.
Slide 3: So the US-Canada border is 5,525 miles in length. There are 11 US states that have land borders with Canada, including bridges over rivers those would be Alaska, Washington, Idaho, Montana, North Dakota, Minnesota, Michigan, New York, Vermont, New Hampshire, and Maine; 2 additional states have borders on Lake Erie, those being Ohio and Pennsylvania. On the other side of the border, Canada has 7 provinces and the Yukon Territory on the border.
Slide 4: The US-Mexico border is 1,954 miles in length. 4 US states border Mexico (California, New Mexico, Arizona, and Texas; Mexico has 6 states on the border the US.
Slide 5: Here is a border map that shows border ports of entry where there were over 1 million people crossing into the US in 2015.
Slide 6: Now we’ll talk about the TransBorder freight data.
Slide 7: The TransBorder freight data, these are data collected as part of a required import/export trade filing. These are thru federal regulations, things like Customs duties. From those, Census extracts and tabulates the TransBorder freight data from the official US foreign trade statistics for BTS. TransBorder freight Data are the exclusive source of trade data by land mode of transportation. By that we mean that Census puts out data on total trade, trade by vessel and trade by air but nothing on rail, highway, or pipeline data. So they have that data and break it out for us. The service modes of transportation only involve US-Canada and US-Mexico.
Slide 8: The data elements with the TransBorder data are: the mode of transportation (air, vessel, pipeline, truck, and rail); value in US dollars; weight (US imports only), in metric and English units of measure; commodity classification (2-digital harmonized tariff system, which classifies international trade between the US and other countries); state and province in the US, Canada, and Mexica; port of entry or exit; and freight charges (raw data only).
Slide 9: As far as data tabulations, data can be tabulated by state and port; by state and commodity, and by port and commodity. You cannot combined all three in TransBorder; however you can combine them in the Freight Analysis Framework (v4) which we’ll get to in a little bit.
Slide 10: This is an example of the main TransBorder database query [review hypothetical scenario].
Slide 11: These are the results of the query.
Slide 12: We also have transshipment data. Transshipments are shipments of merchandise from a country of origin to a country of ultimate destination through an intermediary country. BTS transshipment data are annual data that provide information on US international merchandise transshipped through an intermediary country (Canada or Mexico) prior to reaching the ultimate destination, as well as shipments from their ultimate origin through Canada or Mexico to the US.
Slide 13: This is an example of a transshipment interface and query [review hypothetical scenario].
Slide 14: These are the results of the query.
Slide 15: So as far as other aspects of TransBorder freight data do, we can search by port and commodity; create pie charts and “top 10”-type lists; find the value of weight ratios for imports; data indexed to inflation; you can also download raw data and perform trend analysis
Slide 16: Sample of pie chart
Slide 17: Sample of trend analysis
Slide 18: Among the recent TransBorder freight data activities are the start of migration to Tableau, which will allow us to upload data easier and will make data easier to download for users and offer more visualization options for users. We have also extended our interagency agreement with Census through February 2018.
Slide 19: Now the Freight Analysis Framework (FAF) integrates data from a variety of sources such as the commodity flow survey to create a comprehensive picture of freight movement among states and major metropolitan areas by all modes of transportation (TransBorder data are a major input into the FAF). http://www.ops.fhwa.dot.gov/freight/freight_analysis/faf/
Slide 20: Sample template from FAF
Slide 21: Sample of FAF data results
Slide 23: Now we’ll for to border crossing / entry data. Border crossing / entry data counts data for vehicles, containers, passengers, and pedestrians entering the US through land ports and ferry crossings on the US-Canada and US-Mexico borders.
Slide 24: Monthly and annual data has been available since 1995; data is sorted by port and state; and new data is added approximately six months after the month from which the data as collected.
Slide 25: BTS provides monthly border crossing / entry data for the US-Canada and the US-Mexican border at the port level. Due to workload, Custom and Border Protection prefers to provide data every quarter (broken down by month). This is data count for trucks, trains, containers that are loaded with goods, containers that are empty, personal vehicles, busses, passengers, and pedestrians.
Slide 26: Limitations that we have on border crossing / entry data are: it’s only incoming data (data coming into the US); data does not represent the number of unique vehicles, equipment or individuals; the data is at the port level (not the facility level); and definitions are basic and can vary among sources.
Slide 27: This is a summary of what I said before: we have 6 freight elements (3 truck elements, 3 rail elements).
Slide 28: We have 6 passenger elements.
Slide 29: Sample of the border crossing / entry interface.
Slide 30: Sample of the results.
Slide 31: Border crossing / entry data can be found in annual data compilations (such as TSAR, NTS, Pocket Guide to Transportation Statistics, and STS) and in major reports (such as Passenger Travel Facts and Figures and Freight Facts and Figures) that utilize border crossing / entry data.
Slide 32: Current border crossing / entry data activities include migrating data into Tableau (as we are with other types of data)
Slide 33: So thank you very much for your attention!
JD: Thanks, Steve! We’ve had some questions for you:
-
Is there available any source for weights in the case of US Exports?
- The short answer is no as far as land modes. There are some export weights for air and vessel. What we have done is the value-to-export weight ratio for imports. You can get an estimate of export weight by port or commodity by using the value-to-weight ratio to get the ratio for imports and then use basic algebra to come up with the value of exports.
-
Is shipper information a data element that can be obtained?
- No, there’s no number we get on specific shippers that cross the border (such as UPS).
-
What did you mean by one truck crossing 100 times?
- What we’re counting is trucks crossing the border. In some cases, a vehicle may cross the border on a daily basis. Each of those crossings is counted, instead of just counting one crossing for that one vehicle.
-
Are there any plans to add incoming data in the future?
- We have incoming data, it’s outgoing data that‘s the problem. We don’t have any plans for that; however there’s a Canadian website that has data for entering into Canada. It’s not quite in the same format as we have in the US. Is also some data in Texas for both ways, but there’s no uniformity amongst the three countries. Maybe eventually we will get there, but that’s probably a long way off.
-
Are there cases where a port and facility aren't the same in California?
- The Customs and Border Protection website has some information with listing of ports-of-entry. California is a bit unique in that you have some names that are similar.
-
Regarding the facilities at the border, anyone knows if some places have a 24-hour working day?
- Slightly more than half the facilities run 24 hours a day. In remote areas you have staffing and other challenges that make round-the-clock staffing impractical. So on off hours people have to drive further to cross the border.
-
Is there a data source that you know of for trucks, containers, rail, etc. leaving the US?
- Like was said earlier, the Canadian government has some data, I’m not aware of any such source from the Mexican government.
-
What is the website for the passenger vehicle information? I checked TransBorder and it only had freight data...
- It’s under the border crossing / entry data on the BTS site.
-
To be clear - is there a way to obtain port data disaggregated by facility (e.g., Peace Bridge freight only)?
- No, we don’t have access to it. CBP might have that data but they don’t share it with us.
-
Are there plans to add the Cross Border Xpress Facility in Otay Mesa?
- Silvia: it’s the tunnel to the airport that was discussed earlier. It’s been completed and recently had a grand opening.
-
What is best data source to find trend data for freight?
- Our trend data in the TransBorder data or the freight analytics framework, and if you’re looking for just domestic quotes you can look at commodity flow data.
-
Will Cross Border Xpress be tabulated as an option in crossing data or combine with Otay?
- It’s highly likely would be combined, but it’s my guess. We’re putting in our request for the most recent 2016 data with CBP so we’ll see if there’s a new port-of-entry, but in all likelihood it will be combined with another port but you never know.
JD: Great questions, everyone! Remember that these will be posted online along with the webinar recording in a week or two.
JD: Next we have Melissa Fanucci. Melissa is the Principal Planner at the Whatcom Council of Governments, the Metropolitan Planning Organization in Bellingham, Washington. For over 15 years her work has centered on the International Mobility & Trade Corridor Program, a bi-national, cross-border transportation planning coalition. In this role she specifically focuses on project management, data collection, and collaborative planning efforts with other transportation and border inspection agencies. She also manages the Cascade Gateway and the U.S. - Canada Border Data Warehouse projects, oversees the regional ITS architecture, and serves as an advisor for regional architecture initiatives.
So, Melissa, the floor is yours!
MF: Slide 1: Thank you so much for joining us today. I appreciate the opportunity to showcase what we’ve done in the region using BTS data and hope it provides some insight for other users looking to utilize the tools available.
Slide 2: Before we start, however, I just want to share a little bit about me. Anyone who knows me knows I love two things: Goats and data. Pretty much in that order. In addition to my passion for quality transportation data, I also help run a non-profit goat rescue in Washington State.
Slide 3: And while I have a ton of amazing photos of goats thanks to my work with the rescue, I have very little goat data available to share with the world.
Slide 4: In contrast, I have numerous transportation related databases, but a very small selection of quality photos to accompany these slides.
Slide 5: Therefore, I have decided today, in order to spice things up a bit and get away from the same boring pictures of trucks, that I’d make my presentation on BTS border crossing and TransBorder data from a regional perspective… and add pictures of goats. So there you go. Something charming to stare at while I drone on.
Slide 6: So let’s get started. This presentation is split in two parts, showcasing two possible ways to use the BTS TransBorder Freight Database to make regional assessments of cross-border commercial movements and commodity flows.
Primarily we’ll look at using the online query tool to develop regional commercial data analyses, and what its best at. We’ll also look at what challenges there are in the dataset and what needs to be calculated manually for a true binational portrait of cross-border commercial flow. I’ll show examples of how we have used the query tools available on the BTS website to develop policy decisions based on conclusions drawn from the datasets.
Next I’ll go over how we extract data from the BTS website to populate our own query tool at our regional cross-border data warehouse. This allows for easier regional analyses and one-stop shopping for the end user interested only in a particular subset of data.
There are challenges to our approach, however, so I’ll highlight those and also discuss ways this can be better improved in the future for more streamlined data sharing.
Slide 7: (SWITCH to live view of TransBorder.bts.gov) So, starting off with the online surface freight database:
Steve presented a great overview of the products available through BTS and what they provide for cross-border data analysis, so I won’t spend any more time describing the database itself. Instead I’ll show you how we use the tool by switching to my computer.
First, it’s important to determine what you are looking to understand. In this example, I’m curious to see what commodities cross through our busiest commercial port-of-entry, Pacific Highway, as compared to our smallest commercial port at Lynden-Aldergrove.
I’m interested in goods traveling all throughout the United States, so it doesn’t matter that I can only choose Aggregate all U.S. States. If you are interested in seeing what crosses through a port that’s destined to your state only, however, you’ll want to use the other search function that allows you to choose that – however you will not be able to view goods at the commodity level.
I select as my trading partner Canada. I’ll choose last year since it’s a complete dataset.
I’m interested in two-way trade so I will hold down the control key and individually select both Exports and Imports. This allows those data elements to be shown on separate rows, rather than totaled together.
Then I select the Customs Ports I’m interested in, specifically, Washington State. This populates the port name field. By holding down the control key I can select more than one port. I’ll choose Blaine and Lynden from the list.
Since these are land ports-of-entry, I’m specifically interested in truck commodities as compared to rail, pipeline, or other. And since I want it for both directions, I’m going to choose Value.
This is important to note, because weight values are only provided in one direction, southbound. I’ll talk more about that later.
Once value is chosen, I then select all 12 Months Detail so I can see seasonal commodity trends. Lastly, I make sure that All Commodities Detail is selected.
Typically I hit “submit” first to confirm that the table looks like what I was hoping to get. Once I see that it does, I then download the CSV file so I can begin to play with the data in Excel.
Now, as you can see, I have monthly commodity types for Pacific Highway, and Lynden. Exports are northbound into Canada, and imports are southbound from Canada.
Using these data we’re able to develop a portrayal of a port-of-entry in terms of the markets it serves and its importance in the system.
Now, a quick note on one of the challenges using this cross-border data set. Import data from Canada is only available as a value, not in weight. This is an important distinction because while value provides a snapshot of what crosses the border, understanding volume in terms of weight is a critical piece to comprehending the transportation policy implications of truck movements. The value of goods like cars and manufactured goods may be important in terms of the economy, but even low-value imports and exports have a role to play in that they often contribute to higher value manufacturing, and they can have a significant impact on the transportation network.
Looking at weight gives us a better picture of how many trucks cross and how heavy they are, and so from a commodity analysis standpoint it makes a lot of sense to use this measure.
But since this measure isn’t available through the reports BTS receives from Canada, BTS has provided the means to calculate a value to weight ratio to compensate for the lack of this measurement.
Using this tool will allow you to look at the ratio by specific commodity, thereby providing comparable northbound and southbound values.
Okay let’s switch back to the presentation to see how we used this specific data in a regional border analysis.
Slide 8: This map here shows the four border crossings that make up the Cascade Gateway system of border crossings between the Lower Mainland of British Columbia, in Canada, and Whatcom County, Washington State in the U.S. The Peace Arch is a passenger port only. Pacific Highway is the 4th busiest commercial port on the entire U.S. Canada border. And two other regional ports take portions of the commercial traffic as well – Lynden/Aldergrove to the east, and further east, the Sumas-Abbotsford/Huntingdon crossing.
In 2009 Canada Border Services Agency, aka CBSA, started the development process to replace their aging port-of-entry facility at the Aldergrove crossing. The old facility was not technically a full commercial port, but they did process trucks and predominantly served local trade. However when it came time to replace the facility, there was intention to only replace the passenger vehicle component, and not the commercial facility.
This raised a great deal of concern from local businesses and planners who saw the Aldergrove commercial facility as an important piece to the overall Cascade Gateway system of crossings.
In response, the cross-border working group called IMTC, put together a technical assessment of the port to look at how closing the commercial facility would impact overall trade movements, and the environmental implications of such a closure.
Slide 9: This was a perfect example of how to use BTS TransBorder data to its fullest. We ran an analysis of the top commodities crossing through the port in 2008 and compared that to the totals for the region. These calculations were done using weight to best capture the volume of movements rather than the value. This analysis showed a total of 8.2 percent of all commodities would have to be shifted to the other two commercial ports-of-entry in the system. In some cases, like with Iron and steel, over 25 percent of the regions commodity flow took place through this port.
This has serious implications to Pacific Highway and Sumas Abbotsford-Huntingdon, since both ports already operated under heavy commercial conditions and don’t have the capacity to take on an 8 percent increase of traffic.
Slide 10: To show what environmental implications arise from this shift, we simply looked at volumes, also provided through BTS, and what percent shift would likely go to one port or another, based on estimates of proximity and commodity flows. The analysis showed an added 123,300 vehicle miles traveled for those trucks whose closest port would have been Lynden/Aldergrove.
And when looking at those cumulative additional miles and how they will result in emissions per unit of fuel, we see that this closure amounts to a significant increase in greenhouse gases per month.
The results of this technical assessment were presented to CBSA and shortly thereafter the agency did announce they would construct a full commercial port-of-entry as well as the new passenger facility at Aldergrove. Since its official opening on November 9 of last year, truck traffic has been steadily increasing at the port.
Slide 11: Of course, simpler analyses are completed as well using the BTS data. This is a chart showing value comparisons by direction and year, with commodities grouped together into generalized categories.
BTS data has been invaluable in providing our region with the data and resources we need to visualize what is happening at our border crossings and how to best strategize long-term.
Slide 12: Now, let’s switch gears to a more innovative approach to using BTS data directly on a regional website.
The website in question is Cascade Gateway Data.com, a border data warehouse for the four ports-of-entry between the Lower Mainland of British Columbia and Whatcom County, Washington State.
The project began initially in 2007, but the most recent rendition of the database was designed and implemented in 2010 using funds from Transport Canada, FHWA, WSDOT, and WCOG.
The website stores border wait times in five minute increments, both directions, for trucks and cars, and includes NEXUS lane wait times as well. Users of the website include regional planners, inspection agencies, research institutions, and the traveling public looking to see trends in wait times, especially on busy weekends and holidays.
Slide 13: The new border data warehouse receives data from four sources: WSDOT’s advanced traveler information system, or ATIS, that reports northbound border wait times through their website, on variable message signs, and from an app; and BCMOT’s southbound ATIS system that provides a comparable service.
In addition to these two datasets that provide five minute increment data, we also archive commercial vehicle data from two additional sources.
WSDOT has a weigh-in-motion detector on Interstate 5 that we can manually download the data from and use to capture vehicle types.
And of course, the BTS TransBorder freight data that is made available on their website now also provides data to our warehouse.
From the warehouse, end users can use the data through the website, or using the Application programming interface, or API, to use the data on their own apps or websites.
On this illustration, you can see two grayed out data sources that we are working to incorporate into the database. This is a solution to address the new dynamic nature of border crossings, where LED signage allows inspection agencies to change the mode of a booth in response to real-time demand.
Once those components are included, there will be six separate data sets.
Slide 14: We use the code listed on the screen here to perform what’s called a “screen scrape.” Basically we initiate a request, just like a web request, from the BTS site, using the parameters established when the person makes selections with our query tool.
The return data is processed, and then used to populate the tables on the Cascade Gateway Data website.
Slide 15: (SWITCH to live view of www.cascadegatewaydata.com) So now let’s go to the live website so I can show you how in works in real time.
CROSSINGS Tab - Data is available by port by mode. If I choose Pacific Highway, for example, I can see volumes by day, and average delay. If I’m interested only in commercial vehicles, I can select Pacific Highway Southbound Trucks, for example, and see their averages per day.
Looking at a specific day, the data are available in five minute increments. A chart view provides average delays. And all this data is available for download as a CSV file.
DETECTOR Tab - In addition to volume and delay data, this online resource provides a great deal of other information. On the detector tab, users can pull up volumes and speed at the individual detector level. This allows a user to query volumes in each specific lane.
WIM Tab - As shown in the architecture diagram, the archive downloads data from a weigh-in-motion detector on Interstate 5. This provides users with vehicle type and volume data to compare against the crossing totals.
REPORTS Tab - The next three tabs focus on tools made available for users. Pre-made reports are available to provide answers to commonly-asked questions, such as average wait times over holiday weekends.
The custom query tool allows users to create their own report with all of the data parameters available.
And the subscriptions tab allows users to sign up for notifications when wait times exceed a pre-defined threshold.
BTS Tab - But the tab that I want to focus on today is the last one, showcasing the BTS freight data. The data here is directly pulled from the BTS website using a “screen scrape” of the BTS data query tool. The reason we’ve reproduced the data here is to make it easier for regional users to get all the data they need at one location.
Many of the choices on the BTS website can be overwhelming, so this simplified query tool limits the queries available. Users can choose year, measure value, one or more of the three ports in this region, mode, and commodity.
The data is still available in CSV format.
We’ve had feedback from users that they really appreciate being able to come to one website and get truck delay, volume, and commodity data all at one location.
CHALLENGES Tab - What are some of the challenges of this method?
Because we don’t officially receive our data from BTS through an API, or a data transfer, but through the website query tool itself, our query is affected every time BTS changes its website. When it alters its query functionality, we don’t know it until we try and run our query and it fails. We don’t have a formal data sharing agreement with BTS which makes it a challenge to keep up to date with alterations.
NATIONAL BORDER DATA WAREHOUSE Tab - Okay, before we leave the topic of BTS on regional warehouses, I’d like to just alert folks to the existence of another border delay archive available on a national level, at www.borderdatawarehouse.com. This site pulls data from the Cascade Gateway archive, and from the Bluetooth traveler information systems in the Buffalo/Niagara region. As other regions establish dynamic border wait time systems, they will hopefully also be added to this national level archive.
Because each area uses different technology to estimate wait times, we’ve kept this national archive’s data sets limited to the common denominators – specifically, wait time only. We don’t share volume, occupancy, vehicle length, or any other data elements that are available elsewhere.
However since BTS data is available at all these crossings, it may make sense at a future date, should funding be available, to incorporate the TransBorder freight data here as well. Again, it brings up the potentials of using an API interface to the TransBorder database, and also what products may emerge as BTS migrates its data to the Tableau visualization platform.
Okay let’s switch back to my presentation to wrap up and take questions.
Slide 16: When it comes to improvements that would make our database, and other services like it better, it would be a huge improvement to have direct access to the BTS data, similar to what we provide other users.
APIs allow other websites, app developers, etc. to access the core database behind the scenes and run queries of their own on that dataset. This screen shows examples of code that developers can use to plug our data from the website into websites, mobile applications, live data visualizations, and other resources. It’s the most flexible and reliable way to share data with other agencies.
This would be the ideal improvement for our BTS data sharing tool, since we wouldn’t have to rely on scraping data from the website. It would lead to better functionality.
As another, smaller step to improve functionality, simple notification of upcoming modifications or changes to the web interface would benefit us, since we typically don’t find out until the system breaks on our end.
However given this was a pilot as it was developed in 2011, and it’s been going strong, minus a few outages, for the last five years, we feel it’s been a really beneficial addition to the archive, and provided key BTS data to stakeholders in a meaningful manner.
Slide 17: To sum up the benefits and challenges of pulling data directly from the BTS website to populate an external database:
The project has shown benefits in providing people with data in a limited, regional focus, and using a simplified regional tool;
There has also been praise in providing one-stop shopping for data consumers in terms of getting Cascade Gateway freight data all in one place.
The biggest challenge has been the instability of the tool every time a change is made at the BTS end regarding their website. Without advance notice, we don’t find out about the breakage until it’s too late.
Another challenge I’ll briefly mention is that we don’t store the data on our own servers, since initially this was considered redundant. However that lack of stored data means that when the BTS website is down, ours is down as well. We don’t have a backup to refer to when BTS servers are inaccessible.
These challenges could be addressed with a few basic changes. Primarily, if the dataset from BTS was available through an API, the website wouldn’t be relying on the format of the query form, rather the base data underneath. It would be far more stable and less likely to break.
Slide 18: To summarize, there are basically two ways we use BTS TransBorder freight data for regional cross-border commercial movement analysis. There is direct access and the primary means of data analysis, through the BTS website. I’ve listed the URL below.
And of course, the way that BTS can integrate with other data sets through specific regional or national archives is another way to share this great data with a broader range of users, and to cater available data to the needs of the region.
JD: Thank you, Melissa! We’ve received some questions for you …
JD: These were great questions, everyone!
That concludes our session on TransBorder Data. We would like to thank Steve Beningo and Melissa Fanucci for presenting here today. We would also like to thank all of you for joining our session.
JD: Remember that today’s presentations will be posted online along with the webinar recording in 1-2 weeks, so watch your emails!
JD: Our next BTS Webinar is scheduled for Tuesday, July 26, and the topic will be National Census of Ferry Operators. You can find out more information about all of the BTS Webinars by visiting www.rita.gov/bts/webinars.
JD: Thanks again, everyone. We hope you can join us for July 26th!
-
Since there's only data entering the US how is export/import defined? Are those US exports and imports and would that mean that imports are typically empty trucks or containers?
- Because BTS gets their data from CBP, they’re getting the data that is coming into the US so technically that is imports, but we get a lot of trucks that are empty so they don’t necessarily need to file paperwork. But the majority of what comes in is exports, what is leaving the US and going into Canada.
-
Are you planning to add passenger vehicle information to your site?
- On the border data warehouse we do have passenger vehicle information there. We have some individual information about passenger vehicles from intercept surveys that we do about every five years, but in terms of what we do for the basic volume and delay we do have that for both the Cascade gateway and at border data warehouse national level.