|
POST
|
The fastest way I've found to do this on Enterprise is to use the ArcGIS API for Python. That's a weird response your getting, and my guess is you should be getting an error instead (check the server logs). The problem is that your starting locations are missing required fields. You're only providing a type and globalid, but you need to provide at least one additional value, depending on whether the starting location is a point or line: If you're running isolation traces from lines that can get tricky, because you aren't required to split lines at valves so you could potentially be missing out on results. This is why I'll usually try to pick some piece of equipment like a meter or a corp stop as my starting points, but put in skip logic to ensure I don't process the same area multiple times. If you are open to using a community sample written in C#, there is a batch trace community sample available that does all of this (including the skip logic). You just need to compile and run it. You would partition your network using your mains, then set up a named trace configuration to run a connectivity trace that stops at isolation devices. In fact ... there are already sample configuration files that do this for the standard naperville model, so you'd just need to adjust them to account for any schema changes you've made (Partition_Water_Isolation). You can use the link in the partition markdown page to access them:
... View more
2 weeks ago
|
0
|
3
|
413
|
|
POST
|
Can you please verify three things: The attribute rule for updating elevation to lines is assigned and enabled. The device/junctions on either end of the line have Z-values The line itself has z-values on its first and last vertex.
... View more
2 weeks ago
|
0
|
5
|
301
|
|
POST
|
Can you post a screenshot of what attributes or values you are expecting to be updated on the lines class? Do you have any attribute rules written to maintain these attributes as you are creating or updating features?
... View more
2 weeks ago
|
0
|
1
|
341
|
|
POST
|
@PierreloupDucroix you'll want to ensure that versions are reconciled on a regular basis. You can automate this, but you need to make sure that you don't reconcile a version that already has conflicts! Otherwise, you will automatically accept the conflicts as-is without any record that they existed (the default behavior). If you use Python you can accomplish this with the Reconcile Versions tool by seting the parameter proceed_if_conflicts_not_reviewed to NOT_PROCEED (which isn't the default value). If you're using REST, or some other means you will need to use the APIs to query for persisted conflicts on the version before you reconcile.
... View more
2 weeks ago
|
0
|
0
|
85
|
|
POST
|
@NathanHeickLACSD Correct, subnetwork flow direction is calculated every time. This is important, nay required for certain scenarios like cathodic protection. The upstream path to a pressure source vs. the upstream path to a rectifier (or the downstream path to an anode) are going to be different.
... View more
2 weeks ago
|
1
|
1
|
118
|
|
POST
|
Is the connection file using the credentials of the data owner? It sounds like there may be a difference in the connection files between the machines. If you copy one of the connection files from the other machines to this one, does it work?
... View more
2 weeks ago
|
0
|
0
|
152
|
|
POST
|
I like the idea of using Arcade to identify the nearest pole on-demand, you'll just need to make sure that your water editors have read-only access to the electric layers. If you combine both networks, then editors will need to have full read/write access to both datasets, and both editors will need to be careful with how they edit data. You'll also get some annoying scenarios like removing a pole as part of an electric design will cause a conflict with a water version because the water user added an association to that pole to a feature in their version.
... View more
2 weeks ago
|
1
|
1
|
159
|
|
POST
|
Do not manually run SQL statements to clear out history, that is a sure-fire way to corrupt the versions in your geodatabase. Enabling the network topology populates the table with the new mappings. The safe way to manage the size of these tables is to Be considerate about how often you are disabling and enabling your network topology or performing bulk updates on branch versioned data. If you need to remove rows, use the Prune branch history tool (read more here). This will safely delete records older than a certain date. If you are not routinely performing other data maintenance tasks with your database, the tool will not be able to remove as much history. I know that sounds vague, read the link I provided above for a more precise description.
... View more
2 weeks ago
|
1
|
2
|
102
|
|
POST
|
@PierreloupDucroix How would you configure the trace to stop at the first pole? Poles are part of the structure network, so they can't be used as barriers. I suppose you could trace to the first fitting or valve and see if it has a pole associated with it. For performance purposes I would think carefully about whether I wanted to turn on the update structure/domain container during update subnetwork. Do you really want to put the system, pressure tier, etc from your water network on your poles? Not only is it of limited value, but it will also make update subnetwork take longer to run (since it has to update all the poles in the network).
... View more
2 weeks ago
|
0
|
1
|
179
|
|
POST
|
Please log an issue with support then. There may be something else going on, or there may be a known issue (if you're on an older release) that I'm not aware of. The fact that you appear to have a custom coordinate system may be relevant.
... View more
2 weeks ago
|
0
|
0
|
258
|
|
POST
|
@PragatiSingh there's lots of discussion here. You have two domain networks, and the assumption is that you want them to be in separate utility networks You could put them in the same utility network if you wanted them to share structures or had some other compelling reason, but that is not typical for water/electric. If you do want to have multiple utility networks, then you can have options. If you just want to manage one database, you can put them in the same database but give each one separate schemas. If you put them in the same schema you will get name conflicts on the structure classes (so you'll have structurejunction and structurejunction_1). If you want to manage them in separate databases, then you are free to do that using however many databases, instances, and servers that you want because the two utility networks are not related in any way.
... View more
2 weeks ago
|
0
|
0
|
524
|
|
POST
|
@NathanGEOregon can you include a copy of the log from when you ran the tool? specifically I'm wondering if there are any warning messages for that field.
... View more
2 weeks ago
|
0
|
0
|
278
|
|
POST
|
@PierreloupDucroixthe most common cause of this is by frequent enabling/disabling of the network topology. the table maps every feature to its corresponding network element. every time you disable/enable the network topology we must delete and recreate all the mappings. The table is versioned, so if you are doing this frequently and not managing your conflicts and history than the table can become large.
... View more
2 weeks ago
|
0
|
1
|
229
|
|
POST
|
There was a bug that was fixed in one of the more recent releases of Pro that fixed an issue with snapping not working when the map was reprojecting the utility network (i.e. utility network is a state plane but the map was something else).
... View more
2 weeks ago
|
0
|
2
|
267
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | a week ago | |
| 1 | 2 weeks ago | |
| 1 | 09-22-2025 06:57 AM | |
| 1 | 2 weeks ago | |
| 1 | 2 weeks ago |
| Online Status |
Offline
|
| Date Last Visited |
Monday
|