nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Locate Features Along Routes - Linear Input Features

MilesTautscher

Hi,

I have linear routes with M values (pipelines) and a linear layer of rivers. I want to use Locate Features Along Route to determine the location where the rivers and pipelines intersect.

How come I have to set a search radius? The rivers and pipelines clearly intersect at many locations. That's all I want, I'm not concerned with areas where they come close.

Even when I set a search radius (one metre), it returns far fewer values than I expect. And of course, each record has a "from" and "to" value, neither of which actually represent the intersection.

PS: I'm running 10.1.

Thanks,

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

DanLee

I have checked with our linear referencing expert and I confirm that the tool doesn't support the analysis of crossing-lines for intersections. It would require a new option for the specific analysis and output (of course without affecting existing workflows); our development priority depends on how high the demand is. You may submit an enhancement request with Esri Support or enter the idea at:
http://ideas.arcgis.com/

The two-step workaround I mentioned earlier should get the intersection points for your use of the Locate Feature Along Route tool. Hope that helps.

RichardFairhurst

If conflation technically means something other than what the Locate Features Along Route tool currently does for polylines, that makes no difference to me. The primary point I want to make is that tool as it is now designed has no bug. If the current behavior was a bug it would have been reported and fixed decades ago.

The easiest way to create a bug is to alter an established behavior of a legitimate tool that has been used for decades so that it suddenly performs new behaviors without user permission. Changes to well established behaviors that users have relied on for decades should only occur by making new options available that only take effect after the user explicitly changes his script, model or workflow to take advantage of them. If ESRI had always carried that out with each new release, the vast majority of bug reports would never have been reported. (How many of us would have checked the box to make tables all appear in one window or wanted that as the default if we had been given the choice?)

RichardFairhurst

Richard - What you're saying makes sense, but then the tool seems odd.

ESRI's definition of Locate Features Along Routes:

"Computes the intersection of input features (point, line, or polygon) and route features and writes the route and measure information to a new event table." Source.

Your description is a little over my head. The way I interpret it is: the tool takes two parallel(ish) lines and joins their attributes, but only within certain points (defined by your search radius). Which to me just sounds like a spatial join, except with measure values.

Points only create point events and lines only create line events with this tool. That difference is why the help explains that there is a difference in how the tolerance is interpreted for these two feature types. Numeric tolerance used with points means that only a point event is found and created and cluster tolerance used with lines means at least two end points must be found or no feature event is written.

The tool is more than a spatial join, because it is actually capable of creating multiple smaller line segments from a single source event line wherever the event line has some portions of its length within the Route tolerance. The line will have no event written where it does not intersect on some portions of its full length. Spatial Join never creates any new line segment shapes that are not an exact duplicate of the target feature, but Locate Features Along Routes creates new line shape events that may be different from the input lines or the routes, just like Intersect with the polyline output type. Anyway, this behavior is exactly what I want when doing line conflation.

If I wanted intersections I would use Intersect polylines with the points output option and then use those points as the point event for Located Features Along Routes as you found you had to do. I do not deny that a similar set of options could let this tool do the same thing, but it is essential that it is only offered as an option like they do with the Intersect tool to let me explicitly choose to get point outputs or line outputs. The current tool behavior cannot be altered without a new setting for end user control over the behavior, because people like me would be upset if they could no longer use the tool exactly as it is currently designed and it suddenly changed to a new behavior that breaks our workflows.

Not necessarily. The tool has enough functionality to recognize if you are choosing points, lines, or polygons as the intersecting features, and greys out the appropriate parameters accordingly. At most, there could just be another check box that says something like "Include intersecting points in output table" (the default can be off so as to conform to the main purpose of the tool). It could still copy the attributes over, as well as the From-Measure and To-Measure (if I set a search radius)...I just need to be able to tell it that I need one extra box.

It does not have enough functionality to change its decades old behavior without breaking workflows. The new option you mention would have to be added for me to be willing to let you get the output you want, since an output like what you are seeking would break my workflows. The current output cannot be regarded as a bug that must by default be overridden because it serves a legitimate purpose for users that requested the tool be developed in the first place.

Alternatively if I set my search radius to 0, it could recognize that I'm only looking for intersects. Yes I know this defies physical logic since an intersection technically exists in space but still.

No, a search radius of 0 means to me that the line and the route must be an exact point for point match along a line segment in order to create an event. That is what a 0 tolerance means for the Intersect tool when polylines are intersected with polylines, unless you explicitly choose the option to create a point output type. I would have my workflows break if suddenly this tool only created point events when I specified a 0 tolerance without asking me for permission to do that. My workflow requirements are every bit as legitimate as yours. But users like me have the prior claim to this tool's behavior, since we have created workflows based on its current behavior over the course of all of the decades it has existed. Therefore, by default it could only change behavior if a new option was consciously chosen, and without that our scripts and models must continue to behave as they do now for all possible settings that the tool currently supports.

Post your request on the Ideas site, but be sure to word your request as an enhancement involving an additional option that expands the tool's functionality, not as though this tool has a bug in its existing behavior. It has no bug. If the current behavior is not respected, any attempt to "fix" it by altering the behavior of the current settings will only create a bug, not fix a bug.

DanLee

Hi Miles,

