Assigning names to contiguous line segments

[JohnWarden]

I have hundreds of polylines  across the US, with each polyline consisting of 10 to 100 segments. One segment in each line has a name field. I want to assign the name in a given segment to all other segments in the same line. I can't use a spatial join and assign the name of the closest segment, as it may assign the name from a nearby line, not the line segment in the same line. I can use a spatial join and assign the name of touching segments, but I would have to repeat this process 100 times if a line has 100 segments. Any suggestions on how to make this process quicker?

[DarrenWiens2]

1.) Dissolve lines using UNSPLIT_LINES

2.) Select the original line segments containing names.

3.) Spatial Join named lines to dissolved lines.

You will run into problems where there are T-intersections between differently named lines, but there is no way around it, AFAIK.

[JohnWarden]

Thanks for all the suggestions. Unfortunately, none of the ones I've tried work. I don't know Python so I'm leaving those out, but neither Dissolve, Merge or Unsplit have done anything. I tried all three on a single line consisting of 46 line segments that had no intersecting lines, but it did not combine the multiple segments into a single line. The output files all had 46 rows in the table.

[RichardFairhurst · Accepted solution]

Most likely you have bad topology control and your tolerance is too precise for the level of accuracy that was maintained during the creation of this data.  Unless line ends precisely meet they will not merge together the way you want.

If you have a Standard license or above you could try the Snap tool in the Editor toolset to try to get the ends to snap together.  You should just use the Ends option to snap the line ends only.  This tool directly modifies your original lines, so make a backup in case things go wrong and process it in an Editor session so you can undo your attempts and try different tolerances.  Once your lines are topologically accurate to the tolerance setting of your data, the Dissolve ends option should work.

Additionally, be sure you leave all of the Dissolve fields unchecked.  You must not allow any attributes to affect the dissolve.  Only summary statistics fields should be used.  If you do not include any summary statistics fields your output should have no fields other than ObjectID and Shape.

[JohnWarden]

This doesn't work either.

I went back to my original shapefile and selected one segment in a line, did Select by Location/add to selected features; selected the line as the target layer as well as the source layer, and used Touch the Boundary as the selection method.

This process selected the adjacent line segments. I ran it several times and each time it added the adjacent segments to the selected features. Doesn't this mean the ends of the line segments are touching?

[RichardFairhurst]

No, that only means they touch the edge.  Look at the sketch properties of two lines that should meet end to end.  If they have the exact same coordinates in the matching ends of the line then they would meet end to end.  If they are off by a fractional amount, they don't meet.

Also, did you confirm that no attributes were generated by the Dissolve tool other than the ObjectID and Shape?  If you had any other field in the output that is not a summary field (Sum, Mean, Min, Max, etc) that will prevent lines that touch end to end from connecting if the value in the other fields do not exactly match.

Dissolve with the Dissovle_Lines option and no attributes should merge everything together into one feature, not multiple features if done properly.

Screenshot your Dissolve setting screen if you want to let us verify that all of the inputs are correct.

Here are my results on a topologically correct line layer (I use an actual topology layer with rules that identify dangles and line ends touching the interior of another line as errors to ensure that only cul-de-sacs and stub roads are allowed to not meet end to end) with different Dissolve tool inputs.

Original Input lines: 2496 line features.

Dissolve with no attributes, no summary fields, create multipart features, and using the Dissolve_Lines option: 1 line feature created.  When the create multipart features option was unchecked the process failed to complete.

Dissolve with no attributes, no summary fields, create multipart features,  and using the Unsplit_Lines option:  2,039 line features.  Separate line features are created at every intersection of 3 or more lines.  The unsplit lines option only works if just two lines meet end to end when no attributes are considered.  The create multipart feature option had no effect on the unsplit lines process.

Dissolve using a Street Name attribute to control the dissolve, no summary fields, create multipart features, and using the Dissolve_Lines option:  980 line features were created.  Only one line feature was created for each unique street name.  The create multipart feature option had an effect on the dissolve process and created 18 additional features when the multipart option was unchecked for a total of 998 features.

