Consider using new TZM geo/geo-types

[nyurik]

Would it make sense to migrate all internal postgis types to the proposed geo-types that support T, Z, and M generic types? Are there any changes that should be made to that proposal? How should SRID be added to it? One option might be to double the number of types - e.g. LineString, LineStringM, LineStringZ, LineStringZM, LineStringS, LineStringMS, LineStringZS, LineStringZMS, where all of them are aliases to pub struct LineStringTZM<T: CoordNum, Z: ZCoord, M: Measure, S: SRID>(...) -- where SRID could be defined as either i32 or NoValue.

If SRID is not accepted to geo/geo-types as an i32 (which seems to be a postgis convention only), one option would be to have some sort of a wrapper enum as described in georust/wkt#91 with an additional i32 srid.

[EvanCarroll]

The srid doesn't have to be i32, there isn't a value that goes negative.

[EvanCarroll]

Looking at this if I did this now and implement srid functionality in rust-postgis -- which I'm half tempted to do anyway I would have rewrite this whole crate to flatten the wrapped NewTypes to maintain the same nice api.

God I wish these types were in georust/geo, so I could fix this here like God intended.

georust/geo#1341 (comment)

[EvanCarroll]

In my fork at postgis-butmaintained, the ekwb::Point is now based of geo-types::Point internally, it add an srid.