No description provided.
resolve ST_Equals TODO
Beware of rounded boxes.
Basically a bounding box may be slightly larger than needed when
it is created by reading the version cached in a serialized geometry.
This is because serialization forces use of floats by ensuring the
float version of the box fully covers the double version.
When reading things back the "fitting" box info is discarded.
Depending on where the values passed to ST_Equals originate
(read from disk or output from another function) the exact equality
It would be fun to try at reproducing this scenario in a regression
test to proof what I'm saying and ensure it's not broken in the future.
If the inputs to ST_Equals are both of type GSERIALIZED, won't both bounding boxes have forced to float somewhere upstream?
There are cases in which the bounding box is not included in the GSERIALIZED.
In those cases, it is computed with full precision when needed.
Your patch seems to be actually only using gbox_same_2d when both
inputs do have the cache, so should be safe.
Only I thought to mention the possibly hiding problem
(may be worth a comment in the code)
I was also thinking about a gbox_same_float using the same rounding logic as gserialized_from_gbox, or maybe a more loose gbox_same_within_tol. Do you think one of those would be preferable?
add gbox_same_2d_float fn and use it for ST_Equals pre-test
Applied to SVN at r13788, thanks
From dbaston <postgis#40> resolves outstanding TODO list item
git-svn-id: http://svn.osgeo.org/postgis/trunk@13788 b70326c6-7e19-0410-871a-916f4a2858ee