Reverse: choose between libgeos and PostGIS behaviour

[peterstace]

There is some behavioral difference in the Reverse operation between PostGIS and libgeos.

E.g. for MULTILINESTRING((8 4,6 1,3 9,0 2),(5 3,4 8,1 2,9 8)):

PostGIS gives: MULTILINESTRING((0 2,3 9,6 1,8 4),(9 8,1 2,4 8,5 3)) Libgeos gives: MULTILINESTRING((9 8,1 2,4 8,5 3),(0 2,3 9,6 1,8 4))

The current behaviour simplefeatures has implemented is the PostGIS behaviour. We need to decide if we wish to keep this behaviour, or if we wish to switch to libgeos behaviour.

[DoctorLoki]

A third possibility is adding an option to choose a compatibility mode, across the whole code base.

[peterstace]

That's a good point. One way of doing that could be to allow Reverse to take functional options which could make it behave differently.

[DoctorLoki]

Yes, although a global mode variable would let you write if Compatibility == CompatibleWithPostGIS to encapsulate all those differences using consistent symbols across the whole code base.

[peterstace]

I'd rather stay away from a global mode setup, since two users of the library within the same executable may ask for different behaviour requirements (unbeknownst to each other). Whoever set the mode first would end up silently getting unexpected behaviour.

I think the current behaviour is probably fine. In a certain sense, the ordering of some things have semantic reasoning and the order of other things don't (I say in a certain sense, since I guess these are subjective, and rely on convention):

• The order of inner rings in a Polygon, LineStrings in a MultiLineString, Polygons in a MultiPolygon, or Geometries in a GeometryCollection don't have any semantic meaning. The current behaviour doesn't change the ordering of these.
• The ordering of coordinates within a LineString or ring do have semantic meaning (since they either change the direction of the LineString, or the orientation of the ring). The current behaviour does change these.

So there is some consistency between reversing the order of things that have semantic meaning, but leaving alone things that don't. That seems fairly logical to me (and I'm guessing that's why PostGIS implemented it in that way).

I'll close this ticket out.