Latest Contributions by JonDeRose

Thank you for the reply @GIS_Solutions   I understand this should not be seen when working with branch versioning but thought there might have been issues related to a previous cached connection that might not have been configured as branch initially.   I can force the error if I intentionally attempt to register as traditionally versioned with move to base before changing he connection properties, otherwise I cannot replicate. If you are able to reproduce this issue with a new database connection in a new instance of Pro and provide the steps you are using to reproduce the issue I would be happy to review this further on my end.   Just a note on labels.  We are looking into ways to improve the experience with them in this community; however, please know that these are not required to create a new post/question. If you hover over the info icon this provides more detail and communicates that these labels are optional.   Thanks, Jon ... View more

@GIS_SolutionsI've moved this post out of Ideas into Questions.  The error message you are receiving is consistent with registering a feature dataset containing a UN without using a branch versioned database connection as @JayantaPoddar noted. When registering the dataset containing the UN as versioned At any point did you see this dialog, and if so, do you select the check box and click OK (Note: this option is not supported for datasets like the UN)? Can you confirm the Geodatabase Connection Properties for this particular database connection are now set to Branch as shown below?  On the other dataset that you are able to register as versioned, can you confirm it is registered as branch?  (Right-click feature class and open Properties, view "Versioning".  Does this read "Branch"? If yes to all of the above, does the issue persist after closing and restarting ArcGIS Pro? It is possible you are running into a workflow related issue caused by an initial caching of the register as versioned using move-to-base.  In testing I ran into a similar issues but was able to get past this by closing and re-starting Pro.  I am going to look into this issue further.   Jon   ... View more

Thanks @curtvprice To confirm, this is seen when you are attempting to place a new starting point in the trace locations pane?  Is there any change in behavior depending upon the network feature you place the starting point on?  Does the feature display in the the pane pane before it is displayed on the map? Working with a large NHD sample dataset I am not able to reproduce similar behavior but I'd like to get a better idea of what you are encountering.  Could you share the diagnostic log from the ArcGIS Diagnostic Monitor while performing the action?  Open ArcMon by pressing   Cntrl + Alt +M, enable Diagnostic log (logs to C:\Users\<user>\Documents\ArcGIS\Diagnostics\ArcGISProLog.xml) and attempt to place the starting point.   ... View more

Good morning Rudy, While the utility network is not industry specific, we do have a Learn lesson that allows users to explore the components of the utility network through the lens of an electric configuration. Get Started with the ArcGIS Utility Network This lesson was originally authored for the ArcGIS Pro 2.5 release and has recently been updated for 2.7.  Take a look and let us know what you think. Thanks, Jon ... View more

@Thom_Leeffers   Just to clarify, you should not need to unversion your data or "flatten your versioning tree" to make schema changes, add rules, etc.  While removing existing named versions to add rules, etc. may be completed as a best practice to prevent the need for additional steps to be performed with each existing version...it is not required.  The schema of the data itself is not versioned, and (as an example) any rules that are added to the Default version would be pulled into the named version through a reconcile. Here's a KB in ref to versioning of table schema (older but remains relevant with branch):  https://support.esri.com/en/technical-article/000008159 We will investigate methods to clarify this further in our documentation. Here is a doc reference regarding rule modifications wrt deletion:  https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/delete-a-connectivity-or-association-rule.htm - Jon ... View more

Seconding Dan's suggestion.  The script is "correct" as written however, the issue is most likely access to the data. ... View more

@JackDaniels519 Thank you for the details.  I've taken a look at the data you have shared and can reproduce the issue.  The issue appears to be related to the location of the starting point in a loop; however, I have not yet been able to determine the cause.  I've created an issue to investigate and can provide more insight once we've had an opportunity to review further. ... View more

Thanks for the reminder @TimWhiteaker !  I discussed with @AustenCutrell2 a bit further and we identified that the only remaining issues encountered were related to placement of user-defined starting points on junction features when performing a shortest path trace. This issue was addressed as part of the 2.8 work.  In this use case, populating FEATUREGLOBALID for the trace location enables a work around. To your point @TimWhiteaker , you are correct arcpy.Describe would be the method to get access to the SOURCEID; however, as I mentioned previously, this is NOT required for user-defined trace locations.  When working with a trace network in a file geodatabase we can supply the FEATUREGLOBALID to provide granularity over which features in a trace locations feature class will be honored.  If this field is absent from the schema of the trace locations feature class, the geometry of the feature class is used to intersect the network feature geometry and place starting points or barriers.  Note that this does not apply to Trace Network Services with the upcoming release of Enterprise 10.9, in that case, FEATUREGLOBALID is a requirement.   - Jon   ... View more

Austen - I am not able to reproduce this behavior with 2.7.  I'll reach out to you separately to see if we can identify differences between our two approaches or determine if working with Support might be a better avenue. ... View more

Hi Austen, I am sorry to hear of the challenges you are running into.  You are correct that the SOURCEID/FEATUREGLOBALID are not required for trace locations coming from a user defined feature class.  When these fields are absent from the schema, the geometry of the input feature class is used to intersect the geometry of the network feature and place the starting points. The team addressed issues related to trace locations placed on junction features in the 2.7 release.  It sounds as though the issues you are seeing are specific to Shortest Path traces alone?  Is that correct or are you seeing this with other trace types as well?  One issue that we were unable to get into 2.7 related to placement of starting points on junction features when performing a shortest path trace.    If this is encountered only with Shortest Path traces you may be encountering this behavior; however, in that scenario populating FEATUREGLOBALID enabled you to work around that limitation.  One additional scenario that could trigger 002512 is when more (or less) than 2 trace locations exist. To confirm, I reproduced this again with a 2.7 client before testing  with a recent 2.8 build where I was no longer able to reproduce the issue.  Can you confirm whether creating a new junction feature class and populating this with the GLOBALID of the source network feature allows you to run the trace?  It is possible I am missing a component of your workflow. One other potential.  am not sure if this would be feasible based on the length of your edge features in the network; however, one potential solution in the interim would be to place the user-defined starting points along an edge. Thanks, Jon ... View more