Regression? EWKB output differs between 3.2.0 and 3.3.3

[rcoup]

Pseudo-code (Python/DjangoGIS) -- if you need a C++ testcase I can probably whip it up, but Django is a fairly thin wrapper around the GEOS C API.

from django.contrib.gis import geos  # v1.3.3 fwiw

# create a multipolygon
g1 = geos.GEOSGeometry('MULTIPOLYGON (((166.6799806431010040 -46.4981334411101983, 166.6799806431010040 -35.3010750499954966, 178.3065325464093291 -35.3010750499954966, 178.3065325464093291 -46.4981334411101983, 166.6799806431010040 -46.4981334411101983)))', srid=4326)
print g1.hexewkb
>>> 0106000020E610000001000000010300000001000000050000000501C466C2D564405E4E2BD6C23F47C00501C466C2D56440A5AF92A089A641C09BBF571DCF496640A5AF92A089A641C09BBF571DCF4966405E4E2BD6C23F47C00501C466C2D564405E4E2BD6C23F47C0

# build a new multipolygon using the first polygon from the existing multipolygon
g2 = geos.MultiPolygon(g1[0], srid=4326)
print g2.hexewkb
>>> 0106000020E6100000010000000103000020E610000001000000050000000501C466C2D564405E4E2BD6C23F47C00501C466C2D56440A5AF92A089A641C09BBF571DCF496640A5AF92A089A641C09BBF571DCF4966405E4E2BD6C23F47C00501C466C2D564405E4E2BD6C23F47C0

g1.hexewkb == g2.hexewkb  # uh oh
>>> False

g1.hex == g2.hex  # Plain OGC WKB
>>> True

g1.ewkt == g2.ewkt
>>> True

g1.wkt == g2.wkt
>>> True

There's been a change in behaviour between 3.2.0-CAPI-1.6.0 and 3.3.3-CAPI-1.7.4. Before, the Polygon got written into EWKB without the SRID attached (only the MultiPolygon container had it). After, both the MultiPolygon and the contained Polygon EWKB have SRIDs attached. Looking through the changelog, this could have happened with #464, since AFAIK the contained Polygon gets cloned into the new MultiPolygon.

Not sure what the behaviour is meant to be, but it means EWKB values can't be compared for equality across versions.

[strk]

I'd call it a regression ! It looks like there are no automated tests for EWKB output :/

[strk]

I think the sane behavior here is dropping the SRID from geometrycollection components. Committed that behavior as r3840 in trunk and r3841 in 3.3 branch.