I think you have the right analysis and understanding of the problem. Regardless what tools (Intersect, Select By Location, Spatial Join, or Locate Features Along Route) have the option for returning intersections, the underlying computation for intersections should be the same. I am not an expert for LR, but your expectation for LFAR tool seems reasonable to me. When you expect a tool to return intersection points, you certainly can use other tools to verify results. If your pipelines and rivers actually cross or touch within the feature's XY Tolerance (see properties of the feature class), at least the Intersect tool should find all the intersection points; the duplicate points are by design; the Delete Identical tool should take care of them. Could you do the following:
1. Check what the XY Tolerance values are on both inputs (pipelines and rivers).
2. Run Intersect tool, followed by Delete Identical tool. Check if the resulting points are expected. If not, you can share some repro sample data; we can investigate.

Entering 0 for search radius may mean different things in different tools and doesn't always mean 0 is used; some tools use the XY Tolerance internally, other tools may treat it as an option for certain analysis. Generally for lines to be intersecting or touching they need to be within the XY Tolerance to each other. It won't make a difference if you try any value smaller than the XY Tolerance.

The tools with an "intersect" option I mentioned above are simply based on a search radius. This is not in the nature of conflation that I know of. Conflation typically refers to matching two spatially overlapping but shifted datasets from different sources (e.g. State DOT roads vs. local government maintained roads); you wish to spatially align one towards the more accurate one or to transfer attribute from one source to the other. Feature matching - the core of conflation - is not only based on proximity but more critically based on topological structures and similar patterns. As far as I know, the LFAR tool, as it is now, does not operate as a conflation tool. I just want to clarify that.

MilesTautscher

Richard - What you're saying makes sense, but then the tool seems odd.

It is not an intersect tool at all really with lines,

ESRI's definition of Locate Features Along Routes:

"Computes the intersection of input features (point, line, or polygon) and route features and writes the route and measure information to a new event table." Source.

it is a conflation tool. Conflation looks at more than just an intersection and is designed to ignore intersecting lines. Instead it attempts to only register lines that could be interpreted as parallel lines within the tolerance distance. It is a useful tool for aligning two line networks that are not quite aligned with each other, which a common need for transportation oriented folk (who had the initial influence on the LR toolset).

Your description is a little over my head. The way I interpret it is: the tool takes two parallel(ish) lines and joins their attributes, but only within certain points (defined by your search radius). Which to me just sounds like a spatial join, except with measure values.

In any case, it would break the current tool if they did what you want from my perspective. To do what you want a set of choices that could let me not do what you want to do would have to be incorporated into the tool so it retains its current behavior. Otherwise, you need a new tool.

Not necessarily. The tool has enough functionality to recognize if you are choosing points, lines, or polygons as the intersecting features, and greys out the appropriate parameters accordingly. At most, there could just be another check box that says something like "Include intersecting points in output table" (the default can be off so as to conform to the main purpose of the tool). It could still copy the attributes over, as well as the From-Measure and To-Measure (if I set a search radius)...I just need to be able to tell it that I need one extra box.

Alternatively if I set my search radius to 0, it could recognize that I'm only looking for intersects. Yes I know this defies physical logic since an intersection technically exists in space but still.

In any case having to use a multistep geoprocessing process means you are joining the real world of GIS experts. Everything worth doing is multistep and I gave up complaining about it years ago.

Lol.

MilesTautscher

I originally tired a search tolerance of 0, and it gave me no results.

So I tried a search tolerance of 1 millimetre, still no results.

So I tried a search tolerance of 1 metre, and I got 18 results - far fewer than I should have.

HeatherMcCracken

Can you try using a search tolerance of 0?
Does this give you better results?

We recommend using the smallest search tolerance possible, as for lines it will also be used as a cluster tolerance

From the parameter help
"If the input features are lines, the search tolerance is really a cluster tolerance, which is a numeric value representing the maximum tolerated distance between the input lines and the target routes."

Let me know how it goes.
Thanks,
Heather

RichardFairhurst

That's what I ended up doing (and then using Locate Features Along Routes with my point layer). The only problem with that is:

- It's an extra step
- When I ran intersect, it came up with 1024 points. When I ran Locate Features on those points, it came up with 1117 locations. Now I have to investigate those extra 100 points to see what's up, because in no situation should one point fall on two different pipelines.

I've used Locate Features Along Routes with polygons and it works like a charm. To not have it work with polylines seems like a glitch.

It is not a glitch. It is not an intersect tool at all really with lines, it is a conflation tool. Conflation looks at more than just an intersection and is designed to ignore intersecting lines. Instead it attempts to only register lines that could be interpreted as parallel lines within the tolerance distance. It is a useful tool for aligning two line networks that are not quite aligned with each other, which a common need for transportation oriented folk (who had the initial influence on the LR toolset).

In any case, it would break the current tool if they did what you want from my perspective. To do what you want a set of choices that could let me not do what you want to do would have to be incorporated into the tool so it retains its current behavior. Otherwise, you need a new tool. In any case having to use a multistep geoprocessing process means you are joining the real world of GIS experts. Everything worth doing is multistep and I gave up complaining about it years ago.

DanLee

Oh Intersect tool with POINT output creates duplicated points, I think. You can use Delete Identical tool to remove duplicated points so each location has only one point.

MilesTautscher

That's what I ended up doing (and then using Locate Features Along Routes with my point layer). The only problem with that is:

- It's an extra step
- When I ran intersect, it came up with 1024 points. When I ran Locate Features on those points, it came up with 1117 locations. Now I have to investigate those extra 100 points to see what's up, because in no situation should one point fall on two different pipelines.

I've used Locate Features Along Routes with polygons and it works like a charm. To not have it work with polylines seems like a glitch.

DanLee

Can't you just use the Intersect tool to find the intersection point - specify output type POINT between pipelines and rivers?

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.