Panic on clip operation #1174
Comments
|
Here's another likely-related stacktrace I experienced today using different data: |
|
Hi, I encountered a similar bug: use geo::{BooleanOps, Polygon, LineString, Coord};
fn main() {
let poly1 = Polygon::new(
LineString::new(vec![
Coord {
x: -10339459.518507583,
y: 3672178.7824083967,
},
Coord {
x: -10172502.686420029,
y: 3169028.9498966974,
},
Coord {
x: -10002503.513328442,
y: 3498113.19617442,
},
]),
vec![],
);
let poly2 = Polygon::new(
LineString::new(vec![
Coord {
x: -10644125.090349106,
y: 3510000.058398463,
},
Coord {
x: -10010375.27222986,
y: 3502179.60931681,
},
Coord {
x: -10018249.493188547,
y: 3506247.294314978,
},
Coord {
x: -10018249.49318854,
y: 3506247.294314993,
},
Coord {
x: -10320063.446714956,
y: 3765929.7827082784,
}
]),
vec![],
);
poly2.union(&poly1);
}with stack trace: thread 'main' panicked at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/sweep/vec_set.rs:29:14:
segment not found in active-vec-set: 1
stack backtrace:
0: rust_begin_unwind
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/panicking.rs:72:14
2: core::result::unwrap_failed
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1654:5
3: core::result::Result<T,E>::expect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/result.rs:1034:23
4: geo::algorithm::sweep::vec_set::VecSet<geo::algorithm::sweep::active::Active<T>>::index_of
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/sweep/vec_set.rs:27:9
5: geo::algorithm::sweep::proc::Sweep<C>::handle_event
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/sweep/proc.rs:232:30
6: geo::algorithm::sweep::proc::Sweep<C>::next_event::{{closure}}
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/sweep/proc.rs:46:13
7: core::option::Option<T>::map
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/option.rs:1073:29
8: geo::algorithm::sweep::proc::Sweep<C>::next_event
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/sweep/proc.rs:44:9
9: <geo::algorithm::sweep::iter::CrossingsIter<C> as core::iter::traits::iterator::Iterator>::next
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/sweep/iter.rs:170:26
10: geo::algorithm::bool_ops::op::Proc<T,S>::sweep
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/bool_ops/op.rs:81:30
11: <geo_types::geometry::polygon::Polygon<T> as geo::algorithm::bool_ops::BooleanOps>::boolean_op
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/bool_ops/mod.rs:69:9
12: geo::algorithm::bool_ops::BooleanOps::union
at /home/arenaud/.cargo/registry/src/index.crates.io-6f17d22bba15001f/geo-0.28.0/src/algorithm/bool_ops/mod.rs:33:9
13: crashpolygeo::main
at ./src/main.rs:46:5
14: core::ops::function::FnOnce::call_once
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5 |
mikemoraned
added a commit
to mikemoraned/spectrum
that referenced
this issue
Aug 5, 2024
…eo library - panix possibly related to georust/geo#1104, georust/geo#1174 or similar
2 tasks
michaelkirk
added a commit
that referenced
this issue
Oct 28, 2024
We've had several reports of crashes in our BooleanOps implementation over the years. Some of them have been addressed, but there remains a long tail of crashes. FIXES #913, #948, #976, #1053, #1064, #1103, #1104, #1127, #1174, #1189, 1193 The root of the issue (as I understand it) is that floating point rounding errors break the invariants of our sweep line algorithm. After a couple years, it seems like a "simple" resolution is not in sight. In the meanwhile, the i_overlay crate appeared. It uses a strategy that maps floating point geometries to a scaled fixed point grid, which nicely avoids the kind of problems we were having. Related changes included: Included are some tests that cover all reports in the issue tracker of the existing BoolOps panic'ing JTS supports Bops between all geometry types. We support a more limited set: 1. Two 2-Dimensional geometries `boolean_op`. 2. A 1-Dimenstinoal geometry with a 2-D geometry, which we call `clip`. So this maps JTS's Line x Poly intersection tests to our Clip method. - rm unused sweep code now that old boolops is gone I marked a couple fields as `allow(unused)` because they are used for printing debug repr in tests. Speed up benches by only benching local boolop impl by default
|
I just merged #1234 which replaces our BoolOps implementation with one backed by the i_overlay crate. This should resolve the issue you're seeing. Let us know if it recurs. You can use it now if you use the unreleased |
urschrei
pushed a commit
to urschrei/geo
that referenced
this issue
Nov 6, 2024
We've had several reports of crashes in our BooleanOps implementation over the years. Some of them have been addressed, but there remains a long tail of crashes. FIXES georust#913, georust#948, georust#976, georust#1053, georust#1064, georust#1103, georust#1104, georust#1127, georust#1174, georust#1189, 1193 The root of the issue (as I understand it) is that floating point rounding errors break the invariants of our sweep line algorithm. After a couple years, it seems like a "simple" resolution is not in sight. In the meanwhile, the i_overlay crate appeared. It uses a strategy that maps floating point geometries to a scaled fixed point grid, which nicely avoids the kind of problems we were having. Related changes included: Included are some tests that cover all reports in the issue tracker of the existing BoolOps panic'ing JTS supports Bops between all geometry types. We support a more limited set: 1. Two 2-Dimensional geometries `boolean_op`. 2. A 1-Dimenstinoal geometry with a 2-D geometry, which we call `clip`. So this maps JTS's Line x Poly intersection tests to our Clip method. - rm unused sweep code now that old boolops is gone I marked a couple fields as `allow(unused)` because they are used for printing debug repr in tests. Speed up benches by only benching local boolop impl by default
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following code panics. It tries to calculate
clipfor two geometries: aMultiPolygoncontaining two polygons that share a common edge, and aMultiLineString(I could reduce the latter to a single line segment).The data is from OpenStreetMap. Here is a link to the geometries. The line is the segment of the line on the map that intersects the common edge of the areas.
Here is a backtrace.
The text was updated successfully, but these errors were encountered: