Snapping

[SLouq]

I have a question about snapping.  

I am working with line features and notice the vertexes of my lines are not snapping to the edges of lines they are intersecting with even though I have edge snapping turned on. The embedded image shows how they are not snapping. Can someone show me what snapping tool has to be on in the snapping settings?

Thanks

[Scott_Harris · Accepted solution]

@SLouq Is it possible that you are zooming in beyond 1:1 for map scale?

[SLouq]

How can you zoom in beyond 1:1? I just zoomed in as much as it would let me. 

I was always under the impression when snapping is on, you should see no gap between the lines

ETA: You are right. I just looked at it again and I see now how you can go past 1:1 with the zoom. 

[Scott_Harris · Accepted solution]

Yes zooming in beyond 1:1 is allowed, but the distances represented in the gap are most likely negligible and within the XY Tolerance of the data. Feel free to contact Esri Technical Support if you need help verifying.

[GISAdminSHN]

@Scott_Harris I'd like some further clarification on why snapping would not place the new vertex at a location on the edge being snapped to, using the XY tolerance of that edge's dataset. In using a snap, the user is asserting their intent to be "topologically pure", snap should respect the intent of the user.

Also, there should be a help document that discusses the relationships between map unit precision settings, snap settings, and XY Tolerance settings of the common "snappable" feature dataset filetypes. It should include guidance on which settings to employ in typical use cases (high-accuracy, moderate-accuracy, low-accuracy), where those settings are found, and anything that overrides or hinders the use or modification of the settings. Feel free to use this thread and it's followers as a guinea pig if you'd like to post the rough draft here! 😄

[Scott_Harris]

Hi @GISAdminSHN ,

I like your idea of having some additional documentation regarding editing and XY tolerance/resolution. I haven't seen a case where the default XY tolerance/resolution (0.001 meters/0.0001 meters) weren't good enough for most every mapping use case, but I may not have seen _every_ use case :). I'll bring it up with the documentation folks.

Also, it sounds like you may be running into a similar issue to what @SLouq saw? If that's the case, and you are willing to contact Esri Technical Support with details on how to reproduce it, I'd be more than curious to dig deeper into it with the development team. If you end up doing that, please reach out by sending me a direct message on here, or have the analyst reach out to me to let me know.

[GISAdminSHN]

@Scott_Harris I am going to test a few more things and will file a support ticket with steps to reproduce my use case. One of the more notable anomalies I am seeing is that after snapping to an intersection or vertex, I am able to see the true coordinate in the sketch geometry pane, but after committing the edit and saving changes, the coordinate of the vertex has been slightly modified.

Is it smaller than the default tolerance? Yes, yes it is! 😄 But I cut my teeth in the industry on CAD survey drafting, so I am a bit pickier than most. Some of my workflow involves CAD interop as well so I want to make sure things that should be touching are indeed touching so some tools in CAD don't break, like BHATCH and BOUNDARY that will misbehave when regions that are supposed to be closed off have these kinds of microgaps.

Completely understand the sentiment that this can be considered a not-a-gis-problem if all the tools in Pro respect the implied topology, but that won't stop me from digging in to see where I can get the highest coordinate precision I can out of Pro and it's feature datasets. It helps us avoid potential interoperability issues with CAD, QA data review issues where discrepanices like these often point to a procedural problem in the way the data is authored, and of course the micro-aggressions of knowing the snaps have this wiggle in them! 😄

In the meantime, would you consider posting us an "OCD Neat Freak Cheat Sheet" for maxing out precision settings for Pro 3.3, fgdb feature classes, and shapefiles?

[GISAdminSHN]

@Scott_Harris and all, I have arrived at a better understanding of XY Resolution that underpins this issue and wanted to share in case anyone else needs to find their way there!

The issue is created when utilizing snaps other than Point, Endpoint, or Vertex. The XY Resolution of your datasets will be leveraged to conform any new/modified points/vertices to their closest spot on the "resolution grid."

