Select to view content in your preferred language

Extend Line Tool Not Working?

3274
2
Jump to solution
06-06-2013 12:08 PM
by Anonymous User
Not applicable
Original User: kaeldowdy

So, this is a continuation from my first post related to inaccurate matches at: http://forums.arcgis.com/threads/86038-Inaccurate-Matches-in-Spatial-Join-(Precision-Problem-), but I felt this question needed its own thread...

I have two simple line feature classes:  Leader Lines and Pipelines (color coding used to explain the screenshots).  The Leader Line feature might be either just "before" (Example 1) or "after" (Example 2) the Pipeline feature.  What I'm wanting to do is to extend or shorten the Leader Line to touch the Pipeline.  In my earlier post, I've already gone through the process of determining which Leader Lines aren't touching a Pipeline feature, so now I need to act upon the ones I determined were disconnected.

Example 1 (Leader Line ~ .5 mm away from Pipeline)

[ATTACH=CONFIG]25092[/ATTACH]

Example 2 (Leader Line ~ .38 mm past Pipeline)
[ATTACH=CONFIG]25093[/ATTACH]

I reviewed the Extend Line and Trim Line tools, and tried using the Extend Line tool on my Example 1 scenario Leader Lines, but I could not ever get the line to extend to the pipe.  Maybe I'm misunderstanding the usage of this tool (do all objects need to be within the same feature class or can they be different?)

I then tried merging these two feature classes together, and then selected the Leader Line and tried running the Extend Line tool, but no dice either.  The SHAPE Length remained the same.

Does anyone have any thoughts as to a different way to go about extending (or shortening) the line within a certain tolerance?  I'm thinking anything <= 1.0 mm would be a good start. 

Thanks!

EDIT 1: So, I'm making progress. When I mentioned earlier that I was "merging" the two feature classes together, I was actually using theUnion tool, but I found that if I used the Merge tool, and then run the Extend Line tool, it works!  Well, mostly...

When I run the extend on my leader line, the line extends past the pipeline and not exactly on the pipeline.  When I measure the little dangle, it's very small -- 0.000007 mm.  This might be an acceptable tolerance for some, but it still is not technically touching and I'm afraid I will run into issues later once I import this data back into my source system (GE Smallworld). 

I found that I needed to provide an XY Resolution and Tolerance of 0.00001 mm whenever I run the Merge and then the Extend Line works on the output geodataset from the Merge. 

Is it possible that my feature classes which go into the merge need to be recreated with a certain level of precision to allow for subsequent processes to be more accurate?  I'm just wondering if we need to reexamine how the initial geodatasets are even being created. 

Otherwise, is there a combination of settings for the XY Resolution and Tolerance needed to make the Extend work as desired?
0 Kudos
1 Solution

Accepted Solutions
by Anonymous User
Not applicable
Original User: rfairhur24

You will most likely never get absolute 0 accuracy of a projected point on a line.  The Resolution and Tolerance predetermine the exact level of imprecision you want to allow.  You can continue to increase these settings, but any values lower than those settings will be accepted by the system and acceptable equivalent positions.  I believe at 15 significant digits you will reach the limit of the double precision field is capable of storaging.  But that comes with the cost of severely limiting the total world XY coordinate system your data can accommodate. 

Points will always move to actual XY positions that can actually be stored on the exact coordinate values those settings can create.  The computer is binary and that makes certain values that can exist along a line with any slope beyond pure horizontal or pure vertical on whole number positions very hard to represent in the significant digits of fractional values.  That is why you will see fractional values on point XY coordnates that are below your tolerance settings as the computer tries its best to represent the number within the binary system precision.

I would test what you have in the GE Smallworld application to see what level of tolerance they accept.  They have to accept some tolerance, since it impossible to store infinitely precise coordinates in a binary computer system.  Their line won't exactly fall at every infinite position along the line's length either, since they have to store coordinates somewhere.  I believe they would have use a non-standard field storage type to exceed the top precision ESRI supports.

View solution in original post

0 Kudos
2 Replies
by Anonymous User
Not applicable
Original User: rfairhur24

You will most likely never get absolute 0 accuracy of a projected point on a line.  The Resolution and Tolerance predetermine the exact level of imprecision you want to allow.  You can continue to increase these settings, but any values lower than those settings will be accepted by the system and acceptable equivalent positions.  I believe at 15 significant digits you will reach the limit of the double precision field is capable of storaging.  But that comes with the cost of severely limiting the total world XY coordinate system your data can accommodate. 

Points will always move to actual XY positions that can actually be stored on the exact coordinate values those settings can create.  The computer is binary and that makes certain values that can exist along a line with any slope beyond pure horizontal or pure vertical on whole number positions very hard to represent in the significant digits of fractional values.  That is why you will see fractional values on point XY coordnates that are below your tolerance settings as the computer tries its best to represent the number within the binary system precision.

I would test what you have in the GE Smallworld application to see what level of tolerance they accept.  They have to accept some tolerance, since it impossible to store infinitely precise coordinates in a binary computer system.  Their line won't exactly fall at every infinite position along the line's length either, since they have to store coordinates somewhere.  I believe they would have use a non-standard field storage type to exceed the top precision ESRI supports.
0 Kudos
KaelDowdy
Deactivated User
I would test what you have in the GE Smallworld application to see what level of tolerance they accept.  They have to accept some tolerance, since it impossible to store infinitely precise coordinates in a binary computer system.  Their line won't exactly fall at every infinite position along the line's length either, since they have to store coordinates somewhere.  I believe they would have use a non-standard field storage type to exceed the top precision ESRI supports.

Thanks for the insight into how the Resolution and Tolerance works in ArcGIS -- that was very helpful to know how those values come into play when determining equivalent coordinates.

I do like the idea of trying what I have at this stage and see what it looks like in Smallworld.  Perhaps by the time the geometry gets into that environment we may not even notice a problem.

I guess I was trying to mimic some of what comes out of Smallworld.  For many of the leader lines coming off of the pipelines, the end point of the leader touches the pipeline exactly (at least "exactly" in terms of what I can zero in on from within ESRI).  However, those are for points which are correctly drawn from within Smallworld and likely use a snapping mechanism to do so.  Smallworld will accept non-connected leader lines, but we have some processes in TIBCO which scan the geometry in Smallworld and take action on pipeline segments which have connected leader lines -- and since many of them are "disconnected", the process on the TIBCO side is missing them. 

It's ultimately a training issue with the tech who's drawing the leader lines not connecting them precisely, but I'd like to find a way to fix this in an automated fashion so TIBCO and other processes can pick these situations up and us not have to manually fix several thousand leader lines...

Thanks again for the info!
0 Kudos