Re: RE : [sdx-developers] RE : Lucene

[Pierrick Brihaye]

Salut,

Martin Sévigny wrote:

> Qu'est-ce que tu veux dire par deux indexations différentes? Deux
> DocumentBase te permet de le faire.


Bon, je vais expliquer ce que je veux faire. C'est peut-être un besoin 
spécifique, mais la méthodologie me paraît reproductible :

J'ai des documents XML possédant de l'info de géoréférencement. J'ai un 
servlet d'affichage cartographique qui communique avec une BD (sous 
MySQL ou d'autres systèmes ayant une interface JDBC).

Idéalement, pour ne pas avoir à patcher le servlet, j'aurais aimé 
pouvoir, lors de l'indexation, balancer les infos de géoréférencement 
(et l'id du document) dans la base MySQL. Pour cela, il m'aurait fallu 
un accesseur au document d'indexation, parser celui-ci et lancer mes 
"INSERT INTO"... Pas possible tant que je n'ai pas de gestionnaires 
d'évènements car le document d'indexation est complètement encapsulé 
dans SDX. Certes, je pourrais patcher SDX lui-même pour y accéder ;-)

Voilà ce que j'appelle une "double" indexation...

D'un autre côté, je me dis que je pourrais patcher le servlet pour qu'il 
sache lire des index Lucene. C'est tout bénéfice pour tout le monde et 
ça ne me paraît pas trop compliqué à mettre en oeuvre (à condition de 
repackager le servlet, mais c'est moi que ça concerne... et mon 
correspondant russe :-). De plus, j'obtiens tous les avantages que 
propose SDX sur l'exploitation des jeux de résultats. Je suis donc en 
train de m'orienter vers cette solution.

Pour cela, il faut que je puisse convenablement indexer mes infos de 
géoréférencement.

Celles-ci sont au nombre de 6 :

L'info proprement dite. Je peux l'avoir en texte (WKT de l'OGC). Ca 
risque de géver la performance car ces textes peuvent être *très* longs. 
Enfin, en attendant la possibilité de stocker du binaire, on n'a pas 
trop le choix.

J'ai ensuite 4 réels qui représentent les coordonnées de la "bounding 
box" de ma forme géométrique. Pour cela, il faut que j'invente un 
"FloatField" qui stockera des nombres réels en taille fixe (pour pouvoir 
les retrouver grâce à une RangeQuery), un peu sur le modèle de 
DateField. Je pense utiliser floatToIntBits() et... stocker 32 
caractères "0" ou "1".

Le dernier, paramètre est un entier (qu'il faudra convertir en longueur 
fixe) qui identifie le système de géoréférencement. Je ne peux pas 
l'exploiter à l'heure actuelle, mais il faut y penser. Ce n'est pas un 
problème pour l'instant car toutes mes données sont dans le même 
système. A terme, je passerai autant de RaqneQuery qu'il y a de systèmes 
de géoréférencement dans l'index...

La première étape est donc, logiquement la définition des champs.

Quand on a <sdx:field type="word" />, on dit en fait deux choses :
- que le champ est de type org.apache.lucene.document.Field
- que le champ va être tokenisé par un analyser

Quand on a <sdx:field type="date" /> :
- que le champ est de type org.apache.lucene.document.DateField
- que le champ ne sera pas tokenisé

Je voudrais donc, dans un premier temps, que le paramétrage de SDX 
puisse éviter cette double sémantique.

Je proposais donc la possibilité de nommer le type de champ (étant 
entendu qu'au final, tout ça sera transformé en String, en tout cas dans 
le Lucene actuel). On pourrait avoir des trucs du genre "String", 
"Date", "Integer" placé dans le package org.apache.lucene.document donné 
par SDX... mais moi, j'ai besoin de types particuliers que je n'ai pas 
envie d'imposer à tous les utilisateurs. C'est pour cela que je 
proposais de donner un nom de classe (Lucene devrait d'ailleurs imposer 
une interface pour ses champs).

A l'indexation, je suis encore un peu embêté car je n'ai pas les 
coordonnées de la bouding box : je dois les générer (c'est très facile). 
Comme je n'ai pas la possibilité d'accéder au document d'indexation, je 
me demande si je n'ai pas la possibilité d'intégrer des extensions XSL 
(xsl-function du style GetBoundingBox) à la feuille d'indexation...

Je reviens sur la double indexation car, idéalement, quand on veut faire 
des index spatiaux, on utilise un R-Index qui est particulièrement 
approprié. Je pourrais aussi étendre mon servlet avec une interface vers 
un R-Index.


> > Pour cela, il faudrait que les "champs" puissent mentionner 
> > le type de 
> > Field Lucene de façon plus souple que ce qu'on a 
> > actuellement, du genre 
> > un truc qui ferait un Class.forName() sur 
> > un.package.monTypeDeChampLucene.
>
> Pourquoi pas. Il faut définir l'interface...


Ca pourrait être un truc du genre :

<sdx:field type="un.package.unTypeDeChamp" 
tokenizer="un.autre.package.unAnalyseur />

Je conçois bien que pour l'immense majorité des champs, c'est un peu :-o 
lourd, aussi faudrait-il prévoir des mécanismes par défaut.

Voilà où j'en suis.

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden