SQLite Forum

Timeline
Login

6 forum posts by user boris.gontar

2020-04-29
11:25 Edit: geopoly_json rounding effect (artifact: d9885713d9 user: boris.gontar)

Result of geopoly_contains_point may change when geopoly_json(shape) instead of the shape itself it used.

sqlite> select geopoly_contains_point('[[0,0],[1,0],[1,1.000001],[0,0]]', 1.0/3, 1.0/3);
2
sqlite> select geopoly_contains_point(geopoly_json('[[0,0],[1,0],[1,1.000001],[0,0]]'), 1.0/3, 1.0/3);
0

No wonder because geopoly_json in the second query returns '[[0,0],[1,0],[1,1],[0,0]]'. The problem is that rounding of geopoly_json is inconsistent with rounding used internally (is it geopoly_blob?).

Is it possible to increase precision of geopoly_json to avoid loss of precision in conversion?

2020-04-28
21:38 Edit: geopoly_json rounding effect (artifact: 001c3f6a40 user: boris.gontar)

Result of geopoly_within may change when geopoly_json(shape) instead of the shape itself it used.

sqlite> select geopoly_within(p1._shape,p2._shape) from poly p1, poly p2 where p1.rowid=1764 and p2.rowid=158;
0
sqlite> select geopoly_within(geopoly_json(p1._shape),geopoly_json(p2._shape)) from poly p1, poly p2 where p1.rowid=1764 and p2.rowid=158;
1
sqlite> .sch poly
CREATE VIRTUAL TABLE poly using geopoly()
/* poly(_shape) */;

The _shape's here are pretty long. I can try to reduce them to be usable as a bug report, but first I'd like to know - should I have expected such effect?

15:35 Post: geopoly_json rounding effect (artifact: da4633e3ea user: boris.gontar)
sqlite> select geopoly_within(p1._shape,p2._shape) from poly p1, poly p2 where p1.rowid=1764 and p2.rowid=158;
0
sqlite> select geopoly_within(geopoly_json(p1._shape),geopoly_json(p2._shape)) from poly p1, poly p2 where p1.rowid=1764 and p2.rowid=158;
1
sqlite> .sch poly
CREATE VIRTUAL TABLE poly using geopoly()
/* poly(_shape) */;

The _shape's here are pretty long. I can try to reduce them to be usable as a bug report, but first I'd like to know - should I have expected such effect?

2020-04-23
00:12 Reply: geopoly_overlap return codes (artifact: b62410bd65 user: boris.gontar)

Agreed.

2020-04-22
21:39 Post: geopoly_overlap return codes (artifact: 1844ed59bb user: boris.gontar)

The source code of geopoly.c contains very useful comment on return codes of geopoly_overlap:

**   0     The two polygons are disjoint
**   1     They overlap
**   2     P1 is completely contained within P2
**   3     P2 is completely contained within P1
**   4     P1 and P2 are the same polygon
**   NULL  Either P1 or P2 or both are not valid polygons

The doc page only mentions zero and non-zero return codes. Is it intentional and it's better not to rely on the comment above?

2020-04-18
19:40 Post: geopoly_within doc bug (artifact: 29dd10943e user: boris.gontar)

The documentation states that "geopoly_within(P1,P2) function returns a non-zero integer if P2 is completely contained within P1". In fact it is vice-versa:

sqlite> select geopoly_within('[[0,0],[3,0],[3,3],[0,3],[0,0]]',
   ...> '[[1,1],[2,1],[2,2],[1,2],[1,1]]');
0
sqlite> select geopoly_within('[[1,1],[2,1],[2,2],[1,2],[1,1]]',
   ...> '[[0,0],[3,0],[3,3],[0,3],[0,0]]');
1
sqlite> select sqlite_version();
3.31.1