Latest Contributions by MelindaMorang

Thank you Francisco. I have been communicating with @EspenFredrikGudevang via private messages for more details on this issue, but I agree with your conclusion that the problem is with Build Network.  Using the network he sent me from the model output, I see the swapped time and distance when I examine a street using Explore Network or when solving a route.  This means that the bug is not in the solvers or in Explore Network, but rather the Build Network process has somehow mixed up these two attributes.  Doing a full rebuild of the network using 3.2.2 or 3.3 fixes the network. The next step in investigating the problem is to find a workflow (via Model Builder or whatever) that reproduces the problem.  Hopefully you can share the model with us. Go ahead and escalate your case to Esri, Inc. Support. It will come to me anyway, but through official channels. ... View more

The key is that you need two fields, not one.  The field values represent the "level" of each endpoint of the feature. For instance, let's suppose you have an overpass and underpass with endpoints at the location where they cross (four features total with eight endpoints).  Because your data is 2D, it looks something like this:   But really, it's an underpass/overpass situation, and you don't want the roads to connect where they intersect.  To do that, you need to add fields like F_ZLEV and T_ZLEV and assign them different elevation values to ensure that they don't connect.  For example, set the overpass values to 0 and everything else to 0.   The hardest part is figuring out whether to set F_ZLEV or T_ZLEV to 1 because the correct field to use depends on the direction of digitization of the street feature.  The F_ZLEV field describes the level of the "from" endpoint  (the starting point of the feature), and the T_ZLEV field describes the level of the "to" endpoint (where the feature ends).   ... View more

Hello Yigal. We don't currently offer this functionality, unfortunately.  You can solve for the optimal route and then use barriers to block key parts of that route and solve a second time to get an alternative that avoids the barriers, but this tends to be rather imperfect and hard to do. If this functionality is important to you, please repost this to the ArcGIS Ideas site as an enhancement request: https://community.esri.com/t5/arcgis-network-analyst-ideas/idb-p/arcgis-network-analyst-ideas  Enhancement requests posted in ArcGIS Ideas are tracked differently on our end than questions here, and it also gives other users the option to upvote the idea.  Alternatively, you can log your enhancement request with Esri Support or Support for the distributor in your country. When you post your idea or call Support, please add as much detail about your use case as you can.  Explain why you need alternate routes, what the goal of your analysis is, etc. ... View more

@RussellProvost1 Were you able to get your scripts working, or do you still have an enhancement request or questions?  Thank you. ... View more

From the comments in this thread, I believe the original idea was based on an incomplete understanding of the analysis limits or confusion between two different solvers.  This thread hasn't had any activity in over two years, so I'm closing it.  Feel free to leave another comment if you feel that your idea or question has not been sufficiently addressed. ... View more

When you say "A new, complete build removes this error", do you mean that your network dataset was in an unbuilt state when you were using Explore Network initially?  Like maybe you edited the attributes or evaluators?  If that's the case, maybe the Explore Network tool was getting confused because of the change, and closing and reopening Pro refreshed some sort of cache.  Essentially, until the network is built, the changes to the attributes are not reflected on the internal, logical network that Explore Network reads, and the values might be incorrect. If the problem is still reproducible after the network has been built, then I would consider it a bug of some sort that we would want to investigate. ... View more

If you can share your data and the changes you made to the network dataset properties that reproduce the problem, we can take a look.  Alternatively, you can submit a ticket through Esri Support (or through your distributor), and we can look at it that way as well. ... View more

The Network Analyst extension deals exclusively with transportation networks, so I'm going to move your question to somewhere that the right people are more likely to see it.  I hope you find the answers you're looking for. ... View more

Are those grid lines the streets (edges) in your network?  If so, then it's likely that some of the points are being snapped to the street locations outside the 23km cutoff distance.  You an see where the selected streets extend beyond the edge of the service area. When you do a network analysis, the input points must be "located" on the network, meaning the closest non-restricted location on the network is found, and that location is used as the start and end point for the analysis.  Since it looks like your evenly spaced input points are much denser than the grid network, a lot of them will be snapped a fairly large distance to the closest location on the grid.  The snapping distance is not counted as part of the 23km cutoff.  Here is some documentation about the locating process: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/locating-analysis-inputs.htm ... View more

Assuming you have configured your PublicTransitTime cost attribute according to our tutorials and/or used our network dataset template, then solving using this cost attribute works as follows: the travel time along public transit edges in the network uses the transit schedules and models riding transit, and the travel time along street edges in the network uses walking time along those streets.  So, solving using PublicTransitTime is a complete solution to model a traveler who can take transit but must walk along streets to get from their initial location to transit stop, make transfers between stops, and get from the final transit stop to their destination.  You don't need to add anything else to the analysis to make it correctly model walking when not using transit. The WalkTime cost attribute is a completely separate cost attribute that is configured in our template primarily to support accumulation.  If you set this as an Accumulate Attribute, it will tell you how much travel time was walking because it returns the walk time value along streets and returns 0 for transit lines.  You can read about Accumulate Attributes in this documentation page for closest facility layers (it's a long page, so search for "Accumulate Cost Attributes".) ... View more

That second warning message tells you what's wrong.  You can click the warning link to see the documentation for that message, which should give more details.  But, basically, you need to check on the option to interpolate blank stop times.   ... View more

I can help you with this, but your screenshot of the error message has the detailed messages cut off.  Can you copy/paste the full list of errors?  One of those should give more details about what went wrong. ... View more

You could change your restriction's usage type to "Avoid High" instead of "Prohibited".  This will allow the biker to use the large roads if no other path is available.  Documentation: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/restriction-attributes.htm#GUID-E02CEE7B-7957-490F-BAD9-611FB50EB444 ... View more

The travel mode type doesn't really do a whole lot, but if you set it to Walking, it will use a smaller pixel size for your Service Areas and make the polygons a bit more detailed.  But it doesn't do anything to affect the actual analysis result. If your road is "major" but also has a bike lane, you should probably just make it not restricted.  Otherwise, bikes won't be able to ride there, which isn't your intention. Note that crossing major roads can still be a challenge/problem on a bike, so it may not be that inaccurate to show that the area across the street is inaccessible unless you have good infrastructure for crossings and left turns. ... View more