Opened 16 years ago
Closed 13 years ago
#103 closed task (wontfix)
Box3D always gets cast to 2D geometry
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | master |
Keywords: | boxes | Cc: |
Description (last modified by )
Actually not sure if this is solvable. But ST_SetSRID, ST_Force_3DZ all lose the Z coordinate value of a BOX3D.
Example:
SELECT ST_AsEWKT(ST_Force_3DZ(ST_Extent3D(foo.the_geom))) As b3extentpoly, ST_Extent3D(foo.the_geom) As b3extent FROM (SELECT ST_MakePoint(x,y,z) As the_geom
FROM generate_series(1,3) As x
CROSS JOIN generate_series(1,2) As y CROSS JOIN generate_series(0,2) As Z) As foo;
Yields: b3extentpoly b3extent POLYGON((1 1 0,1 2 0,3 2 0,3 1 0,1 1 0)) ;BOX3D(1 1 0,3 2 2)
I would expect the POLYGON value to have some 2 z coords in there.
Change History (8)
comment:1 by , 16 years ago
comment:2 by , 14 years ago
Description: | modified (diff) |
---|---|
Milestone: | → PostGIS 2.0.0 |
Priority: | low → medium |
Resolution: | wontfix |
Status: | closed → reopened |
Version: | → trunk |
Wait a sec, box3d is not a cube, is it ? It's defined by 2 points only, you can't define a cube like that.
I've hit this problem as well, while trying to get a 3d envelope of a 2.5d geom.
comment:3 by , 14 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
Status: | reopened → new |
comment:4 by , 14 years ago
strk, Can you ever get a valid 2.5D polygon out of a box3d unless the zs of both points are equal? The box3d in essence defines something that can not normally exist in 2.5D. It's a 2d box accompanied by a Z yardstick.
comment:5 by , 14 years ago
uhm. now that's a good point. So, what's the plan for 3d indices and such ? Which gets back to… shouldnt' we define operators of boxes rather than geometries ?
The only reason why I hit this issue was for 2.5d topology, in particular the mbr field of face table. I guess I can get away by keeping it 2d no matter topology vertex dimensionality, but wouldn't want to go against the wind if gbox is introducing smarter boxes.
comment:6 by , 14 years ago
To have a shared view on this.. BOX3D actually defines a cube, in terms of min-max range in the X/Y and Z dimension.
You _might_ represent a cube with polyhedralsurface I guess.
comment:7 by , 13 years ago
Keywords: | boxes added |
---|
comment:8 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Ticket #1329 obsoletes this one, as the only reason why you'd want to cast a BOX to a GEOMETRY is to set a srid for use with operators.
The issue here is that the cast from BOX3D to geometry only works in 2 dimensions. Unfortunately the behaviour of the 3rd dimension is not really defined when casting from a cube, so we could interpolate the Z coordinates but at the end of the day that doesn't really help you at all.
Since there is no well-defined behaviour, we may as well stick with the 2D conversion with the Z coordinate set to 0 and mark this as 'Won't fix'.
ATB,
Mark.