[hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Nicolas Helleringer]

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