2012/5/3 Emmanuel Bernard <emman...@hibernate.org> > Let me see if I understood by rephrasing. I am trying to get a feel of > where conversions happen. > > I am assuming that this is mostly relevant for the boolean query approach > and the later circle memory filtering (ie that quad tree is not involved). > In Quad Tree mode you still have to filter by distance the candidates returned by the Quad Tree. This still applies.
> Today we accept decimal coordinates from the user and store them as is in > the index. But to calculate the right rectangle and then circle filter when > we build a query and later filter elements in memory (circle): > - we convert the query coordinates into radians to find the right box > boundaries coordinates and convert them back into decimals > no : the box used in simple mode is calculated in decimal degrees > - for each matching element in the box we further convert the coordinates > in radian to filter by circle > yes > In the new scheme where radians are stored, we would: > > - receive coordinates from the user as decimals > - convert them to radians once at indexing time and once at query time > yes > So the big difference would be that we avoid the per element in the box > filtering conversion from decimals to radians. > no : the diffrerence is only durring the distance filtering as Sanne said > Am I correct or completely wrong? not completly =) Niko > On 3 mai 2012, at 10:12, Nicolas Helleringer wrote: > > > Hi all, > > > > Sanne and I have been wondering about the way the spatial > > branch/module/functionality for Hibernate Search shall store its > > coordinates in the Lucene index. > > > > Today it is implemented with decimal degree for : > > - easy debugging/readability > > - ease of conversion on storage as we want to accept mainly decimal > degree > > from users data > > > > Sanne pointed out that when the search is done there is quite a few > > conversion to radians for distance calculation and suggested that we may > > store directly coordinates under their radians form. > > > > I have tried a patch to implement this and as I was coding it I feel that > > the code was less readable, in the coordinates normalisation mainly and > > that there was as many conversion as before. > > Conversions had moved from search to import / export of coordinates in > and > > out the spatial module scope to user scope. > > > > What the docs does not tell (yet), is that we are waiting for WGS 84 > (this > > is a coordinate system) decimal degree coordinates input, as these are > > quite a de facto standard (GPS output this way). > > > > Today this is not the purpose of Hibernate Search spatial initiative to > > handle projections. There are opensource libs to handle that on user side > > very well (Proj4j) > > > > So. The question is : shall we store as radians or decimal degree ? > > > > Niko > > > > P.S : Hope it is clear. If not ask for more. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
