2012/5/3 Emmanuel Bernard <emmanuel(a)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(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev