SCM

[#1010984] sbox bug in pgsphere-1.1.1

View Trackers | Bugs | Download .csv | Monitor

Date:
2011-02-01 16:37
Priority:
3
State:
Open
Submitted by:
Tim Axelrod (taxelrod)
Assigned to:
Nobody (None)
Category:
Group:
Resolution:
None
Category:
Group:
Resolution:
None
Summary:
sbox bug in pgsphere-1.1.1

Detailed description
pgsphere-1.1.1 + postgresql 8.4.5 gives the following results:

MonetPlates=# select spoint '(0, 1.31)' @ sbox '( (5.162, 1.30), (5.160, 1.32) )';
?column?
----------
t
(1 row)

MonetPlates=# select spoint '(5.161, 1.31)' @ sbox '( (5.162, 1.30), (5.160, 1.32) )';
?column?
----------
f
(1 row)

The results are clearly incorrect. This comes, I believe, from an error in the code for sbox_cont_point() in box.c, which I have corrected in the attached file. The above queries now work correctly.

Followup

Message
Date: 2015-09-02 13:32
Sender: Markus Nullmeier

Well, the documentation unfortunately does not specify too clearly the exact set of spoints an sbox is supposed to made up from. But it apparently turns out that longitude intervals with "switched" borders, such as [5.162 .. 5.160] in this case, are considered to be crossing 2 * Pi, resulting in the complement of the non-switched variation.
Here, this comes down to [5.162 .. 2 * Pi] U [0 .. 5.160] and this is what sbox_cont_point() implements. In this way, sboxes are at least oblivious to shifts of the prime meridian.

Thus, the example above are to be expected.
Date: 2011-02-01 20:38
Sender: Robert

Do you have a diff for your change?

Attached Files:

Attachments:
box.c

Changes:

Field Old Value Date By
File Added588: box.c2011-02-01 16:37taxelrod
Powered By FusionForge