FTOT network system

[jiezhao1219]

Hi @olivia-gillham-volpe @matthewpearlson @aobergdc,

FTOT provides multi-modal network. However, based on Tuesday's meeting, we plan to add the detailed roads network (obtained from https://www.arcgis.com/home/item.html?id=f38b87cc295541fb88513d1ed7cec9fd) into FTOT network system for our next case study, about the forest residuals-to-jet fuel supply chain. Could you provide some recommendation about how to incorporate the detailed road network into the FTOT network system, and then apply for optimization?

Thanks,
Jie Zhao

[aobergdc]

Hi @jiezhao1219

At the moment, FTOT is not setup to easily be able to plug and play separate sources of network data. There are several challenges/limitations that I describe below. That said, the ability to include user-defined networks is something we want to continue to explore and something we can hopefully facilitate for your team.

Here are the main challenges-

1. The network you linked to is relatively large—with over 4,000,000 road segments. This is over 100 times more segments than the road network provided with FTOT and is likely to cause major performance issues in both preparing the network for use in FTOT and ultimately—in running actual FTOT scenarios. Assuming your scenarios are more localized, I would recommend you adapt the Esri network to only include the region of roadways you are interested in flowing things on (e.g. you could clip it to Washington State). I would also recommend excluding categories of roadways you don’t need in the network—for example, the Esri network seems to be very detailed and includes pedestrian walkways, service drives and alleys. One reason the FTOT road network is based on the Freight Analysis Framework road network is due to the network’s focus on including the important freight corridors.

2. Any network included in FTOT must be a fully connected, flowable network (some GIS feature classes are not setup this way, but my understanding is that networks Esri produces are indeed fully connected and flowable, so this is probably not an issue in this case).

3. There are certain road network attributes which are leveraged while running FTOT to help determine optimal routes and/or calculate statistics that are provided in the reporting outputs. When you use the default FTOT road network, all of these attributes are automatically included (the road network Is based on the FHWA Freight Analysis Framework network, and these attributes either originate or are derived from the data included in that network). These include the following attributes:

• Functional Class (defined using the FHWA 7-category system-- see the FHWA Codes column: https://www.clrp.cornell.edu/q-a/191-functional.html for a full description of those categories) Unfortunately, Esri’s road does not appear to use the FHWA 7-category system—they use something else entirely which would require customization of the FTOT code in various places to properly process. The alternative, which I think would be much easier, would be to create a new field which converts the Esri functional class field (ROAD_CL) to the FHWA 7-class equivalent. You’d want to dig into the Esri metadata to understand exactly how they class roadways and ideally there is some sort of 1:1 relationship with the FHWA equivalents.
• Urban Code: We use the FHWA definition of urban code where 99999 indicates rural areas and any other value less than 99999 indicates an urbanized area. I do not see this in Esri’s network. Since it might be challenging to replicate the exact methodology FHWA uses to define the urban codes, at a minimum FTOT needs some sort of binary representation of whether the segment is urban or rural. For example, a simple designation of 1 (urban) or 0 (rural) for each road segment is adequate here. You would be able use the urban area GIS data from the Census to help with that kind of designation. https://www.census.gov/cgi-bin/geo/shapefiles/index.php
• Speed Limit- This does seem to be included in Esri’s network—it’s the SPEED field.
• Volume (Average daily volume of vehicles on the segment (one-directional) I do not see this in Esri’s network.
• Capacity (Average daily capacity of vehicles on the segment (one-directional) I do not see this in Esri’s network.
• Volume Capacity Ratio (volume divided by capacity) I do not see this in Esri’s network.
  Any replacement network will need to include these attributes for full FTOT functionality. At a minimum, functional class and urban code are required, while the others, like volume and capacity, are necessary if you are running scenarios where background flows and/or capacity needs to be considered.

4. Once the above three challenges are considered, there is still some pre-processing of the network that is required to do things like ensure proper connectivity to intermodal facilities, and simplifying the network to the extent possible. We have an internal tool that is not currently part of the public release that automates this process. Once you are able to finalize a road network that addresses challenges 1, 2 and 3 above, I’m happy to run the road network through that process to cut a final network that is fully compatible with FTOT.

Does this all make sense? Happy to schedule a time to discuss more of the details over the phone if it would be helpful. Feel free to bring Dane into the conversation if it makes sense to involve him on the GIS side.

[jiezhao1219]

Hi @aobergdc

Thanks for your explanation, it is greatly helpful for me. Based on your recommendation, I have tried to narrow the detailed network system only in the Pacific Northwest (PNW) region (i.e. the supply chain affected area) and exclude some unneeded road. However, the network is still too large. Since we consider a multiple schedule input (e.g. 20 years) in the supply chain resilience assessment, which needs a lot of simulation time, adding the detailed network into FTOT would cause large computational burden and performance issues. In this case, we decide not to add the detailed network into FTOT, without considering the city street.

Thanks for your help! Please let me know if you have any questions or suggestions.

Best,
Jie Zhao (WSU)

[matthewpearlson]

Hi Jie. Thanks for the update. I agree. With a 20 year time horizon, the network will need to be as simple as you can make it.

Can you explain the purpose of the local road network? Is it to get a better sense of the first-mile and last-mile movements? Let us know why you want the detailed network and we can brainstorm some ideas on this side.

[jiezhao1219]

Hi @matthewpearlson

Since we consider the forest residuals only in PNW region, not in national scale, the road system in FTOT network will loss some details, especially for some cases when the residuals can not be directly connected to road system. In this case, to be more realistic, the forest residuals-to-jet fuel supply chain considers the detailed network (e.g., city street) as one component of the network system.

Besides, after we obtain the optimal supply chain layout, we plan to run the supply chain optimization only for network in response to multiple risk factors without incorporating the facility optimization. Could you give me some suggestions about how to modify the Python files to eliminate the facility optimizer in the optimization process (i.e. keep all the input facilities being utilized in the supply chain)?

Thanks,
Jie Zhao (WSU)

[matthewpearlson]

Hi Jie. Thanks for your question about the the FTOT network system and how to modify the scenario for your analysis.

I think it makes sense to modify the FTOT network you are using to remove the links outside the area of interest. This will help with the performance issues you mentioned in #15.

As for how to eliminate the facility optimizer in the O-steps, my suggestion here would be to run the scenario all the way through and get an optimal result. Then, use the optimal result as your network. We can do this using ArcGIS to do a selection based on either the fields (e.g. mode and mode ID), or the location.

Let me know if you'd like to schedule some time to discuss.

(FYI @olivia-gillham-volpe @aobergdc )