Dissolve using a Street Name attribute to control the dissolve, no summary fields, create multipart features, and using the Unsplit_Lines option:  998 line features were created.  There is one line minimum for each unique street name, but where any lines did not meet end to end additional features with the same street name were created for each line gap.  Therefore only 18 gaps existed in my line data when the street name was considered.  Intersecting roads with other street names had no effect on the unsplit process.  The create multipart feature option had no effect on the unsplit lines process.  However, the results were the same whether I unchecked the multipart feature option and used Dissolve_Lines or I used the Unsplit_Lines option.

[JohnWarden]

I re-ran your suggestions and it appeared not to work. However, when I zoomed in very tight on one of the line segments (which is from a file of railroads) I think I discovered the problem. The method you suggested (Snap, then Unsplit) appears to work fine, except when there is a switch or siding on the rail line. A screen capture is shown below.

After running the Snap and Unsplit tools, contiguous line segments with no switches or sidings on them were joined together end-to-end. However, if there is a switch or siding the end-to-end join does not occur. In the screen capture below there are three line segments: the two long segments and the smaller side track. So...now, any suggestions on how to proceed? I don't need the siding or switch tracks so if they could be deleted that would be fine, but I'm not sure how to isolate them for deletion or exclude them from any geoprocessing functions.

While the screen capture illustrates a dead-end siding, some are double ended, with both ends joining back into the main rail line.

[RichardFairhurst]

Unless you have an attribute to distinguish sidings from mainline railroad tracks there is no way to make that distinction other than to select the lines and encode them manually or delete the unwanted lines.  All 3+ way line intersections like you showed in your picture will prevent your line from unsplitting until you can separate the mainline railroads from the sidings.

I would normally assign a subtype to the sidings and mainline railroad lines so I could select just the mainline railroad lines and use that selection with the Dissolve tool.  The subtype approach is non-destructive so that you can easily recover in case you find out you need to restore a line you mistakenly selected and incorrectly categorized, whereas if you delete lines recovery may not be possible after saving the layer,  As long as only the mainline railroad lines are selected the dissolve will ignore the sidings and unsplit the mainline railroads the way you want them.  After doing your best to do the mainline selection, unsplit the lines, assign railroad names and retest for continuity by looking for lines that still had unassigned names.  That will show you where two or more mainline railroads actually intersect, which you have to process manually no matter what technique you use, or it will show where you missed a siding.

You can always use the geoprocessing results tab to easily open a tool you ran previously so that you can rerun the tool without having to reconfigure it.  So redoing the steps in an iterative approach is not that hard.

Frankly, from my perspective 3500 features is well within my tolerance for assigning a two category subtype attribute manually and I see no benefit for looking for an automated approach to avoid that step, unless I knew that I would have to repeat that process more than once.  Since that relatively minimal level of effort would let me automatically assign 100s of unique railway names I would consider that a very acceptable trade-off.

[DarrenWiens2]

This thread is getting too long to read, so sorry if this has been mentioned and/or ruled out. You may be able to save yourself some time by Merging (that is, edit merge) or Dissolving all lines into one massive multipart polygon, then Exploding or running Multipart to Singlepart to separate into touching clusters. Finally, Spatial Join named segments to clusters. You will have to manually inspect clusters that should have more than one name.

[JohnWarden]

Thanks to all for the help.

Darren, I was able to merge everything into one massive multipart polygon as you suggested, but the Explode and Multipart-to-singlepart tools just returned me to my starting point.

Between you and Richard I was able to make some headway, but the switch/siding problem discussed above derailed (ouch) any further efforts to accomplish what I wanted using a few commands. I'll have to go down the manual track (ouch, again) to deal with the switch/siding problem.

Consider this issue closed...and again, thanks for the ideas and your time.