Latest Contributions by RobertKrisher

When you ran the UN Migration Wizard (or the Migrate to Utility Network GP tool), you had to pick the target feature class for all your layers. If you want to use flow meters as controllers, then you should rerun the migration and put the flow meters in the device layer. While you're doing that you could also consider making siphons devices, in case you ever wanted to add a terminal configuration to them. ... View more

I just tested this out on my end and was unable to reproduce. I tested it using the 'asset manager' domain. If this is something you can consistently reproduce, please log a case with support. Also, for geodatabase/data modeling questions like this that aren't specific to utility workflows or the utility network itself I recommend you post them in the Geodatabase Questions community. ... View more

As long as the field isn't associated with a network attribute or something required by the utility network, you can do this the same way you'd alter any other field in a geodatabase. The Design view for fields or the Alter field tool. Edit: @VishApte_NGIS mentions below that if you just switch a field from lower case to upper case, it will not change the field. This means you must alter the fields(s) twice, once to make it upper chase (with an extra adornment like 1) and a second time to remove the adornment. To make this easier, consider using the Alter Fields (multiple) tool to make the two calls. ... View more

@PierreloupDucroix you are correct in that the behavior is slightly different when posting edits from a version. If the subnetwork or subnetwork line is modified in the version we will mark it as dirty when it gets posted because we know that there are changes that happened to it in the version that mean it needs to be processed in default. As an example, if you create new features in your version and run update subnetwork, they will have their subnetwork name populated and the subnetwork line will be updated to reflect the new features in your version. After you reconcile and post your version to default, there is no guarantee that those same features will be connected, so we make you rerun update subnetwork to ensure everything is clean and connected. ... View more

You can do this in the Field Design View to change them in the geodatabase, then any time you add that feature class to a map it will use the field alias. If you need to change MANY field aliases or domain descriptions, you could consider using the D_Rename table. If you have pre-existing maps, this change will not automatically apply to the layers in those maps. Instead you must manually alter the Field Alias on each feature/subtype layer, as well as any popups that have overwriten the default alias of the field. Something like the utility network properties extractor can make this process easier because it allows you to export properties to a file, adjust them, then re-import them. You can also use the Paste Properties command on a layer to paste the field properties between an already configured map and an existing map. Because of this it is best to get your field aliases figured out in your data model and initial map before you start making too many additional maps. ... View more

Disabling and re-enabling the network topology on a regular basis is going to have some long-term performance implications, and you shouldn't need to do that. I'd make sure that going forward, you're just always logged into portal, and if you run into any strange behavior, make sure you're logged into the right portal/service, restart Pro, and hopefully that fixes it. If you find the experience of editing using the web map from Portal acceptable, then that's fine. There's a lot more you can do with a desktop map in ArcGIS Pro than you can do with a Web Map in Map Viewer, but you aren't relying on any of those capabilities so you're fine (display filters, layers with multiple definition queries, etc). ... View more