Latest Contributions by RobertKrisher

The easiest way to access that programmatically is to use one of the APIs provided to read the annotation properties. Because you're using a MGDB I assume you're using ArcGIS Desktop? Which means you would use .NET, Java, or C++ and ArcObjects to access this information. It is possible to access ArcObjects using Python code, but it requires jumping through some extra hoops in order to load and work with the COM Objects used by ArcObjects. ... View more

@Andy_Morgan  In option 1 you get the Isolating valves, which is the slower isolation trace. Once you've done this, you use the faster connected trace to get all the isolated features. You're still doing two traces, but one isolation trace and one connected trace will always be faster than two isolation traces. The larger the subnetwork that contains the area being isolated, the faster it will be. Option 2 allows you to do it all with a single trace (choosing include isolated features gives you the isolated features and the isolating valves) but requires the tedious effort of digging through the complete trace result JSON to manually identify the isolating valves. You'll also need to make sure you filter out any false positives when doing this (valves 3972 and 3973 in your example above). Filtering out false positives is a bit tricky, but you'll want to exclude any valves that are barriers (i.e. closed) but still contain results on either side. These are uncommon, but possible. Option 2 can be done with either Pro SDK or Python. When talking about this with people (where I don't have the luxury of using bolded text) I usually refer to the results as the contents and barriers for the trace instead isolated/isolating. ... View more

Option 1- It should be faster to do the isolation trace to get the valves, then run a connected trace with the valves as barriers. The connected trace ignore terminal connections and subnetwork controllers, so there is the possibility for it to produce different results. The reason why it is faster is because a subnetwork trace must analyze the entire subnetwork to determine flow. If you run a connected trace it will only consider the portion of the network bounded by barriers. Option 2 - If you're willing to parse the JSON for the export, or manually inspect the results, you could run 1 trace then parse the results to find features that match your condition barriers (i.e. closed valves). This is something that the Batch Tracing CoreHost application that I linked to earlier does. Also, because it uses the Tracing API directly it bypasses the GP overhead and should be able to perform that analysis in a fraction of the time. For reference, doing this analysis for Naperville using raw GP takes about 8 hours, using the Pro SDK it takes a few minutes. ... View more

@VishApte_NGIS, we plan to include the fixes in a patch to 11.5. If you log a case with support and get attached to the bug you can get notified when the specific patch releases. ... View more

@BrandoCrozier note, if your original asset package used a D_Rename table to rename asset groups/types then the final asset types in your deployed utility network will be different and you will need to un-rename your asset types in the new rule table. ... View more

@MarkWasdahl1 after you've created the feature, you can go back into the attributes and update the elevation values of pipes that you know the elevation for. If that's the workflow you want then you can either disable the attribute to fire on update (i.e. on have it fire on create) or modify the rule so that if the elevation values of a feature are already populated that they won't be overwritten. This would allow you to manually specify an elevation when you know one without it being overwritten, and to null out the elevation and edit the feature to trigger the system to recalculate it. ... View more

@Yeaton have you confirmed that your lines are connected to the right terminal on the subnetwork controller? If the subnetwork doesn't have any lines, then this is likely the case. If your subnetwork consists of a single line, then it is likely that your first line is acting as a barrier. Check the fields used as condition barriers, like lifecyclestatus, and ensure its marked as in service. ... View more

The attribute rule should only fire on create, giving you initial elevation values to drive your slope/analysis. If you are blessed with having more detailed information about each invert that you can use to fine-tune the elevation data on your pipes after that then you should absolutely capture it. @MikeMillerGIS  thoughts? ... View more

That query is happening because when you disable the network topology, we mark all the subnetworks (and subnetwork lines) as dirty. If your subnetworks are already dirty and you are seeing that query, this is a known issue that is being patched through the network management release plan. BUG-000180226. ... View more

@EdwardBlair Customers often adapt the model to suit their requirements. In the case of rectifiers/anodes, because the Domain Network is defined as being source-based and because anodes aren't always physically connected to pipes you'll likely want to use rectifiers as sources (see article 2 for examples). I have seen some customers use the existing tier to manage this, foregoing the importance of test points. I have also seen one customer add a new tier so they could trace and manage the electrical conductivity of the cathodic protection system separate from the regulatory requirement. It comes down to what are the requirements that you are trying to solve with your GIS and what configuration best meets that need. This is why I linked to the first article, because it lays out the requirements and business case for the original design and configuration of cathodic protection in the UPDM model. ... View more

@Andy_Morgan You can mitigate the risks of pressure zone boundaries breaking if you have editors work in a version, instead of defaulting directly, and ensure they validate all their dirty areas, fix all their edits, and trace or update their subnetworks before posting their versions. This will flag any inconsistent subnetworks before they are posted to default and become everyone's problem. ... View more