Dan Baston

This PR addresses `geos_c` and `geos` but we have many more targets for benchmarks, tests, and utilities (geosop). I would prefer not to have all of these moved.

Interesting that these cases were supported by GEOS but removing that support apparently produced no test failures in GEOS or PostGIS?

> Finally, we could bypass GDAL altogether and write a custom rasterization algorithm (...) Then build python bindings to it. Some discussion at https://github.com/isciences/exactextract/pull/34

Sorry if this is off-topic/spam, but I've been working on a similar project that I thought might be of interest. It's some C++ code, exposed as an R package, that...

@davidabek1 @sgoodm The approach of https://github.com/isciences/exactextract is equivalent to the Stack Exchange link; the difference is that exactextract does the vector-based intersections in a way that takes advantage of the...

I don't have experience targeting an earlier Java version than what I'm compiling on, but it seems like it could complicate project development and testing (developers would need to verify...

Given that JTS now uses interface default methods (for example, [here](https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/geom/CoordinateSequence.java#L95)) it seems like the target is now 1.8.

Would it be reasonable to specify the compile version at 1.8 in the root `pom.xml` for now (to fix the build failure described in #276) and then update the version...

> Would it be reasonable to specify the compile version at 1.8 in the root pom.xml for now Looks like this was done at d13f2309c3c28eb3aa0e. Probably this issue can be...

Perhaps this falls under 'known bugs' described at https://locationtech.github.io/jts/javadoc/org/locationtech/jts/simplify/TopologyPreservingSimplifier.html