<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>idea Precomputed real-time linear referencing feature class (equivalent to route event layer) in ArcGIS Pro Ideas</title>
    <link>https://community.esri.com/t5/arcgis-pro-ideas/precomputed-real-time-linear-referencing-feature/idi-p/1398239</link>
    <description>&lt;P&gt;ArcGIS Pro 3.2.2; Oracle 18c 10.7.1 EGDB; SDE.ST_GEOMETRY:&lt;/P&gt;&lt;P&gt;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&amp;nbsp;&lt;EM&gt;dynamic segmentation&lt;/EM&gt;,&amp;nbsp;which is&amp;nbsp;computationally intensive (lots of math).&lt;/P&gt;&lt;P&gt;As an alternative, I want a linear referencing line &lt;U&gt;feature class&lt;/U&gt;. A feature class would be orders of magnitude faster than an event layer.&lt;/P&gt;&lt;P&gt;The FC (I will call it #3) would be based on two items, just like a route event layer would be:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Non-spatial event table with EVENT_ID (unique DB index), ASSET_ID, FMEAS, and TMEAS fields, such as a construction projects table.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;There would need to be a trigger-like mechanism in both #1 &amp;amp; #2. Any time rows in 1 or 2 get updated, those edits would need to be synced to #3.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Idea:&lt;/P&gt;&lt;P&gt;Could functionality be added that would precompute a&amp;nbsp;real-time linear referencing feature class? (equivalent to a route event layer)&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description>
    <pubDate>Thu, 21 Mar 2024 02:31:48 GMT</pubDate>
    <dc:creator>Bud</dc:creator>
    <dc:date>2024-03-21T02:31:48Z</dc:date>
    <item>
      <title>Precomputed real-time linear referencing feature class (equivalent to route event layer)</title>
      <link>https://community.esri.com/t5/arcgis-pro-ideas/precomputed-real-time-linear-referencing-feature/idi-p/1398239</link>
      <description>&lt;P&gt;ArcGIS Pro 3.2.2; Oracle 18c 10.7.1 EGDB; SDE.ST_GEOMETRY:&lt;/P&gt;&lt;P&gt;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&amp;nbsp;&lt;EM&gt;dynamic segmentation&lt;/EM&gt;,&amp;nbsp;which is&amp;nbsp;computationally intensive (lots of math).&lt;/P&gt;&lt;P&gt;As an alternative, I want a linear referencing line &lt;U&gt;feature class&lt;/U&gt;. A feature class would be orders of magnitude faster than an event layer.&lt;/P&gt;&lt;P&gt;The FC (I will call it #3) would be based on two items, just like a route event layer would be:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Non-spatial event table with EVENT_ID (unique DB index), ASSET_ID, FMEAS, and TMEAS fields, such as a construction projects table.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;There would need to be a trigger-like mechanism in both #1 &amp;amp; #2. Any time rows in 1 or 2 get updated, those edits would need to be synced to #3.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Idea:&lt;/P&gt;&lt;P&gt;Could functionality be added that would precompute a&amp;nbsp;real-time linear referencing feature class? (equivalent to a route event layer)&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Thu, 21 Mar 2024 02:31:48 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-ideas/precomputed-real-time-linear-referencing-feature/idi-p/1398239</guid>
      <dc:creator>Bud</dc:creator>
      <dc:date>2024-03-21T02:31:48Z</dc:date>
    </item>
    <item>
      <title>Re: Precomputed real-time linear referencing feature class (equivalent to route event layer)</title>
      <link>https://community.esri.com/t5/arcgis-pro-ideas/precomputed-real-time-linear-referencing-feature/idc-p/1398246#M29029</link>
      <description>&lt;P&gt;Attribute rule idea:&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.esri.com/t5/attribute-rules-ideas/sample-script-precomputed-real-time-linear/idi-p/1398245/jump-to/first-unread-message" target="_self"&gt;Sample Script — Precomputed real-time linear referencing FC (equivalent to route event layer)&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 20 Mar 2024 02:31:33 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-ideas/precomputed-real-time-linear-referencing-feature/idc-p/1398246#M29029</guid>
      <dc:creator>Bud</dc:creator>
      <dc:date>2024-03-20T02:31:33Z</dc:date>
    </item>
  </channel>
</rss>

