Latest Contributions by MelindaMorang

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

@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