Miscellanous/FAQ
Geometries with Z-coordinates
Currently fractopo has only partly been tested with geometries that
have Z-coordinates (e.g. LineString([(0, 0, 0), (1, 1, 1)]). Any
issues you believe might be related to Z-coordinates should be reported
on GitHub. To test for such issues using your data, try removing the
Z-coordinates with e.g. the following code:
from shapely.geometry import Polygon, MultiPolygon, LineString def remove_z_coordinates(geometries): """ :param geometries: Shapely geometry iterable :return: a list of Shapely geometries without z coordinates """ return [ shapely.wkb.loads(shapely.wkb.dumps(geometry, output_dimension=2)) for geometry in geometries ] trace_data.geometry = remove_z_coordinates(trace_data.geometry)
Thanks to Siyh for the issue report and above code example (https://github.com/nialov/fractopo/issues/21).
Furthermore, some validation and analysis remove Z-coordinates from
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.