Opened 5 years ago

Closed 5 years ago

#2954 closed defect (fixed)

ST_ClipByBox2D: ERROR: gbox_overlaps: cannot compare geodetic and non-geodetic boxes

Reported by: strk Owned by: pramsey
Priority: blocker Milestone: PostGIS 2.2.0
Component: postgis Version: master
Keywords: Cc:

Description

Calling this:

SELECT st_clipbybox2d('SRID=4326;POINT(0 0)','BOX3D(-1 -1,1 1)'::box3d);

Results in:

ERROR:  gbox_overlaps: cannot compare geodetic and non-geodetic boxes

Which box is geodetic ?

Change History (6)

comment:1 Changed 5 years ago by strk

Using a BOX2D (as expected by the signature) works:

SELECT st_clipbybox2d('SRID=4326;POINT(0 0)','BOX(-1 -1,1 1)'::box2d);
0101000020E610000000000000000000000000000000000000

But casting a BOX3D to a BOX2D fails again:

SELECT st_clipbybox2d('SRID=4326;POINT(0 0)','BOX3D(-1 -1,1 1)'::box3d::box2d);
ERROR:  gbox_overlaps: cannot compare geodetic and non-geodetic boxes

comment:2 Changed 5 years ago by strk

It's worst: the actual results depend on some previous state. MEMORY FAULT HIDING !

=# SELECT st_clipbybox2d('SRID=4326;POINT(0 0)','BOX3D(-1 -1,1 1)'::box3d::box2d);
0101000020E610000000000000000000000000000000000000                              
=# SELECT st_clipbybox2d('SRID=4326;POINT(0 0)','BOX3D(-1 -1,1 1)'::box3d);     
ERROR:  gbox_overlaps: cannot compare geodetic and non-geodetic boxes           
=# SELECT st_clipbybox2d('SRID=4326;POINT(0 0)','BOX3D(-1 -1,1 1)'::box3d::box2d);
ERROR:  gbox_overlaps: cannot compare geodetic and non-geodetic boxes   

Note that the first (succeeding) and last (failing) queries are identical.

comment:3 Changed 5 years ago by strk

Figured, I'm casting a BOX2DF to a GBOX... Now, how to deal with these BOX2DF ? I can't find them defined in any header file. Should I just give up on the idea of using them ? Which BOX should a "ClipByBox2D" take then ? Would it be a BOX3D with a check of it being 2D only ? Or should it be a GEOMETRY with code extracting only bounding box from it ?

comment:4 Changed 5 years ago by strk

As scary as it may be, I also see BOX2D_out doing the same thing I'm doing: casting the pointer to a GBOX. Should I just make a new GBOX and initialize it with values from the lame one ?

comment:5 Changed 5 years ago by strk

Also BOX2D_in is doing weird things, creating a type with a double pointer while scanning the input text for float (not double) numbers.

comment:6 Changed 5 years ago by strk

Resolution: fixed
Status: newclosed

r13034 fixes this by avoiding to use gbox_overlaps with incomplete GBOX values (a BOX2DF casted to a GBOX). It still smells bad, but it turns out being what the rest of the BOX2D related code does...

Note: See TracTickets for help on using tickets.