How to quickly "snap" all lines together in a subdivision?

1547
13
01-19-2023 03:35 PM
AndrewWallick
Occasional Contributor

I have a subdivision I just created, but realized the lines came very close, but did not snap to each other. Is there a way to quickly select the subdivision lines and run a tool to make them all snap together (with a certain tolerance)?

My solution for the moment is to go through each one and use the extend tool on them, but that's pretty tedious.

Here I'm zoomed in to 1:0.04 and you can see the lines are not actually connected:

AndrewWallick_1-1674171197166.png

 

13 Replies
AmirBar-Maor
Esri Regular Contributor

@AndrewWallick 

We have an idea to auto-snap line endpoint to a parcel point or another line extremity if within a given tolerance and if the line is 'COGO-enabled'.

This idea is similar 

JasonBessert
New Contributor III

Amir, on this topic, is there benefit to using the "Must not have Dangles" ready to use attribute rule?

I've been trying to implement it, but I can't get the Error Inspector to find dangles when I evaluate the rules in a test case.  Just wondering if you have been able to get it to work effectively in your case.  We are working with clients who import a lot of cad data with poor snapping in the DWG output of subdivisions and would like to validate to find dangles in preparation and staging before adding it to a fabric.

I have a support case open with ESRI right now #03245768 on that matter.

AmirBar-Maor
Esri Regular Contributor

@JasonBessert If you are referring to the "Ready To Use Rules" those are the Data Reviewer Extension rules.

If your customer has a license to that extension they can use that when performing Data Reviewer evaluation workflows. You might need to take a Data Reviewer training to understand how to use the extension. Unlike geodatabase topology, Data Reviewer will not change the source data (cracking and clustering) when evaluating the rules.

AmirBarMaor_0-1674604580921.png

 

0 Kudos
JasonBessert
New Contributor III

Thanks Amir, we are fully licensed on data reviewer and are working with ESRI on the support case I mentioned above, where the "Find Dangles" reviewer check is misbehaving.  It's finding errors where there are no errors, yet failing to find errors where it is supposed to (real dangles).

We're looking for a solution that evaluates for dangles, wihthout the behavior of topology and the cracking that comes with it, and the find dangles check would be the best candidate for this, but not with the behavior I'm seeing lately that prompted me to report a bug. 

I also used to apply @FrankConkling's solution very extensively in ArcMap, by planarizing lines with a high-enough cluster tolerance to have a magnetic effect on forcing dangles to snap together, but I've noticed in Pro that you have to be very careful with COGO enabled lines, since planarizing with a tolerance set too high alters the COGO attributes.  Do you know if there is a way to configure the behavior of Planarize in Pro to not update the COGO?

Thanks as always!

0 Kudos
FrankConkling
New Contributor III

Jason,

Unfortunately, at the moment there is no way to prevent this.  However, it would be a great idea to include the option on the pane, similar to the option on the Line Intersection tool. (See screenshot)

Frank Conkling - Panda Consulting

JasonBessert
New Contributor III

This I would agree with 100%, @FrankConkling .  The added automation with Pro has a lot of benefits, yet if a user is not careful, they may corrupt the COGO if the automation recalculates the COGO from the subtle geometry changes the application needs to make to cling the lines together at their vertices.  Not sure why ESRI left out that parameter/option to the planarize tool when it is available with other tools.

As of now, I'm not too thrilled about the planarize tool to secure lines together.  If the cluster tolerance is too low, it will not clean all the dangles.  But if a user sets it too high to increase the likelihood of full snapping, the COGO attributes are altered from their entered values from recorded documents.

0 Kudos
TimHodson
Esri Contributor

Hi Frank and Jason,

What you describe is a bug, and is not the intended design. Thank you for reporting it. When using planarize, the COGO distances are recomputed when the lines are split; in these cases the existing COGO attributes get re-proportioned, and the COGO Type is then set to "Computed" on the resulting shorter lines. For the cases where planarize is snapping line ends together and the lines are not getting split, then the COGO distances should not be getting updated.

Instead of using Planarize to do this snapping, you could instead use the GP Snap tool on the line selection, use the End snapping as the snap type, and use a small tolerance. In my tests of this it seems to be an effective solution. Example something like the following:

TimHodson_0-1674752130715.png

Does this work to solve the problem?

-Tim

 

FrankConkling
New Contributor III

Tim,

Thanks for looking into this and the snap tool is a good workaround.I definitely do not recommend that the user use the planarize the lines if the "gap" is greater than about twice the cluster tolerance of the topology.

It would be nice to have this function built into the tool (I know that you are not on the edit team) instead of having to use a separate geoprocessing tool. Intuitively, editors are more apt to use a built in function or edit tool rather than using a geoprocessing tool.

Frank Conkling - Panda Consulting

0 Kudos
JasonBessert
New Contributor III

Thanks Tim,

As always, you have a keen way of showing us the light.  

The snap tool would be a very viable candidate to this workflow of 'gripping' disconnected lines together.  And I was highly interested in this thread because I'm looking for a way to ensure snapping and validate the snapping (to make sure of full connectivity) before validating topology and cracking.  That's why I've been playing around with the "Find Dangles" ready to use attribute rule and having trouble implementing it.

Seems my Dangle Tolerance for that rule (0.01) was way too low.  I set it that way because I thought it needed to be close to the cluster tolerance, but not equal or below it.  I have it set to 20 or 100 now, because I'm working with datasets that have quite many floating lines that need to be rooted out and cleaned up because they are excessive lines that should not end up in the parcel fabric.  If my cluster tolerance is too low, then the validation will not find it.  

So now my workflow to ensure full connectivity is as follows:  1.)  Planarize (low cluster tolerance/default) to slice all lines at intersections.  2.)  Snap GP tool  3.)  Validate Find Dangles attribute rule to find any remaining dangles and deal with them manually.

Thanks for the insight, as always!  😀