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" <briantcarc...@gmail.com> Date: 12/18/2013 1:24 AM (GMT-05:00) To: General Discussion of SQLite Database <sqlite-users@sqlite.org> Subject: Re: [sqlite] General R*Tree query On Tue, Dec 17, 2013 at 3:57 PM, Roman Fleysher < roman.fleys...@einstein.yu.edu> 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
