Latest Contributions by MelindaMorang

Hello again, Rogier.  The OD Cost Matrix solver does not preserve the "traversal result", the actual network path from the origin to the destination.  So, you will not be able to determine which transit stops were used.  However, if you use the Closest Facility solver or Route solver, you CAN access the "traversal result" by using the Copy Traversed Source Features tool.  This tool will create feature classes showing the network edges, junctions, and turns that were used in the route, and you could extract which metro stop was used from the junctions feature class. ... View more

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. ... View more

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. ... View more

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. ... View more

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. ... View more

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? ... View more

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? ... View more

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. ... View more

Hi.  It sounds like you have a reproducible crash.  Sorry for your trouble!  The best thing for you to do is to submit it to Esri Support, and they can work with you to resolve it or work around it, and also forward it on to the development team as appropriate: Esri Support Home  ... View more

So, you have a feature class with a field called MAX_SPEED, and you're using that field in a descriptor attribute in a network dataset.  Are you asking how to determine the largest MAX_SPEED value in a solved route, or something like that?  So, a route from Point A to Point B travels along some streets, and you want to know the largest MAX_SPEED value of the streets used in that route? If this is the case, I think you can use the Copy Traversed Source Features tool after solving your route to get what you want.  This tool will create a feature class showing the actual street segments that were traversed.  You can use the SourceOID field to join your source feature class to this by ObjectID, and you can transfer the MAX_SPEED field over.  You don't actually need to add MAX_SPEED as a descriptor in the network dataset. ... View more

Hello.  What do you mean by "META-DATA"?  What information are you trying to get? ... View more

Hello, Yosef.  You probably just need to save the output from each chunk separately and then merge them all at the end. ... View more

Do you need to create a network dataset, or could you use the ArcGIS Online Services instead?  The Online Services use authoritative network data.  You get charged a small number of credits per analysis, but it saves you the time and effort of setting up your own network dataset.  Since it sounds like you don't have any street data, this might be a good solution to you. ... View more

The error message to me indicates that your parameters are out of order.  It must be looking at the value of one of your other parameters which you have accidentally put in the place where the hierarchy setting should go.  Double-check your parameter order, or (maybe easier), use explicit keywords when setting each parameter.  For example, arcpy.GenerateServiceAreas_na(Facilities=PDS1, Break_Values=Break_Values, Break_Units=Break_Units, Network_Dataset=streets, ... I'm using the parameter names as specified in the tool documentation.  You can leave out optional parameters for which you just want the default, and the parameter order doesn't matter. ... View more