Optimize Route Event Layers

Bud

Route event layers that are based on large event tables (>1000 rows) are relatively fast when drawn in the map. But they could be faster.

It's occurred to me that plotting events along a line using M-values is computationally expensive process. There's likely a fair bit of trigonometry being done. And things like multi-part features and true curves would add complexity & slowness too.

Idea:
If an event spans the entire length of the line (F_MEAS = 0 and T_MEAS >= line length) then just use the line geometry from the FC -- instead of plotting the event along the line. If the event only spans a portion of the line, plot the event along the line as usual using trigonometry.
That might improve Route Event Layer performance since using an existing shape would be faster than generating a new one (plotting an event along a line). For example, drawing a feature class in the map is extremely fast -- way faster than a Route Event Layer.

Could the ArcObjects code behind Route Event Layers be optimized using a technique like that, if it's not being done already? (I assume it's not, otherwise I think my Route Event Layers would be as fast as a FC.)

Bud · ‎03-24-2023

Notes:

Maybe the optimization would be an optional setting in the Route Event Layer properties. That way, if the optimization didn't actually speed things up due to the majority of events only span a portion of the line, then the optimization could be disabled.

I suppose as a temporary workaround to make my maps faster, I could create two layers in my maps:
1) Route Event Layer: for events that only pertain to a portion of the line.
2) Feature Layer: for events that pertain to the whole line. Join from the FC to the event table WHERE F_MEAS = 0 and T_MEAS >= line length. Join type: matches-only.
With that said, having two separate layers (each with their own definition query) would get messy in a hurry. If I wanted to add criteria to the def query, I'd need to do it to both layers. As well as any other properties like symbology, labeling, joins, etc.
So that workaround isn't very practical, now that I think about it.