Strange behaviour with "Locate Features Along Routes"

[HåvardMoe]

I'm having some strange behaviour with the "Locate Features Along Routes" function with ArcGIS 10.1.

I have:

• One feature class with line geometry with an attribute I want to create linear events from.
• 45 feature classes with the defined routes

I want:

• Event tables per route

To create my events I iterate over the routes and create one event table per route, using the arcpy.LocateFeaturesAlongRoutes_lr() function.

My initial test on a couple of the routes worked fine, but when I attempt to run though all of them I get this:

Executing: LocateFeaturesAlongRoutes C:\Work\FGDB.gdb\Features C:\Work\FGDB.gdb\Route1 RID "1 Meters" C:\Work\FGDB.gdb\EventTable "RID LINE FromM ToM" FIRST DISTANCE ZERO FIELDS M_DIRECTON

Start Time: Thu Feb 19 14:41:01 2015

ERROR 999999: Error executing function.

The table was not found. [EventTable]

Failed to execute (LocateFeaturesAlongRoutes).

Failed at Thu Feb 19 14:41:02 2015 (Elapsed Time: 1,00 seconds)

I run through the database (just added some exception handling to list the ones with errors) and find that 16 out of the 45 routes give this error, while the rest go through ok.

I wondered if it could be my script, but the same routes fail when I use the tool in ArcMap.

I've checked the input data, and can't really find what the issue is with the 16 problem routes. Some of them are short and easy (one feature), others of them are longer and more complex. All of the routes have measures set, with nothing particular shoving up using the Route Measure Anomalies display.

Anyone else seen something like this?

[XanderBakker]

Are you willing to share some of the data that produce the error?

[HåvardMoe]

I'll try, if it can help. Attached is a zipped file geodatabase with a subset of feature classes. The feature class "Attribute" hold geometries with the single attribute field I want an event table for (i.e. the "Input Features" for the function). The feature classes ADLB, NSIB and SORB are routes with a single field holding the route ID. SORB is going through fine, the others are not:

[XanderBakker]

Can you list the inputs parameters that you have used?

I just did a test with the one that should work and it took almost forever (>1 hour) to complete...

[XanderBakker]

When want to locate line features along a route you obtain the route ID and the M from and M to values of the route. In your case the line feature coincides with the route and your features have a large number of points (how was this line obtained, and do you need that precision for this analysis?). This results in long processing times, but I guess should not be the reason to collapse the process.

In case the line segment only uses 1 route, it is easier to evaluate the start and end point of the line feature, This would make the process a lot easier to process (seconds instead of hours). I becomes more complex in case the line feature needs to use a combination of routes. However, this should be possible to resolve, when the nodes of the route are used to split the line feature.

[RichardFairhurst]

I fully agree with Xander that you should first analyze the end points of you lines that overlay each route to do a quick level analysis.  Point event tables can be sorted, duplicated, and then joined in such a way that two end points of a line can be transformed into a line event table in about 4 or 5 steps.  Then do more complex geoprocessing for lines that did not fall within a single route.

I frankly do not trust the line overlay of this tool.  It will always fail to match the segments if your routes or your input lines have true curves in them (it fails without an error, but just does not include any portion of true curves in the line events generated).  Convert to shapefile to get rid of such curves if you intend to do line on line overlays.  For point on line overlays, true curves in the routes do not cause a problem.

[HåvardMoe]

The routes and the line features are based on the same line geometries. The original data are very segmented, and we have done a job tidying up this to define the routes. The data had some attributes that we wanted to create event tables for.

I first tried running this on the big route feature class I have containing all routes vs. the input feature class and ended in hours of prosessing time. Based on this I set out to split up the job to run per route - hence the split of each route as separate feature classes and a script to iterate them. Running this script I complete the non-problematic 29 routes in little over 3 minutes, so I don't think prosessing time is the issue here... 

There should be no true curves in the data.

[XanderBakker]

Thanks for the additional explanation. I will have another look.

[HåvardMoe]

The parameters I use are like this:

This ran through the route that should work in a few seconds (22 sec on my PC last run).

[XanderBakker]

I did another run and had a similar processing time (around  25 seconds) and the other two resulted in the same error as you encountered. When I converted the result back to route events, I noticed that the result does not include the entire route. There are two parts where the route event is not created. The largest is shown below.

However, this does not explain in any way why for the other parts the error occurs.

I will have to look into the data with more detail (especially the M values) to see if that may be the reason. The alternative would be to create a python script that does this analysis without using the tool.

BTW the other missing part is located here: