I've created a multi-modal network data set with four main modes being Metro, BRT, Walking and Cycling.
I want to have travel time as and impedance with multiple modes. However, to get onto the metro takes more time than getting of the metro. That is why i made two transfer lines between the metro and the walk infrastructure. They are in digitized in opposite direction and both have a oneway restriction.
However, when solving a route from the metro infrastructure to somewhere else, it is impossible to get of the metro system. The analyst simply says there are no routes possible.
I have the feeling that i defined my oneway restrictions in the right way. However, when i removed the restriction from the network dataset attributes, it was possible to get of the metro infrastructure.
I added a picture in which the situation is explained. The metro transfer line has an arrow at the end to see in which direction it is digitized.
I hope one of you can help me out.
O.K. clear.
I however do not think that your suggested solution will work, because in the end, I want to use this dataset to make an OD-matrix with multiple origins and destinations. Also, the 'commuters' will have to be able to use up to four different modes when moving from O to D.
Plus, i want to model a way in which it is not possible to use a bike after the BRT or metro modes have been used. However, it should be possible to use the bike before this is done.
I realize I have a very complex set of questions, but a powerful tool as the network analyst should be able to give the answers to this.
Again, i really appreciate your help and I hope we can find a sollution to my problem together.
Having multiple origins and destinations shouldn't pose a problem, unless you mean that you need some of them to locate on bike edges and some on walking edges. That could prove challenging. You might have to resort to a definition query: Snapping network locations with Build Query—Help | ArcGIS Desktop
Unfortunately, despite the awesome and wonderful power of the Network Analyst tools, we really don't have a good way to solve a true multimodal problem like what you're trying to do. If I understand you correctly, you want to model a trip like this: Traveler rides his bike to a BRT station and leaves it parked there, rides the BRT, gets off somewhere, and walks the rest of the way. There is an algorithmic reason for the difficulty. Basically the solver (Route or OD Cost Matrix or whatever) would need to know something about the state of the traveler (bike or no bike) and would need to keep track of this bike/no-bike state throughout the graph search that's going on under the hood when you solve an analysis. Our solvers aren't set up to do this, and if they were, we would have to use different algorithms and heuristic methods because a fast and exact solution can't be guaranteed to be found.
So...hmm...maybe having a separate bike layer and walking layer IS the best solution. Then you could have those oneway restrictions that sort of prevent people from biking off the metro and BRT.
Or maybe you need to break the analysis up into two parts. Solve some biking routes from the origins to the stations, and then solve the routes from the stations to all the destinations. It's not perfect, because the optimal solution might be to bike or walk directly from origin to destination without using the transit lines at all.
Hello Rogier - Melinda keyed me into this discussion as it sounds similar to a problem I have been working to solve in Chicago. We were interested in creating a multimodal network so that we could estimate transit trips that included a driving trip to a park-n-ride transit stop, continuing on transit, and then ending with a walk trip. Your problem sounds significantly more complicated, but would it be correct to say that they are related?
I thought through this a bit and it's a challenging proposition. First, if you introduce driving (or biking, in your case) into the network they are both (almost always) going to be faster than walking and in many cases faster than transit as well. We were interesting in solving an O-D Matrix only for trips that included a transit portion so I can give you some guidance as to how we did this. However, if you are simply interested in calculating the fastest trips regardless of mode (that is, not requiring a mode like transit) then I think you've got the right approach but may wish to simplify your connectivity groups.
For us, I ended up splitting up the analysis into 3 parts. 1) calculate an OD Matrix of drive times to all parking-available transit stations. 2) calculate an OD-Matrix of all transit+walk times from parking-available transit stations to final destinations. 3) calculate an OD Matrix of walk+transit travel times from all O's and D's. Then, join 1) and 2) at the park-n-ride and sum the travel times for an "O to p-n-r to D" trip. Compare this against the "O to D" results from 3) and retain the shortest as the preferred route. This is described in more detail in our TRB paper, which you can view here if you have access: Transit Access Measure: Incorporating Walk and Drive Access | TRB Annual Meeting
If you are just interested in the fastest trip regardless of mode and not requiring use of any mode (and excluding driving, which it looks like you are) then is there a way to simplify your connectivity?
i.e.:
Connectivity Groups | |||||||
Name | Type | Policy | 1 | 2 | 3 | 4 | 5 |
WalkConnectors (from PedestrianStreets to TransitLines) | Edge | End Point | x | ||||
BikeConnectors (from WalkConnectors to BicycleStreets) | Edge | End Point | x | ||||
PedestrianStreets | Edge | End Point | x | ||||
BicycleStreets | Edge | End Point | x | ||||
TransitLines | Edge | End Point | x | ||||
TransitStops | Junction | Honor | x | x | |||
TransitStops_SnappedToPedestrianStreets | Junction | Override | x | x | |||
Bicycle-Ped_Interchange (midpoint of WalkConnectors) | Junction | Override | x | x | |||
Bicycle-Ped_Interchange_SnappedToBicycleStreets | Junction | Override | x | x |
In this way you could let WalkConnectors have a From-To travel time calculated as you wish, and have To-From set to zero. BikeConnectors could be given a To-From as "-1" (so that trips coming from TransitStops, which by definition pass thru WalkConnectors, are not allowed) and a From-To as some value to estimate bike parking search/lock-up time. In this scenario, your Origins would need to begin by being located on BicycleStreets, which sounds appropriate given your assumption that people are allowed to use their own bicycle (they presumably would begin their trip on their bicycle and not walk to get it or walk it before starting to ride). I see you have BRT in there as well, so this certainly can get more complicated so maybe I am over-simplifying, but if nothing else hopefully you've got some fresh ideas to work with.
Good luck!
I thought about this again and it's back to the original challenge that biking will always be faster than walking, especially if the networks are pretty similar (which they kind of have to be if you are allowing people to bike from home, which more likely than not isn't located on a designated bike path or bike lane). So, what I am struggling with is why there would ever be a need to go from the bike network to the walk network - you don't see people walking their bikes around very often because if you've got a bike and you're in a place people can walk, you might as well be biking (if maybe a little slower). In which case, you could just connect the bike network directly to the transit lines at whatever cost you prefer and then disallowed it in the To-From direction. And then your walk network could also be directly connected to the transit lines, with freedom to flow in either direction at whatever cost you wish, to ensure transfers are still allowed.
But this still becomes a checkbox analysis - either you have a bike to begin with or you don't. And you'll get very different results depending on which box is checked. I think a more pure "multimodal" trip might be one that doesn't assume someone has a bike to begin with, but has access to a bike-share network with docking locations pre-defined. This is a different problem than you are trying to solve but would be a reason to locate origins on the PedestrianStreets instead of the BicycleStreets. I'm not sure there is a reason you'd need to do that in your analysis, but very possible I am missing something!
I think he's trying to model a sort of park-and-ride scenario where you bike to the station, leave your bike parked there, and then take transit somewhere else. Since you no longer have your bike, you now have to walk the remainder of the way.
And presumably you would be allowed to ride your bike to any station? In that case I think the connectivity groups can be simplified significantly as I described (though I fully understand I may have oversimplified if there are some additional elements he is wishing to model). Note that this also wouldn't require someone take transit, it would essentially provide the following trip options:
Bike only
Bike to Transit and walk to destination
Bike to Transit and walk to transfer to other transit and walk to destination (endless transferring allowed)
It wouldn't include any trips that had the following interchanges:
Walk to Bike (though it's assumed someone has a bike available at the origin? So not sure why this would be needed)
Bike to Walk (though not sure why this would ever be needed).
Walk to Transit (though if it's assumed someone has a bike available, biking would be faster anyway)
Transit to Bike (as desired to exclude)
Walk only (again, if it's assume a bike is available, then Bike only is faster anyway)
This assumes that the walk and bike network are fairly similar. If they are very different this may not apply, but if they are very different then there's an added complication of how people access the bike network from the walk network (are they walking their bike?)
Melinda does indeed summarize my problem the best way.
You assume that biking is always faster than walking, but the problem with this analysis is that not every metro or BRT station has a bike-parking facility. This means that for some origins it is faster to walk to the nearest BRT/Metro station, instead of biking, because this station does not have a bike parking facility.
I think i am going to go with the solution that you both more or less proposed, by splitting up the analysis in parts and then adding the costs OD matrices to each other.
I would like to thank you both a lot for your help. You really showed me new insights on network modeling.
I see - yes if you want to constrain the places in which people are allowed to bike to then the way we modeled the Park-n-Ride problem can probably be ported over for your situation very nicely. Same idea we took for the park-n-rides, it's fully reasonable that someone drive and park their car near any station just as it would be for bikes, but using designated park-n-rides like how you are using bike-parking facilities is a nice way to constrain the analysis just enough to mimic the choices people make fairly well.
Good luck! If you can't view our TRB paper but want to, feel free to give me a place to send it to, and I'd be happy to.