ArcGIS Pro 3.2.2; Oracle 18c 10.7.1 EGDB; SDE.ST_GEOMETRY:
Route event layers (linear referencing) are slow to draw in the map. That’s because the non-spatial event records need to be placed/drawn along portions of lines via dynamic segmentation, which is computationally intensive (lots of math).
As an alternative, I want a linear referencing line feature class. A feature class would be orders of magnitude faster than an event layer.
The FC (I will call it #3) would be based on two items, just like a route event layer would be:
- Non-spatial event table with EVENT_ID (unique DB index), ASSET_ID, FMEAS, and TMEAS fields, such as a construction projects table.
- M-enabled line feature class, such as a roads feature class (ASSET_ID field has a unique DB index). Some of the lines are multi-part and/or have true curves/arcs.
There would need to be a trigger-like mechanism in both #1 & #2. Any time rows in 1 or 2 get updated, those edits would need to be synced to #3.
I don’t want to export a route event layer to a static FC because it would become out of date. Even syncing nightly or hourly (via a scheduled task, etc.) would not be enough. During peak budget season, many edits are being made throughout the day to #1 (and some geometry edits to #2 as well) that need to be immediately reflected by #3 in maps in real time, with no delay.
I don’t want to manually refresh #3 with a GP tool or model either. That would add too much complexity and risk to a process that is already complicated and messy. I can’t rely on users remembering to run a tool after every single edit. That’s unrealistic.
Idea:
Could functionality be added that would precompute a real-time linear referencing feature class? (equivalent to a route event layer)
The FC would be read-only. Edits would be made to #1 and #2, not #3. That isn’t a problem since route event layers aren’t fully editable in ArcGIS Pro anyway. We can’t delete rows or create new rows (?) via the route event layer attribute table; we can only edit existing rows. So our current process is to make edits using #1 in the standalone table, not in the route event layer. So, if #3 isn’t editable, that wouldn’t change our workflow.
A materialized view (Oracle) wouldn’t be practical due to: ST_GEOMETRY not being supported by materialized views, limited ST_GEOMETRY SQL functions (no linear referencing functions), and the math being too complicated to code by hand in PL/SQL.
