Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a large snap_threshold value can cause: ValueError: Found endpoint in replace_endpoint dict. #22

Open
Siyh opened this issue Mar 30, 2023 · 1 comment

Comments

@Siyh
Copy link

Siyh commented Mar 30, 2023

I'm analysing a large scale fault tracemap (>500 m length trace). If I set the snap threshold to 10 m, I get the error: ValueError: Found endpoint in replace_endpoint dict..

Unfortunately the tracemap is confidential which I realise makes it very hard for you to debug, but I thought I'd share in case you could suggest the best approaches for me to debug?

@nialov
Copy link
Owner

nialov commented Mar 30, 2023

The snap_threshold is for the most part designed to handle the (unavoidable) errors in topological snapping. If the traces in the map are snapped using the snapping functionality of e.g. QGIS or ArcGIS, the distance between endpoints and the segments they should be snapped to be should be well below the threshold of 0.001, which is the default. This can probably be changed in the settings of these software but for the most part the snapping error should not be connected to e.g. the lengths of the traces you are digitising. Using a value as high as 10 m is only sensible if the traces are very large scale.

I would recommend, if possible, making sure that the snapping is done properly using the GIS software. Secondly, the traces should not pass the trace validation part with the same snap_threshold as successful validation should mean that the analysis part will succeed without errors such as these. Have you validated the data with the same snap threshold?

To note: These numeric values and defaults in code mostly assume a metric coordinate system (which I probably should highlight in documentation).

nialov added a commit that referenced this issue Apr 12, 2023
Rephrased the info that was posted in #22.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants