Latest Contributions by RobertKrisher

Another option is to consider using the Differences API on the version management to get all the edits that have been applied to a version (or default) between two moments in time. This approach allows you to see all changes made to features, including changes made to non-network attributes. You will need to do some additional work to identify which subnetworks were affected (likely relying on the subnetwork name field). You could run this process every night to identify all the features that were modified (and their corresponding subnetworks) then determine whether or not to extract a subnetwork that night based on some threshold you set up. As @gis_KIWI4 suggested you will likely want to have a business rule that says that even if a subnetwork hasn't had any significant change, you still must extract all dirty subnetworks within x days of it becoming dirty (using the logic outlined in option 2 above). I have also seen option 3 implemented, with some success, since it does a comparison of the extracts from the last circuit imported to the ADMS and the latest circuit. This is better than trying to detect edits on the GIS side, since that requires a detailed understanding of how information from the GIS is mapped to the elements in the ADMS. ... View more

@RogerFarmer1 the add-in is provided as-is. The code for it will be released soon, at which point you can customize the add-in however you want. ... View more

It depends on the kind of valve between the two districts and what tier the subnetworks belong to. I'll call out @TomDeWitte for the final design intention of the model since it doesn't contain any definition of a district metering area. At the end of the day, it is your model, and you should configure it to meet your needs. If we interpret your question through the way the model comes configured, I have to assume that the district is either a system, pressure zone, or isolation zone. You can look at the data model to see what devices are allowed to control subnetworks to infer how the model was designed to be used: System - If these districts represent different systems and the PM is actually a meter, then this could be represented as a system subnetwork where the PM is a Custody Transfer Meter. Pressure Zone - If the valve regulates pressure, this could be represented as a pressure subnetwork where the valve is a regular and the subnetwork controller. The PM would be a Pressure Monitoring Device. Isolation Zone - If the valve is a Controllable Valve between two arbitrary areas of your network that you want to be isolation zones (it seems unlikely, but I'll mention it here). The  If it's some kind of metering district, then we'd be talking outside of the current configuration, and I'd want to defer to Tom before I exercise too much creativity. ... View more

@aperi read this article for more information about one-way feature service-to-feature service sync capabilities: One-way feature service-to-feature service sync for simple features. For a full utility network, you can use any of the approaches you mentioned above depending on your requirements. ... View more

Mostly, except for the piece about libraries only existing in certain places. The different applications (ArcGIS Enterprise, Pro, etc) have libraries that allow them to read/write the data in the geodatabase. If you want to edit data in a geodatabase outside of these applications (your own application, script, or interface) you can either use one of the SDKs (including APIs for the rest interfaces) or libraries (like ArcPy) that Esri provides. ... View more

This article should help answer these questions: To Branch or Not to Branch - An Introduction to Branch Versioning. The only additional context you need to know is that when a utility network is in an enterprise geodatabase, it must be registered as branch versioned in order to be edited. ... View more

I would recommend you manage them as simple features in a separate dataset and if you want to do network analysis with their data you will need to wait for them to migrate off their geometric network. ... View more

@SusanONeill1 When looking at the error summary table make sure you look at the occurrences field for each error summary. You should find that when you add the number of occurrences for both of those rows together you will get the correct number (which will match the number of error location features you find). ... View more

Have you opened a case with support yet? ... View more

By not being in the network they will not be included in the trace, but you'd need to talk to @TomDeWitte about the intention behind making squeeze off's non-network. It may be that the intention is that squeeze offs are not permanently maintained as network features, but are used as inputs (temporary barriers) during trace. Keeping them outside the network makes them easier to track and avoids issues with network rules or other topology errors while still allowing them to be used for analysis purposes. ... View more

@SusanONeill1 Can you post a screenshot of the complete results of all the errors discovered by the Analyze Network Data tool? The Errors by Type chart gives a good breakdown. I want to see all the errors it discovered, as well as the number of occurences of each error. ... View more

@ToddW_stl when the second checkbox is checked it will cause the tool to only prune system tables, while leaving user data (i.e. the tables you can see in Catalog) untouched. This is important for some users who need to retain a longer history for edits made to user data (parcels, transformers, etc) for regulatory reasons but still want to prune system tables (like dirty areas or the network topology) more aggressively. ... View more

@gis_KIWI4 is correct, when running that GP tool in a server context, it doesn't have access to the map that the user has open, so it has no way of knowing what is selected. The solution to the problem is to populate the trace_location parameter with the information for the locations/features you want to use as barriers. ... View more