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

Add info on snap threshold and crs assumptions #24

Merged
merged 1 commit into from
Apr 14, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions docs_src/misc.rst
Original file line number Diff line number Diff line change
Expand Up @@ -36,3 +36,31 @@ geometric results. Specifically, use of ``Validation`` will remove
Z-coordinates to avoid unexpected behaviour. Use of ``Network`` will by
default remove z-coordinates but this can be disabled (See ``Network``
input arguments)..

Snap threshold parameter
------------------------

Both in validation and analysis a ``snap_threshold`` parameter is used. 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 value used in ``fractopo``. This
threshold during digitising 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.

I would recommend, rather than using a higher ``snap_threshold`` in
``fractopo``, to make sure that the snapping is done properly within the
GIS software used in digitising.

Coordinate systems
------------------

``fractopo`` for the most part assumes a metric coordinate system and
has mostly been tested with data which has the coordinate system of EPSG
3057. Issues with data from other coordinate systems should be posted on
*GitHub*. Using a coordinate system with metric units should be the
first step in debugging if you believe an issue is caused by
``fractopo`` not handling other units correctly. Especially the
``snap_threshold`` value should be adjusted based on the units used.