You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When points elements are being shown, an optimal size for the points is guessed based on a heuristic implemented in _calc_default_radii().
There are three fixes that we need to make here:
get_extent(), even when using exact=False, is too slow when there is a large number of points. We should add a parameter fast: bool = False which computes a very rough approximation of the extent based on some "Montecarlo" sampling.
The value in unit we return is wrong when we are in a scaled coordinate system; I think that we need to divide by the average module of the eigenvalues of the affine transformation, as we do in _adjust_radii_of_points_layer()
When points elements are being shown, an optimal size for the points is guessed based on a heuristic implemented in
_calc_default_radii()
.There are three fixes that we need to make here:
get_extent()
, even when usingexact=False
, is too slow when there is a large number of points. We should add a parameterfast: bool = False
which computes a very rough approximation of the extent based on some "Montecarlo" sampling._adjust_radii_of_points_layer()
get_extent()
where the single-dispatch doesn't recognizeSpatialData
objects. This is tracked here:get_extent()
does not recognizesSpatialData
in the single dispatch pattern in specific cases spatialdata#500For the moment, I am disabling the use of
_calc_default_radii()
in #215.The text was updated successfully, but these errors were encountered: