Event Records not Merging as Expected

257
5
07-22-2019 09:07 AM
Labels (1)
Highlighted
New Contributor II

If an event record in the middle of two similarly attributed event records is changed, the record will only merge with one of the events. The expected outcome would be one continuous event record, but the result is two records.  This was tested in both 10.5.1 and 10.6.1.  This occurs whether the edit is made in the Event Editor attribute table or if the Add Linear Events tool is used. 

This bug has been reported to Esri Customer Help.

5 Replies
Highlighted
New Contributor

I can verify that we have experienced the same issue with merging records here at the Michigan Department of Transportation in Event Editor at 10.5.1 and 10.6.1.  Please keep us posted here regarding the response to your bug report.

Highlighted
New Contributor II

This has now been assigned a defect number:

BUG-000123915
Synopsis: Event Editor does not merge all records accurately using the Add Linear Events tool

Highlighted
Esri Contributor

Hi Amelia,

For workflows like these where you'd like to merge more than 2 events, you should use the merge events widget in Event Editor (https://enterprise.arcgis.com/en/roads-highways/latest/event-editor/merging-events.htm).  It will allow you to change attributes and merge more 2 or more adjacent events together in one operation.

Nathan

Esri Roads and Highways team

Highlighted
New Contributor II

Hi Nathan,

Thanks for your response.  That would be an optional workaround, however, it does not address the main issue.  Modifying a record, or adding a new record that is buffered by two records that have the same values should "naturally" merge all three records.

The reason I believe that the workaround is not sufficient is because this occurs for many scenarios, not just the scenario above where exact measures are being changed.  If you use the create linear events to create an event "A" from measure 0.5 - 2.5 in the scenario above, you will still have a similar "after" table of two records.

Another issue is that many users will be using an attribute set to update multiple events at the same time.  To use the workaround you are proposing, they would need to check the adjacent event records for each individual event at the location where they intend to make a change and then make a decision about whether or not they should use the attribute set when they add linear events, or if they should use the merge events widget.  This would need to be done for every single edit, greatly reducing the timeliness of editing data and eliminating the benefit of utilizing an attribute set.

Additionally, if that middle red portion were a different route that was reassigned to fill the gap in the blue route, and both routes had the same event value, the events do not merge together. 

There appear to be multiple scenarios where a user would expect a full merge to occur based on their edits, but that does not occur.

Highlighted
Esri Contributor

Hi Amelia,

Thanks for the additional information about related workflows.  The Apply Edits REST endpoint that is used in Add Linear Events and when updating events in the event attribute table is only able to merge with one adjacent event currently (not both like in the case you mentioned originally).

We could add support to merge with all adjacent events, however, the downside to adding this support is performance of the endpoint will be slowed down.  Because this endpoint is utilized for the majority of operations in Event Editor, the performance impact would be seen throughout, even if there is no merging that would take place.

We're open to making this change to the endpoint, however, the trade off would be decreased performance throughout the application.

As I mentioned, the Merge Events widget can be used to merge adjacent events, either in place of Add Linear Events/event attribute table editing, or as a step after using those tools.

I'm happy to discuss this point at the next RHUG meeting to get an idea of the rest of the communities thoughts about whether the trade off in performance is worth adding this support.

Nathan

Esri Roads and Highways team

Reply
0 Kudos