In pygeos, we didn't have the Geometry subclasses, so things like pickling were implemented in C. I am really 👍 on keeping that kind of per-object logic on the Python side.

I suppose I can then actually remove the C version (GeometryObject_reduce)

Looks good. I still don't like the idea of SRID support. Not supporting SRID up to this point has eliminated a source of complexity and thus has been good for Shapely. And the GEOS project doesn't consider SRID to be a useful feature, either.

As long as we limit the SRID support strictly to IO (i.e. pickling and read/write WKB), I don't think it will really add a source of complexitly / issues. If someone opens an issue related to SRID for anything else, we can simply close as out-of-scope / defer to GEOS.

I personally don't care that much about preserving SRID for pickling, as long as we support it for WKB (which is needed for example for PostGIS interaction)

Personally I also think that srids are out of scope. However if users want to carry this information (any information really) along with the geometries, then I think it is fine to support that. As long as we never base any logic on it.

I looked in geopandas and it seems that it is only depending on a geometry's SRID due to a design choice and not because there is no other way. Instead of checking to see if an SRID is set on the first geometry at https://github.com/geopandas/geopandas/blob/d006fad416a9f33fd88c1a00744ae9f98cb9c6d0/geopandas/io/sql.py#L88 (if there was a bug here it would be super confusing), this function could instead call https://postgis.net/docs/Find_SRID.html via pd.read_sql() or some lower level function.

We still use SRID for WKB export to PostGIS as well (that doesn't need to be on the geometry though, but as mentioned above still need it in the WKB IO functions)
(this relates to pygeos/pygeos#137)

For the reading side, it is true that we don't need the get_srid(geom) for PostGIS, as we could indeed use one of the PostGIS function as well. However, I personally think we should still support reading the SRID from a WKB object. You can have other sources of WKB than PostGIS, and I think generally being able to extract all information contained in the WKB is a good thing to support.

Pull Request Test Coverage Report for Build 1627350912

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 7 of 7 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+2.9%) to 83.969%

Totals
Change from base Build 1627324933:	2.9%
Covered Lines:	2200
Relevant Lines:	2620

💛 - Coveralls

Since this PR is only fixing the LinearRing pickling and making it consistent with the other geometry classes, I am planning to merge this.
We can continue the discussion about to what extent we want to expose SRID related functionality in general in another issue.