Opened 15 years ago

Closed 12 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 strk)

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 mcayland, 15 years ago

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.

comment:2 by strk, 13 years ago

Description: modified (diff)
Milestone: PostGIS 2.0.0
Priority: lowmedium
Resolution: wontfix
Status: closedreopened
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 strk, 13 years ago

Description: modified (diff)
Owner: changed from robe to strk
Status: reopenednew

comment:4 by robe, 13 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 strk, 13 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 strk, 13 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 strk, 13 years ago

Keywords: boxes added

comment:8 by strk, 12 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.