Unclear what is wrong with Oneway restriction

Discussion created by RogeRThaT on May 11, 2017
Latest reply on May 12, 2017 by deleted-user-qBkp2qFgqzj-

Like • Show 0 Likes0
Comment • 17

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.

Attachments

Naamloos.png273.0 KB

Outcomes

17 Replies

MMorang-esristaff May 11, 2017 8:48 AM
Hello Rogier. I am not sure what's wrong with your Oneway restriction in this case, but a Oneway restriction doesn't seem like the best way to model a difference in travel time between entering and exiting the metro.

When you set up your cost attribute's Evaluators, you have the option to calculate the travel time differently in the "From-To" direction and the "To-From" direction, which refers to the direction of digitization. So, you do NOT need two different line features. You just need one line feature, and you can determine the impedance differently depending on the direction of travel along that one line feature.

See my example below. In this example, I'm setting the impedance for Streets to a constant of 1 in the From-To direction and a constant of 2 in the To-From direction. You don't have to use a constant. You could use a Field or a Function evaluator or whatever. It works the same.

2 people found this helpful
Like • Show 0 Likes0
Actions
- RogeRThaT @ MMorang-esristaff on May 11, 2017 11:58 AM
  Thank you for your answer.
  
  I remodeled the dataset, and got rid of the double infrastructure and applied your solution to take into account the difference between boarding and leaving the metro. Therefore, i also deleted the oneway restrictions.
  
  However, a similar problem keeps occurring. Now, i am not able to go from the transfer line to the 'real' infrastructure. I still do not have any idea what causes this.
  
  It is possible to travel along the transfer line (first screenshot). However, when the 'false metro station' is reached, it is not possible to travel further and i get an error (second screenshot). However, i am pretty sure that the infrastructure is connected, as shown in the third screenshot and my connectivity should also be correct (fourth screenshot).
  
  I hope you or somebody else can help me.
  Like • Show 0 Likes0
  Actions
MMorang-esristaff May 11, 2017 12:29 PM
This network looks very complicated.

Even if your connectivity policy is correct, the points of connection still need to have either a vertex or an endpoint. In your second screenshot, does the blue line have an endpoint or vertex where the pink line touches it?
Like • Show 0 Likes0
Actions
- RogeRThaT @ MMorang-esristaff on May 11, 2017 1:04 PM
  In the original data there's no end point at the intersection with the blue line.
  However, in the edges, it is divided at the point of intersection.
  Furthermore, when i invert the stops 1 and two, traveling is in fact possible (See screenshot)
  So does the fact that there is no end point in the original data affect this?
  Furthermore, i would like to thank you a lot for your help.
  
  .
  Like • Show 0 Likes0
  Actions
  - MMorang-esristaff @ RogeRThaT on May 11, 2017 1:12 PM
    How are you calculating the impedance on the blue lines? It sounds like it's only letting you travel on the blue line in one direction. Or, do you still have a oneway restriction, and is it restricting travel in a particular direction along the blue line?
    Like • Show 0 Likes0
    Actions
    - RogeRThaT @ MMorang-esristaff on May 11, 2017 1:25 PM
      My impedance is calculated with a 'minutes' field.
      I do in fact have a one-way restriction on the blue line, because i do not want people to get from the metro network to the bicycle network, because you cannot take your bike in the metro.
      
      However, underneath the blue(bike) line, is a red (walk) line to which no one-way restriction is applied. Also, there is a double 'false station' one for the bikes and one for the pedestrians.
      
      So obviously, when getting from the metro network it is impossible to get on the bike transfer line, but the solver should be able to make the route go trough the pedestrian transfer, right?
      
      Like • Show 0 Likes0
      Actions
MMorang-esristaff May 11, 2017 1:47 PM
Is either of your "false stations" restricted? Because even if the lines are unrestricted, if the junction between them in restricted, then it might not be possible to travel through the junction. Even if one junction is unrestricted, the restricted one still blocks the path.

Is there a reason you've chosen to duplicate your lines for the walking and biking modes? I think it would make a much cleaner network and less confusing network if you just used a single set of line features for both walking and biking. You can add some attribution to the line features, like a field called "BikesAllowed" and one called "PedestriansAllowed" or something like that, and then you can just create restrictions that control whether or not travel is allowed on those network edges.
Like • Show 0 Likes0
Actions

RogeRThaT May 11, 2017 2:38 PM

My false stations are not restricted. At least i don't think so, in the added screenshot there is also nothing indicating a restriction.

I chose to duplicate it because i got the data from somebody else this way. I also have to say that where the different line features overlap at lets say 90 percent, there's also infrastructure that's bike-only or pedestrian-only.

Also, i am not very familiar with programming in Python, so i decided that if i could work around it, i should.

But let's say i would merge the two layers. How would i make sure that after the commuter has been on the metro, the network analyst will take into account only the pedestrian time of the infrastructure? And that it will not use the bike-only infra?

Actions

MMorang-esristaff

@ RogeRThaT on May 11, 2017 4:02 PM

The problem with having overlapping lines is that a stop or facility or whatever will "snap" to the closest network edge. When they are directly on top of one another, it's sort of arbitrary which one it picks. I think maybe in the example above, it snapped to the bike line instead of the pedestrian line. The bike line has a oneway restriction, so it won't let you travel in that direction. You would have had to snap to the walk line instead in order for that route to work. You can control where your stops and facilities a little using the location settings tab on the NA layer, but that gets ugly quickly. It would be much neater to merge it all into one dataset and use restrictions. When you turn on, say, your biking restriction, and you turn on "Do not locate on restricted network elements", then the stops or facilities won't get located on network edges that don't allow bikes.

To answer your question about pedestrian time, you need to create two different cost attributes, one for walking and one for biking. You would set up the evaluators for each attribute to model the correct travel time based on walk speed or bike speed. So, pedestrians and cyclists use the same lines, but the travel time is calculated differently. When you run your analysis, you just choose the correct cost attribute (and restrictions) for the mode you're trying to model.

Actions

RogeRThaT @ MMorang-esristaff on May 11, 2017 4:15 PM

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.

Actions

MMorang-esristaff

@ RogeRThaT on May 11, 2017 4:36 PM

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.

Actions

deleted-user-qBkp2qFgqzj- @ MMorang-esristaff on May 12, 2017 9:14 AM

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!

Actions

deleted-user-qBkp2qFgqzj- May 12, 2017 9:03 AM
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!
Like • Show 0 Likes0
Actions
- MMorang-esristaff @ deleted-user-qBkp2qFgqzj- on May 12, 2017 9:14 AM
  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.
  Like • Show 0 Likes0
  Actions
  - deleted-user-qBkp2qFgqzj- @ MMorang-esristaff on May 12, 2017 9:26 AM
    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?)
    Like • Show 0 Likes0
    Actions
  - RogeRThaT @ MMorang-esristaff on May 12, 2017 9:34 AM
    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.
    Like • Show 0 Likes0
    Actions
    - deleted-user-qBkp2qFgqzj- @ RogeRThaT on May 12, 2017 9:42 AM
      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.
      Like • Show 0 Likes0
      Actions

GeoNet

The Esri Community

Unclear what is wrong with Oneway restriction

Attachments

Outcomes

Related Content

Recommended Content