Length-based event layer: Linear referencing event layer that plots events along lines using the cumulative length of the line, not M-values

[Bud]

(edited for clarity)

It would help if there were an Event Layer type in ArcGIS Pro that is the following:
Length-based event layer: A linear referencing event layer that plots events along lines using the cumulative length of the line, not M-values.

Reason: Our M-values are always just set to the cumulative length of the line anyway. Never a different value. So we don’t need M-values.
Right now, every time I edit the geometry of a line, I need to redefine/re-populate the M-values so that they're set to the cumulative length of the line. That's redundant, error-prone, and a poor use of time.

[DonaldRees]

Hi @Bud,

I'm not really understanding your request. If you want the cumulative length of the line you can export the route event source layer to a feature class. You can also create routes based on the length of the line and create an event table to display measures based on the m-values. However, if you change the geometry of the linear feature, then you would need to change the underlying m-values. Could you give some details of what your trying to achieve and the use case for doing so?

Donald

[Bud]

@DonaldRees 

So, I have a Roads feature class (not M-enabled, at least, that would be ideal). And I have an event table with F_MEAS and T_MEAS columns. Most of the event records pertain to the whole road. A small percentage of the events pertain to a portion of the road, which is why we need to use linear referencing.

Right now, whenever we modify the geometry of a road, we need to remember to redefine the M-values via the Set as distance editing tool (we set the value in that tool to 0, which means the cumulative length of the line will be used as the M-values). That's a pain and is very error prone. People rarely remember to redefine the M-values after editing the geometry of roads. It's especially painful because we know the information is technically already present in the geometry via math: the cumulative length of the line. We don't want to manually maintain the cumulative length of the line in the M-values too. It's redundant.

(And of course, after editing the geometry of a road, we also need to go and manually check on the events in the event table too. And manually adjust the F_MEAS and T_MEAS values if needed. But that's expected/just part of doing business.)

This applies to other linear asset types too too. Not just roads.
-Sidewalks
-Trails
-Cycling lanes
-Sewers

I know a lot of organizations store values in the M-values that aren't the cumulative length of the line. Such as organizations that maintain lengthy highways and pipelines. But there's also a bunch of us who just treat events in event tables as linear measurements/records along a road. Kind of like "Stations" in a road construction drawing.

There's always been a bit of a communication barrier between us users and Esri on this topic. Not sure why. We have the same communication challenges with the Roads & Highways team too.

But long story short, I never want to populate an M-value ever again. I want to use the length of the line instead when creating an event layer on an event table.

Related: https://community.esri.com/t5/data-management-questions/route-layers-using-xy-instead-of-m-values/m-...

[DonaldRees]

@Bud thank you. I think I'm getting what the request is and please correct me if I'm wrong but the request I see here is twofold. First is to create some type of feature that will allow a user to set the route behavior that if you adjust the geometry of the linear feature then the m-value will automatically update to match the change. Second is to have the same change propagate to the associated event tables and update the m-values.

I would recommend checking out Roads & Highways product if you're looking for an automatic configuration. I believe what they have is called event behavior that matches the above request. You can sort of get what you want now with the core linear referencing tools but like you said there is a manual piece. I do have an alternative suggestion to the define line tool and it depends on if you're in an enterprise geodatabase or a file/mobile geodatabase. What you could also do is generate the route events as a standalone feature class before any geometry updates and then after completing the geometry updates run the create routes feature class using length of features followed by locate features along routes against the new route feature class. This would would result in an updated route feature class with m-values based on the new geometry and an event table with updated m-values. While this would create new route feature classes or versions to manage, this should help address the concern you had about the manual process of the define line portion tool.

[Bud]

@DonaldRees Thanks for your comments. Your part one is close, but not quite what I'm asking for in this particular idea. Your part two is not required; that event editing/updating work would be done manually.

We've actually already met with the Roads & Highways team a couple of times. They said the Roads & Highways product wasn't the right fit.

Here's a different way of explaining what we're looking for.

Currently, there are two existing event layer types in ArcGIS Pro:
1. XY Event Layer
2. Route Event Layer (uses a M-enabled FC)

I'm asking for a third type of event layer:
3. Length-based event layer (uses a FC that isn't M-enabled)
Instead of using M-values stored in vertices, it uses trigonometry to plot events along lines. 

It would use logic similar to the segmentAlongLine ArcPy method. That ArcPy method doesn't use M-values. It uses trigonometry to plot a polyline between start and end measures. Check out this unrelated tool from @SeanLim and @DanLee: Shrink Line GP Tool. If you look at the Python script behind that tool, you'll see that it plots lines on features that aren't M-enabled, using the segmentAlongLine ArcPy method.

I imagine the segmentAlongLine ArcPy method uses an underlying ArcObjects interface that plots lines along features that aren't M-enabled. I can't find the docs right now but I'm sure it's there. What I'm asking for is a new event layer type. It would use ArcObjects to plot events along lines using a feature class that isn't M-enabled.

I've actually done that very thing, but using SQL in a query layer (Oracle EGDB).
Using trigonometry, I generated ST_Geometry features -- partial lines that represented the events. So I know what I'm asking for is logistically and mathematically possible. No M-values needed.
The only problem with the SQL approach was that the OOTB ST_Geometry functions were too slow (a well-known problem), so the query layer performance was poor. But if it were done using ArcObjects in an event layer in ArcGIS Pro (on the client-side in RAM, just like other event layers), then I am quite sure that it would be fast, just like Route Event Layers.
It could also be optimized in this scenario: if the event  spans the entire line (F_MEAS is 0 and T_MEAS is >= the line length) then just use the line geometry from the FC instead of plotting the event along the line. That might improve performance. As mentioned earlier, most of our events pertain to the entire line. It's only a small portion of them that only pertain to a portion of the line.

[TanuHoque]

@Bud 

Please correct me if I'm wrong.

In summary, you are basically asking Make Route Event Layout gp tool to take a non-M-aware layer/feature-class as a valid input for its Input Route Features parameter.

When a layer doesn't have M, it should use line features lengths instead for event calculation.

Currently, the tool throws validation error, when you add a layer/feature-class that is not m-aware.

[Bud]

@TanuHoque Yes, that's correct. Thanks for providing that alternative explanation.

[TanuHoque]

thanks @Bud 

[DonaldRees]

@Bud, thank you for taking the time to help us understand the use case behind this idea. We're interested to know if others would find this enhancement helpful in their workflows as well. I'll switch the idea back to 'Open' from 'Needs Clarification' to allow the idea to gain support.