Latest Contributions by MelindaMorang

This definitely looks strange. Your code looks fine to me. What I can't determine from your screenshot is whether there are edges in your network underneath that zig-zaggy purple line.  Are there?  Or is the line just completely different from the underlying features in the network?  In other words, is the purple route following SOME kind of streets, or is it just generating a wacky geometry that has nothing to do with the underlying network? Since I really have no idea what might be causing this, here are some questions and things to check that might lead somewhere: Does your travel mode (any of the ones you've used) have a simplification tolerance set, and what is it? Is your network dataset built?  Have you edited the geometry or settings since the last time you built it?  (The General page on the network dataset properties will tell you if it's built.) Are you 100% sure that the route you created using the Pro UI was using the same network that your script is using?  Did you accidentally use ArcGIS Online as the network data source for the layer in the UI? If you call export() in your script to export the output route to a feature class, does it still look strange?  Maybe the problem is in the insertCursor. This definitely seems like a strange issue, and if none of these questions lead anywhere, you might be best served by calling Esri Support or Support for the distributor in your country.  They can look at your workflow in detail and try to identify the problem. ... View more

Yes, if you were able to successfully create and build a network with your edited template, then this should be sufficient to resolve the problem. ... View more

By the way, this was an extremely strange issue!  I'm sorry you encountered it, but it's certainly not something we had ever thought to test.  You found a very interesting challenge for our team. ... View more

Yeah, you can't create a network dataset layer with a URL.  You can just use the URL directly: arcpy.na.MakeClosestFacilityAnalysisLayer("https://myportal.mydomain.com/portal/") or arcpy.nax.ClosetFacility("https://myportal.mydomain.com/portal/") ... View more

It's interesting that you're not getting an errors here.  If the exported Routes sublayer is empty, then I would suspect that the solve is failing, but that would throw an arcpy.executeError.  Try printing out the GP messages after calling arcpy.na.Solve().  arcpy.GetMessages() will return all messages returned by the tool.  Maybe there are some warnings that will explain what's going on. With that said, if a Python script or process is your ultimate goal, there's a better way to do it than using Make*Layer, Add Locations, Solve in a script.  That workflow works great in the UI, but for Python, there is a much faster and more Pythonic way to code up a network analysis workflow using the arcpy.nax solver objects.  This documentation explains the process: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/performing-network-analysis.htm.  This documentation is for the ClosestFacility object: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/closestfacility.htm.  I recommend just switching over your code to use this instead, and maybe your problem will go away. Another thing you can try (with your existing script or with new code using the arcpy.nax solver objects) is to write the code to use the local Streetmap Premium network dataset and be sure it works.  Once that's working, you should be able to switch the network data source to use the URL to your portal service, and it should just work (provided the portal is signed in).  If it works with local Streetmap Premium and then doesn't work with the portal, then something is wrong with the portal configuration or the log-in.   ... View more

Hmm, you might have to experiment with a few things.  I don't think you can change the Shape field name of an existing feature class, but maybe you can create a new feature class and then append the rows to it from the old one.  Or maybe use Export Features and fix the Shape field name in the field mappings. Another option is to open up the XML template and change "!Shape!" to "!Geom!", but those templates are complicated and not really intended to be edited manually. ... View more

Sometimes if you create or update folders while Pro is open, it doesn't notice the changes automatically.  Try clicking the refresh button on the dialog.  Does your folder appear?   ... View more

I think the error message gives a clue: [Attribute: Length, Source: TF_Streets, Evaluator: Field, Field: Shape] Check the Shape field in the Streets feature class.  Is it called "Shape", or did it get some other name for some reason?   This could happen if you exported or copied data from a shapefile or some other feature class with a non-default Shape field name.  The template is expecting the field name to be "Shape". Let me know if this seems to be the problem, and if so, we can figure out how to get around it. ... View more

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