https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-an...

All line and polygon edges start and end on these conformed points, but virtually all of the coordinates on those lines that can be calculated and snapped to are NOT resolution grid conforming! The initial snap yields the precise coordinate, but the moment you complete the part or sketch, vertices are instantly conformed to the resolution grid. This in turn causes the gap between the new vertices and the existing feature edge that you thought you just snapped to!

Options:
-To eliminate the gap you may add new vertices to those target features at the same snap locations you just used. This can also help mitigate future potential CAD hatch and boundary command failures caused by "loose topology" (CAD is much higher resolution by default and those tools will flood through the gaps we are currently discussing.)
-There may be a Topology tool that will add vertices wherever another feature is touching (based on XY Tolerance?)
-Python probably has some methods that could do some sort of targeted Densify. I will probably be looking into that, sounds fun!
-XY Resolution Override. Most documents say it voids the warantee, but if you are currently within a step or two of resolution of this not being a further issue I would seriously consider it.

Here is the illustratration of the issue:

Intersection Snap grabs the precise coordinate (it cares not about bossy XY Resolution):
6,110,977.16014931, 2,230,057.77071054

Vertex as repositioned the moment you finish sketch:
6,110,977.16028832, 2,230,057.77083366

[Scott_Harris]

Hey @GISAdminSHN I like the breakdown of your testing. Thanks for sharing!

Considering you are only seeing the offset when snapping to an edge, it actually might be expected. Why? If you were to draw a 2-point line where the endpoints are snapped to the coordinate grid (defined by the XY resolution), you can't really guarantee that any given point along that line will intersect the grid exactly.

Regarding your test: If you plug those 2 sets of coordinates into a distance formula, you get something like 0.00019 units. Assuming those are meters, that is less than the default XY tolerance of 0.001 m.

I'd say that's an acceptable distance, however, I do agree that it causes a bit of anxiety to see that on display in your map. Something interesting about that: only starting in version 2.5, did Pro start allowing you to zoom in beyond 1:1 - so these types of things wouldn't ever be noticed prior to that. As far as I know, ArcMap didn't allow zooming in beyond 1:1. I can't account for every version of ArcMap, but the last version seems to not allow it.

One thing you can do is create a topology with the default cluster tolerance (0.001 m) with no rules and validate it. Once you validate everything within 0.001 m will snap together. This will change the data by adding vertices to edges where they intersect to allow for clustering to occur.

[GISAdminSHN]

@Scott_Harris The XY Tolerance setting is not really implicated in CAD interoperability, but the XY Resolution has direct effects that are more measurable and impactful than you would think. Since at least the 90's surveyors have normally been required to submit coordinates in feet to 3 decimal places, and NGS requires 3 these days. The output from survey equipment would typically be stored to at least two places further than the submittal requirement, so 4 was pretty standard for a long time and 5 or 6 is probably appropriate now.

CAD software works at 64-bit precision, so a typical CA State Plane coordinate in US Feet would be stored at 7 or 8 places. Keep in mind that the point and vector data being produced by every AEC-related company in the USA is likely operating at that resolution or better.

The scenario that needs attention here is when GIS teams are producing or editing vector data that will be expected to have the correct topological relationship with the source CAD data. The necessary end result: the GIS data can be exported to CAD format or imported in CAD and has maintained its original level of precision. 

I would like to see a concise guide on exactly what combination of Environment Settings and Custom Spatial Reference option should be leveraged to simply increase the amout of XY Resolution of a project and it's layers from default (.0001 m) to something really useful for CAD interop folks (.00001 us ft)

If these steps aren't taken, the resulting "grid conformance de-resolution" of the data makes your CAD team lose trust with GIS data. In the AEC industry that has an overall chilling effect on GIS development since GIS is commonly first used in an AEC company in support of Civil/CAD workflows before growing into a collaboration, review, planning, and data management tool (among hundreds of other useful and amazing things!)