fix crs on polygon clipping #309
Conversation
|
Ugh it's not this simple...needs extents too. We should just call tuples and normalize everything when pushing to the array. |
Extend CRS handling from intersection to union and difference operations. Use `mutual_crs` to preserve coordinate reference system information when creating result polygons in non-crossing cases, hole handling, and multipolygon operations. Fixes type mismatches when clipping geometries with different CRS configurations.
asinghvi17
force-pushed
the
as/clipping_crs
branch
from
30bf6b0 to
de4679e
Compare
…g conversion Implements trait-based dispatch in `_linearring` helper to convert LineString geometries (e.g., from ArchGDAL) to LinearRing while preserving CRS metadata. This ensures compatibility with all GeoInterface-compatible geometry types. The function uses trait dispatch pattern: - Returns LinearRing geometries as-is - Converts LineString to LinearRing with CRS preservation - Includes concrete type specializations for GI wrappers (optimization) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Adds missing CRS parameter propagation in `intersection.jl` to match the pattern already used in union and difference operations. This fixes type conversion errors when using ArchGDAL geometries in intersection operations. Changes: - Pass `crs` parameter to `_trace_polynodes()` call (line 87) - Wrap `tuples()` results with `_linearring()` in non-crossing cases (lines 91, 93) With this fix, all 72 intersection and union operations now succeed across GeoInterface, ArchGDAL, and LibGEOS geometry combinations. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
| This is tolerant of `nothing` values in one of a or b, it assumes that they are the same crs. | ||
| """ | ||
| function mutual_crs(a, b) | ||
| if GI.crs(a) == GI.crs(b) |
There was a problem hiding this comment.
This is type unstable.
I think we need to error if they are not nothing but different.
There was a problem hiding this comment.
why is the equality check type unstable? but more to the point, how would it be possible to make it type stable? You'd just hoist the instability to outside this function...
There was a problem hiding this comment.
If you have the comparison EPSG(4326) == EPSG(3857) you were comparing a runtime Int for a branch that returned either EPSG(4326) or nothing. So a return type of Union{Nothing,EPSG}. That will leak everywhere, and after some nesting in apply could even lead to Anys.
There was a problem hiding this comment.
It could be clearer to put the isnothing checks first as the compiler will remove those anyway, then the only real check - == will happen right above the else ... error() and make things more clear.
Finally, this propagates CRS through polygon clipping.