Problems importing 3 and 4 dimensional geometries

[olsen232]

In datasets V2, constraining a geometry to be a particular type eg geometry(POINT Z, 4326) is the only way to store the geometry's type - the geometry column is then of that type, AND, all geometries in the column will be considered to be that type, and if they are provably not that type, then they cannot be stored in that column.

We store this same metadata as column constraints in the working copies.

PostGIS lacks the ability to constrain a geometry as having a particular SRID, without also constraining its dimension.
When mirroring internal PostGIS db "datadb", the geometry columns are completely unconstrained. The OGR library that we use for imports correctly extracts the SRID from a random geometry instance in the column, but doesn't check the dimensionality of the geometry instance. OGR also only tells us if a geometry column definitely does have Z or M - it doesn't tell us if it definitely doesn't. So, since these unconstrained tables aren't definitely 3 or 4 dimensional, we just assume they are 2 dimensional.

So the original postGIS type is simply geometry which is imported as geometry: geometry_type=GEOMETRY, geometry_CRS=4326 (or whatever is appropriate). The lack of Z and M means we think it is 2 dimensional. If we then try to check this out as a PostGIS working copy, it fails - the PostGIS WC geometry column is given type geometry(GEOMETRY, 4326) which again is constrained to be 2 dimensional. So, if the geometries are actually 3 dimensional, they can't be put in the WC.

[olsen232]

Fixed at 8bafada - or at least, fixed for import sources that have >0 geometries and all the geometries have the same dimensionality. (This should at least cover mirroring).