True Curves in Pro 3.5 & Enterprise 11.3 Editing Issues

Question

We have a utility network on UNv7 and are currenting operating at Enterprise 11.3. Previous versions of Enterprise (10.9.1) had a feature service property to allow for editing of true curve features. This feature was removed in 11.3 but added back in 11.5 ;however, we just upgraded to 11.3 at the end of last year.

During one of our editing workflows, we were unable to edit true curve features because we cannot check the box in the feature service to allow it to be editable. We are uncertain how to proceed as upgrading to 11.5 is not possible at this time.

While the initial solution might be to identify (over 50K) line segments that are true curves and use the generalize GP tool to add the vertices in and remove the curve. However, this will add overhead to the database by adding tens of thousands of vertices to the GIS; we're currently researching how this impacts database size and performance. At the same time, Web Maps and online platforms don't really support the drawing of true curve features and are unlikely to be supported outside of Pro any time soon.

I'd rather NOT diminish data quality and performance to accommodate a software gap but I'm uncertain of how to handle the gap in data editability.

Any ideas or insights would be most welcome.

Thanks!

Jennifer Smith

RussellBrennan · Answer

I think it would be good to review the code. Is the custom tool writing it's own ApplyEdits JSON and sending that via the REST API?

I am not sure if this is applicable but have you considered Batch Calculation Rules?https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/calculation-attribute-rules.htm#ESRI_SECTION1_E990820A77724C8AA285A3D23C59E96F

jennsmith_ElectricUN · Answer

The custom tool essentially triggers an "update", which then causes the attribute rules to run. It's a workaround to help us populate fields based on calculation attribute rules after the object/row was created. It's just a way to fire the attribute rules in a version to update fields without having to manually touch each row. To my knowledge, we are NOT touching the geometry so that is why I'm interested in the errors being thrown. In this instance, we were trying to populate a field called "symbol_code" which we use to symbolize features in both our web maps and offline maps due to limitations with subtype groups. The line feature itself - in terms of geometry - is not being updated but the field for symbol code was. I'll see if we can get dev to look at the code to ensure geometry isn't being touched.

RussellBrennan · Answer

Hi @jennsmith_ElectricUN

You can uncheck the box to only allow true curve updates by true curve clients. This will allow all clients to edit the geometries of these features, even clients that do not support curve editing. This does come with some risk as it has has potential to densify curves if someone edits these curves with a non-curve aware client. I am a little behind on which clients currently support true curve editing right now. If you are not editing the curves or can implement controls on who has access to edit with this setting you should be safe to do so.

I might be able to provide additional suggestions if you could explain exactly what you are doing when you said: "We are trying to use a custom C# script to use the API and trigger the firing of our calculation attribute rules." If you are not editing the geometries in this script I am surprised that the curve checks are causing errors.