[GeoNetwork-devel] LuceneQueryBuilder class and spatial search changes

GeoNetwork GeoNetwork Developer
1

Hi all,

I would like to suggest you some changes on the LuceneQueryBuilder class if you mind.
Just to avoid some duplication and to simplify a litle bit the code concerning the geographical search.

This makes me wonder few questions and I would like to share with you for hints if any…

First one is about BooleanClause.Occur clause for the fullyOutsideOf relation query.
It seems that there is only one different value in the case of eastBL parameter with (required = false, prohibited=false) arguments for LuceneUtils.convertRequiredAndProhibitedToOccur instead of (true,false) for all other parameters and other relations.
Looking at the old lucene-utils.xsl file, it appears that this relation was encapsulated into a boolean clause, around the global boolean query, which is not the case in the java implementation… That seems to be a bug for me.

The second question is about bbox values (ie eastBL, westBL, …). Why are we proceeding with a toLowerCase method on each one?
Is there any reason for that??

You will find enclosed a patch, please send me feedback if any.

I also move to the TermRangeQuery since we upgrade Lucene version to 2.9 and the old RangeQuery was deprecated.
But in fact we could use the NumericRangeQuery for that case, what do you think?

BTW, I’m just wondering if it worth to spend time on that or if we should move to spatial search based on spatial index as Simon did for the Bluenet sandbox?

Thanks for your feedbacks,

Ciao,

Mathieu

(attachments)

LuceneQueryBuilder.patch (25 KB)

2

hi Mathieu,

eastBL in fullyOutsideOf should have the the same BooleanClause.Occur as the other ones, it seems to me.

But what was the reason for having the outer Boolean clause in the old lucene-utils.xsl ? The other BB operators do not have that structure.

The toLowerCases() seem useless, indeed.

NumericRangeQuery seems better than TermRangeQuery, although its Javadoc states “NOTE: This API is experimental and might change in incompatible ways in the next release”. And for that matter, all GeoNetwork code is full of deprecated Lucene code, maybe we could upgrade all code at once, when moving to Lucene 3.0 ?

kind regards
Heikki Doeleman

On Wed, Jul 21, 2010 at 11:08 PM, Mathieu Coudert <mathieu.coudert@anonymised.com…> wrote:

Hi all,

I would like to suggest you some changes on the LuceneQueryBuilder class if you mind.
Just to avoid some duplication and to simplify a litle bit the code concerning the geographical search.

This makes me wonder few questions and I would like to share with you for hints if any…

First one is about BooleanClause.Occur clause for the fullyOutsideOf relation query.
It seems that there is only one different value in the case of eastBL parameter with (required = false, prohibited=false) arguments for LuceneUtils.convertRequiredAndProhibitedToOccur instead of (true,false) for all other parameters and other relations.
Looking at the old lucene-utils.xsl file, it appears that this relation was encapsulated into a boolean clause, around the global boolean query, which is not the case in the java implementation… That seems to be a bug for me.

The second question is about bbox values (ie eastBL, westBL, …). Why are we proceeding with a toLowerCase method on each one?
Is there any reason for that??

You will find enclosed a patch, please send me feedback if any.

I also move to the TermRangeQuery since we upgrade Lucene version to 2.9 and the old RangeQuery was deprecated.
But in fact we could use the NumericRangeQuery for that case, what do you think?

BTW, I’m just wondering if it worth to spend time on that or if we should move to spatial search based on spatial index as Simon did for the Bluenet sandbox?

Thanks for your feedbacks,

Ciao,

Mathieu

This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first – http://p.sf.net/sfu/sprint-com-first

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

3

Hi,

On Thu, Jul 22, 2010 at 7:52 AM, heikki <tropicano@anonymised.com.31…> wrote:

hi Mathieu,

eastBL in fullyOutsideOf should have the the same BooleanClause.Occur as the other ones, it seems to me.

But what was the reason for having the outer Boolean clause in the old lucene-utils.xsl ? The other BB operators do not have that structure.

The toLowerCases() seem useless, indeed.

Ok, let me fix it in my patch.

NumericRangeQuery seems better than TermRangeQuery, although its Javadoc states “NOTE: This API is experimental and might change in incompatible ways in the next release”. And for that matter, all GeoNetwork code is full of deprecated Lucene code, maybe we could upgrade all code at once, when moving to Lucene 3.0 ?

You’re right, the NOTE is still there in the Lucene 3.0.2 API. Then, for now, it seems to be better to move to TermRangeQuery and to anticipate the future migration to Lucene 3.x

Cheers,

Mathieu

4

heikki wrote:

[snip]
And for that matter, all GeoNetwork code is full of deprecated Lucene code, maybe we could upgrade all code at once, when moving to Lucene 3.0 ?

Actually it's not that bad any more: the indexing code changes, upgrade to Lucene 2.9.2 and a few fixes since then removed most of the deprecated stuff - just had a brief look and a fiddle and got rid of the remaining deprecated calls fairly quickly. I'll test it out and if ok maybe we can commit the changes and upgrade to 3.0.x for the next 2.6.x release?

Cheers
Simon