You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 topub 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.
The text was updated successfully, but these errors were encountered: