get geom type from prepared geom

[michaelkirk]

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

Note this builds on top of #1317, so review that first (draft until then). Merged!

PreparedGeometry is fast for some things, but it can't do everything a Geometry can do.

Since you can PreparedGeometry::from(&geometry), I'd typically follow a pattern where I'd keep the original geometry and the PreparedVersion of that geometry together, like:

let line_strings: Vec<LineString> = todo!();
let prepared_linestrings: Vec<(LineString, PreparedGeometry)> = line_strings.into_iter().map(|ls| (ls, PreparedGeometry::from(&ls))).collect();

// Then pass the (unprepared, prepared) tuple around - using the prepared geometry for fast Relate operations 
// and the unprepared geometry for everything else:

let (prepared, unprepared) = prepared_polygons.pop().unwrap();
let (other_prepared, other_unprepared) = prepared_polygons.pop().unwrap();
// It's faster to check if there *is* an intersection using a `PreparedGeometry`, 
// but to get the area of the intersection with a `BoolOp`, we need the actual geometry
if prepared.relate(&other_prepared).is_intersects() {
    unprepared.intersection(&other_unprepared)
}

That works, but it's kind of annoying to shuttle both around as a tuple, when I know internally the PreparedGeometry has a reference to the underlying Geometry. This PR exposes that:

Now you can:

let line_strings: Vec<LineString> = todo!();
// No more tuple!
let prepared_linestrings: Vec<PreparedGeometry> = line_strings.into_iter().map(PreparedGeometry::from).collect();

let prepared = prepared_polygons.pop().unwrap();
let other_prepared = prepared_polygons.pop().unwrap();
if prepared.relate(&other_prepared).is_intersects() {
    prepared.geometry().intersection(&other.geometry())
}

Note: that this makes GeometryCow public since it's a constraint on what the inner geometry of PreparedGeometry can be.

GeometryCow was previously private because it's a bit obscure - I'm not sure that it will be useful to people. But it seems stable, documented, and unlikely to be "dangerous", so I'm not worried about making it public.

[michaelkirk]

These super repetitive implementations still exist, they were just moved to the same macro loop that spits out the impl Relate for each geometry, which is no less generated code, but much less typing.

https://github.com/georust/geo/pull/1318/files#diff-68ef9d4f18a931c4cac3275e080a0e37a6a12ec252e519820801e3fa3d716dfdR82

[dabreegster]

This is a useful API change, will indeed make caller code simpler

[dabreegster]

Just reasoning through part of the diff: there was already a GeometryCow available buried deeper, but the types you're exposing here are a little different... Into<GeometryCow>, not &GeometryCow. So it's indeed necessary to store the new field, not just try and get it from geometry_graph

[michaelkirk]

That's right. This was probably worth spelling out more in my PR, but I'll do it now:

An alternate approach that doesn't add a new field/generic to PreparedGeometry could use the existing reference from the GeometryGraph's GeometryCow.

The problem is, because GeometryCow is an enum (just like geo::Geometry) holding some geometry type, we don't have a nice way to get the specific geometry type back out. Instead, the api would have to be fallible, and look like:

geometry_cow.as_point() -> Option<Point>
geometry_cow.as_line_string() -> Option<LineString>
geometry_cow.as_polygon() -> Option<Polygon>
// etc.

For a given GeometryCow, exactly one of those would return Some, the rest would return None. As a programmer using this API you'd have to keep track of what kind of geometry is in each PreparedGeometry.