WKB is missing collections support

[nicerobot]

This WKB

0107000000030000000101000000550B36BFABD753C07CE58B07A5D24540010200000005000000C4190D2ABBD753C028AA6D799BD24540B51F84DBB5D753C07954A1269FD24540F9DB9E20B1D753C0E3D011AFA1D24540FB8E86F8ACD753C0ED444948A4D24540550B36BFABD753C07CE58B07A5D24540010200000002000000550B36BFABD753C07CE58B07A5D24540F6D786E5AAD753C0C619C39CA0D24540

is

GEOMETRYCOLLECTION(POINT(-79.3698576 43.6456613),LINESTRING(-79.3707986 43.6453697,-79.3704747 43.6454819,-79.370186 43.6455592,-79.3699323 43.6456385,-79.3698576 43.6456613),LINESTRING(-79.3698576 43.6456613,-79.3698057 43.6455265))

But fails with

wkb: unsupported type: 7

[twpayne]

Thanks for the report!

go-geom currently does not support geometry collections. The reason is that they behave very differently to every other type of geometry, and I haven't found a good way to implement them within the constraints of Go's type system.

All ideas for how geometry collections could be implemented are welcome :)

[nicerobot]

It seems to me []geom.T would handle it where collections are themselves a geom.T?

[twpayne]

Agree. A (slightly) tricky aspect is: should geometry collections themselves implement the geom.T interface? If so, how?

The last time I read the OGC spec, I didn't spot anything that excluded geometry collections from containing nested geometry collections. So, this means that geometry collections have to implement the geom.T interface. However, geom.T includes methods to access the underlying flat coordinates slice, layout, and stride, but there is no requirement that the geometries in a geometry collection even have the same layout or stride, and the code to handle this variation while packing all the coordinates in a geometry collection into the same flat coordinates array will be quite tricky to write.

An alternative would be to implement geometry collections as a special case of geom.T, i.e. stub out the normal geom.T methods to return nil or panic with an error, but this will mean littering any code that handles geometry collections with type assertions.

I suspect that the second approach is the right one. I'll try typing up some code to see how it looks. Feel free to propose something too :)

[nicerobot]

I was thinking of the special-case geom.T for collections. I think it'll be a little unfortunate to clutter the code with special cases but I do think that respects the OGC spec since collections are different than geometries.

Also, right now, i'm just unmarshaling for marshaling to geojson so i don't care about any other operations on the collection.

[twpayne]

I put some initial work-in-progress code here:
https://github.com/twpayne/go-geom/compare/geometry-collection?expand=1
It doesn't pass the tests yet, but is a rough idea of what I had in mind.

[nicerobot]

Very nice. I commented on SetSRID.
Let me know if/when it's testable and i'll give it a spin (probably not right away but I do have a test case waiting for testing when I can get back to it).