Perhaps this is a weird way for me to get deeper knowledge of R trees, and because I vaguely remember that Tyco refers to a specific epoch in which coordinates are defined, but would it be possible to search R tree using a cone, i.e. stars within a cone of certain degree around given star? This would require a trigonometric calculation before comparison can be made but can be done in a single comparison.

Or, since RA and DEC coordinates are not area preserving (nor distance) -- i.e. angle between stars at DEC =0 is bigger than angle between stars at DEC=80 when they are the same delta RA apart -- then maybe instead of defining rectangular FOV in RA and DEC one should be defining rectangular FOV in DEC, sin(RA)? Then one would not need two searches.

The goal is to find neighbors to a given star defined roughly by some metric? Since there's nothing magical in RA , DEC coordinates the metric could use some other coordinates?

Roman

-------- Original message --------

From: "Brian T. Carcich" <

[hidden email]>

Date: 12/18/2013 1:24 AM (GMT-05:00)

To: General Discussion of SQLite Database <

[hidden email]>

Subject: Re: [sqlite] General R*Tree query

On Tue, Dec 17, 2013 at 3:57 PM, Roman Fleysher <

[hidden email]> wrote:

>

> Since coordinate system is spherical, how do you tell that RA=23:59 and

> RA=00:01 are next to each other using usual comparisons?

I don't; usual comparisons won't work so I do two comparisons:

I am usually looking for stars within a convex field of view (FOV),

typically a frustum with a rectangular footprint, so I determine if and

where RA=0=360 crosses that footprint, and break the FOV into two pieces,

from 0<=RA<=loRA and hiRA<=RA<=360, so loRA becomes hira in one search and

hiRA become lora in the other.

There are only three cases: zero, one or two crossings. Zero crossings

means I can do everything in one SELECT; one crossing means either one of

the poles is in the FOV and I search RA=0 to 360; DEC=someDEC to +/-90, or

the FOV touches RA=0(=360) from one side or the other, which reduces to the

zero case; two crossings means the poles are not in the FOV and I can do

two searches as mentioned above, from 0 up to someLowRA and from 360 down

to someHighRA.

There are some edge cases but that is basically it.

I actually handle "two or more crossings" cases the same as two cases, even

though I don't think "more" can happen with a convex FOV footprint. For

any edge (segment of the great circle between two vertices) of the FOV that

crosses RA=0, which is easily determined since I have the vertices in XYZ

coordinates, I insert a vertex in the edge at the crossing, and then

recurse with subsets of vertices split across RA=0.

_______________________________________________

sqlite-users mailing list

[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users_______________________________________________

sqlite-users mailing list

[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users