For the longest part in a multipart polyline, use the line/part's midpoint to get the ID of the closest polygon

1016
9
05-24-2022 02:29 PM
Bud
by
Notable Contributor

I have a multi-part road polyline FC. For the longest part of a given polyline, I want to use the line/part's midpoint to get the WARD_ID of the closest polygon (single-part polygon FC).

  • The WARD polygons aren't topologically clean. There are slight overlaps and gaps. So that's why I want to get the closest polygon -- within a 30m tolerance.

Is there a way to do that operation with geoprocessing tools? 

License level = Advanced.

Thanks.

0 Kudos
9 Replies
JohannesLindner
MVP Frequent Contributor
  • Explode the multipart features
    JohannesLindner_0-1653460160693.png
  • Calculate a new field that tells you whether a singlepart line is the longest part of a multipart feature
    JohannesLindner_1-1653460290263.png
var id = $feature.ORIG_FID
var fs = $featureset
var all_line_parts = Filter(fs, "ORIG_FID = @ID")
if($feature.Shape_Length == Max(all_line_parts, "Shape_Length")) {
    return 1
}
return 0

 

  • select and delete all exploded lines where "LongestLine = 0"
    JohannesLindner_2-1653460393669.png

     

  • Calculate the central point coordinates
    • This is not actually the midpoint.  This is what the tool help says:
    • "This point is the same as the centroid if the centroid is inside the feature, otherwise it is an inner label point."
    • But it's probably the best you're going to get without pretty large code blocks...JohannesLindner_3-1653460466851.png

       

  • Convert to points
    JohannesLindner_4-1653460523749.pngJohannesLindner_5-1653461415185.png
  • export to actual point feature class
    JohannesLindner_6-1653462597650.png
  • Find nearby polygon features

    JohannesLindner_7-1653462651160.png
  •  Join MidPoints to the original Line FC using "OBJECTID = ORIG_FID"
    JohannesLindner_8-1653463053269.png

     

  • Add the polygons to that join, using "MidPoints.NEAR_FID = OBJECTID"
    JohannesLindner_9-1653463151369.png
  • Calculate the PolygonID field
    JohannesLindner_10-1653463286227.png
  • Remove all joins

 

JohannesLindner_11-1653463417063.png

 


Have a great day!
Johannes
DanLee
by Esri Regular Contributor
Esri Regular Contributor

Just want to mention some alternative tools to use:

1.  To get the longest part among the singleparts with the same ORIG_FID, you can use Summary Statistics with MAXIMUM option on Shape_Length, using ORIG_FID as the Case FIeld. Then Add Join back to the singlepart features via ORIG_FID.

2. Once the longest parts have been identified, you can use Feature Vertices To Point with "Midpoint" option to get the midpoints.

As you mentioned the overlaps and gaps, when a midpoint falls inside multiple (overlapping) polygons, Near may return the FID for one of them.  Are you concerned about that?

I am curious about why the roads are in multipart to begin with and why you need to know the closest Ward polygons to each midpoint of the longest part.  Would you mind giving a brief explanation on the real story with some screenshots if possible?  Thanks.  - Dan

0 Kudos
Bud
by
Notable Contributor

Thanks Dan. Regarding your question, "Why are the roads multipart to begin with?"

Answer:

Some of the roads are multi-part due to situations like this:

The road's "Exclusive Right Turn Lane" was deemed to be too short to be it's own asset. So it was merged into it's parent asset as a multipart feature: 

Bud_0-1656199594349.png

(Here's an example photo, although not the same one from the screenshot above: https://i.stack.imgur.com/aiL7W.png)

That decision was made years ago by people other than me and is beyond my control. (It's not possible to change things at this point...there are too many existing dependencies. Splitting the multipart into two single parts would compromise any records that are related. Including an already-integrated work order management system.)

 

The other scenario is:
Multipart features were created by accident. The person who digitized the roads merged two lines together, but didn't realize that a multipart feature was created. 

Bud_1-1656202825359.png

In that case, it might be possible to go back and convert the multiparts to single parts. But it would take a lot of work to review/fix any linear referencing events that are tied to the geometry/M-values of those roads.

 

I've submitted an idea about multiparts here: Prevent multi-part features.

 

Does that answer your first question?

I'll answer your second question about "Why you need to know the closest Ward polygons to each midpoint of the longest part?" in a separate comment. Cheers.

 

 

0 Kudos
DanLee
by Esri Regular Contributor
Esri Regular Contributor

Thank you Bud for explaining the two scenarios for multipart features to be created.

For the mistakenly created multipart features, if you can select them by some attributes without selecting those "sliparound lanes", then you can run Multipart To Singlepart to make them singlepart, each carries ORIG_FID, followed by Unsplit Line using the ORIG_FID as the Dissolve Field to merge them without being multipart. Hopefully you can use the ORIG_FID to join with original features to transfer any lost attributes.  It may be a hassle but necessary.

0 Kudos
DanLee
by Esri Regular Contributor
Esri Regular Contributor

Just FYI, as a post-editing option, you can use Calculate Geometry Attributes to calculate "Part Count" to a field. Any feature getting a value greater than 1 would be a multipart feature.

I look forward to your description on "Why you need to know the closest Ward polygons to each midpoint of the longest part?", Bud.  🙂

0 Kudos
Bud
by
Notable Contributor

Question:

"Why you need to know the closest Ward polygons to each midpoint of the longest part?"

Bud_0-1656376627418.png


Answer:

I want to be able to control what part of a given multi-part line was used to get the Ward number.

  • So, for Road 123 (multi-part), I want to use the main part of the road (the longest part) to get the Ward number, since that's the part of the road I care about. I don't want to use the turning lane to determine the ward number, since it's just a secondary portion of the road, and technically falls in a different ward.
  • Likewise, I want to use the midpoint of the main part of the road, because I think the midpoint is most likely to be in the correct ward. Whereas, say, the startpoint of the smaller part is in a different ward. 

In some cases, simply using the midpoint of the entire line might work. Maybe the midpoint would have still fallen on the main part of the road, and within the correct ward. But I didn't want to assume that it would always work like that. And with GP tools like Feature Vertices To Points, it actually creates a midpoint for each part, not a single midpoint for the entire line. That's not what I want. So when I saw that behavior, I got a bit nervous and wanted to find a way to completely control how things behaved.

Does that answer your question?

 

(Side note: I don't have control over the Ward layer/topological correctness.)

 

0 Kudos
DanLee
by Esri Regular Contributor
Esri Regular Contributor

Thanks! I understand now.

Feature Vertices To Points generates MID point per part for a reason.  Parts may not be connected in one feature. So it doesn't make sense to find midpoint among disconnected parts.

You can try Feature To Point with the "Inside" option. It generates one point per feature on one of the parts.

Bud
by
Notable Contributor

@DanLee 

As you suggested, Feature To Point with the "Inside" option worked well thanks.

It seems to have placed the midpoint along the entire length of the line (all parts considered), which is what I wanted. It didn't just use the midpoint of a single part...such as the the first part it found (good).

Bud_2-1659107792314.png

(The line in the screenshot is composed of multiple parts. That's incorrect/unnecessary, but beyond my control.)

Bud_0-1659107359668.png

 

Thanks for the tip about that GP tool.

0 Kudos
Bud
by
Notable Contributor

Actually, on closer inspection, I don't think it placed the point halfway along the line. Maybe it did something else, like place the point in the middle of the envelope. Then snap the point to the line, to satisfy the "Inside" criteria.

0 Kudos