GeneWeb

La révision 5456 n'est pas associée à une demande d'évolution.
Aucune doc n'explique la fonction de ces requêtes, ni leurs paramètres.
Y-a-t-il un prérequis à installer ?
Dans l'état actuel, on obtient une page blanche.

Bonjour Xavier

J'ai pu tester hier la nouvelle fonctionnalité et voici le retour que j'ai fait à Fabien :

J'ai compilé à nouveau GeneWeb pour tester de "Dictionnaire des lieux" et voici mes observations :

- Je ne trouve pas le "point d'entrée" dans la page d'accueil. Comme je suis curieux, je suis allé voir dans welcome.txt et j'y lis

%if;(wizard and (bvar.wizard_passwd_file != "" or bvar.wizard_descr_file != "")) <li> <a href="%prefix;m=MOD_P">[book of places]</a> </li> %end;

Je ne comprend pas la restriction and (bvar.wizard_passwd_file != "" or bvar.wizard_descr_file != "") Être magicien devrait suffire alors pourquoi cette seconde condition ?

Quoi qu'il en soit, je suis passé en surchargeant l'URL par ;m=MOD_P

- J'ai des doubles, triples,..., quintuples !!! Ma base est générée par gwc2 (et non gwc1) et il semble que les lieux sont considérés comme différents suivant l'endroit où l'on indique le lieu : naissance, baptême, mariage, décès, inhumation. J'ai donc du changer 5 fois Saint-Pierre,Crépy (02) par [Saint-Pierre] - Crépy (02). Je ne sais pas si c'est voulu, mais après chaque modif, on retourne à la page de garde des modifs de lieux. À mon sens, c'est ballot. Sinon, ce sera très utile à la communauté.

Dominique

et son retour

Re,

Être magicien devrait suffire alors pourquoi cette seconde condition ?

Ah je ne suis pas très bon en template .... j'ai simplement recopié un test qui faisait la même chose. Je vais le modifier !

- J'ai des doubles, triples,..., quintuples !!! Ma base est générée par gwc2 (et non gwc1) et il semble que les lieux sont considérés comme différents suivant l'endroit où l'on indique le lieu : naissance, baptême, mariage, décès, inhumation. J'ai donc du changer 5 fois Saint-Pierre,Crépy (02) par [Saint-Pierre] - Crépy (02).

Ah quelle terrible nouvelle !!! J'avais complètement oublié que en effet ça n'allait pas tout à fait coller avec gwc2 ! Bon ça ne devrait pas être trop méchant à corriger.

Je ne sais pas si c'est voulu, mais après chaque modif, on retourne à la page de garde des modifs de lieux. À mon sens, c'est ballot. Sinon, ce sera très utile à la communauté.

Oui je suis conscient de cette limitation. Le soucis c'est que si l'on retourne à une autre page, ça veut dire refaire une requête pour avoir les lieux... et en fait pour 99% des bases elle sera quasi instantanée mais pour les très grosse base (roglo, pierfit) le nombre de lieux est tellement conséquent que la requête est importante et je ne voulais pas de timeout ...

Mais j'ai fait pas mal de changement entre la béta 0 et cette version commitée. Peut être je peux maintenant avoir une astuce correcte.

Dominique

lledieu a écrit :

Vous avez ajouté 2 nouvelles requêtes MOP_P et MOP_P_OK dans request.ml. Il ne faudrait pas oublier de mettre à jour la fonction this_request_updates_database dans le même fichier.

Ah merci je n'avais pas connaissance de cette fonction !

En parallèle, je serais très curieux d'avoir un retour de Christian sur les performances de la requête MOP_P_OK sur une base de la taille de roglo en fonction du nombre de personnes / familles impactées. Par sécurité, faut-il prévoir un paramètre de base pour interdire l'usage de cette fonctionnalité ?

J'ai réalisé tous mes tests sur une base de la taille de pierfit. C'est deux fois plus petit que roglo mais tout de même conséquent. Les performances sont très
bonnes (2 secondes en moyenne).

Avez-vous la possibilité de faire un test équivalent avec une base créée avec gwc (et non gwc2 comme roglo) ?

C'est la le seul petit bémol. Je n'ai fait mes tests que sur gwc1 et j'avais complètement oublié que l'indexation des données sur gwc2 serait différentes (d'où les doublons avec une base gwc2 qui correspondent respectivement à un lieu de naissance, baptême ...)
Je suis en train de corriger ce problème et cela devrait être fini (code + test) pour la fin de la semaine (la difficulté étant de garder ces mêmes performances).

J'ai donc du changer 5 fois Saint-Pierre,Crépy (02) par [Saint-Pierre] - Crépy (02)

• chapelle,église, ville
• division, cimetière, ville
  pour ne parler que des occurences les plus courantes

En outre cette nouvelle syntaxe est beaucoup plus complexe (et d'une complexité inutile), en utilisant des caractères à 3 doigts. Ce n'est pas réaliste d'obliger tous les magiciens à de tels changements

Il y a eu une période sur pierfit, où, après avoir imposé des règles plus strictes pour la saisie des lieux, certains magiciens ne saisissaient plus les lieux.

Une concertation aurait été préférable avant la modif...

xgen a écrit :

J'ai donc du changer 5 fois Saint-Pierre,Crépy (02) par [Saint-Pierre] - Crépy (02)

C'est un changement radical dans la syntaxe des lieux. GeneWeb a été conçu avec une syntaxe virgules (la dernière pouvant être remplacées par es parenthèses) et un nombre indéfini de niveaux.

C'est en effet la conséquence de mon oubli (pour le 5 fois) ... mais qui devrait être corrigé pour la fin de la semaine.

Quant à la syntaxe, je suis d'accord sur le fait que GeneWeb fonctionne à la "virgule" et dernière parenthèse,
et je ne pense pas qu'il faille changer cela (au contraire). Il suffit d'ailleurs de changer la phrase sur l'aide pour
la saisie des lieux.

Elle a été mise sous ce format car beaucoup d'autres logiciels mettent le lieux dit entre crochets ... Ce qui
pose des problèmes pour la découpe des lieux (par exemple suite à un import gedcom) ... voir le hack 5411.

Une petite précision : le texte qui figure en haut du dictionnaire concerne GeneaNet et uniquement nous. Il ne sera pas présent sur la version compilé de GeneWeb.

Le fait d'adopter le [] pour indiquer le lieux dit n'est pas forcement l'idéal mais c'est le choix que nous avons fait sur GeneaNet, et nous nous en tiendrons la pour le moment.

Jérôme

Faisabilité et performances :
sur Roglo, le nombre de lieux primaires (ce qui devrait correspondre au nom de pays) est supérieur à 100 000. Le nombre lieu total n'a pas été évalué.

Il faudrait pouvoir restreindre le listage de 2 manières
-nombre max de lieux traités
-tranche alphabétique; par exemple de Rumilly à Saint-Cyr

Le dictionnaire complet pourrait ainsi être exploré complètement, mais par tranche de la taille qui convient pour avoir un temps de réponse acceptable et un affichage limité à 2 ou 3 écrans

Est-il envisageable de faire un affichage structuré des lieux en se basant sur le principe de l'affichage par lieu / patronyme ?

Est-il envisageable de proposer la modification des lieux au sein même de l'affichage par lieu / patronyme ?

Sinon, lorsque j'appelle la requête MOP_P avec le paramètre s égal à un lieu complet existant en base, je me retrouve avec un :
Wserver: uncaught exception: Invalid_argument("index out of bounds")

Est-il envisageable de lister les lieux qui se terminent par une chaîne à l'aide de MOD_P ?

_

En parallèle, je serais très curieux d'avoir un retour de Christian sur les performances de la requête MOP_P_OK sur une base de la taille de roglo en fonction du nombre de personnes / familles impactées._

Le problème est que la requête MOP_P n'affiche qu'une page blanche, même si on ajoute ;s=y
qui ne devrait pas trouver beaucoup de lieux.
Donc je n'ai pas essayé la requête MOP_P_OK sur une grosse base...

xgen a écrit :

Faisabilité et performances : sur Roglo, le nombre de lieux primaires (ce qui devrait correspondre au nom de pays) est supérieur à 100 000. Le nombre lieu total n'a pas été évalué.

Dans le dictionnaire des lieux, il n'y a pas de découpage des lieux
comme pour la requête lieu/patronyme.
Il correspond exactement au lieux texte qui a été entré dans la fiche
d'un individu. J'ai peur que ce soit trop gros sur une base de type Roglo
d'y opérer ce découpage et de s'en servir pour le dictionnaire des lieux.

Pour connaître le nombre total de lieu (unique, attention aux espaces ...),
il suffit de faire MOD_P et la liste liste étant alors trop grosse, on aura
un découpage proposé (comme pour la recherche "tous les patronymes").

Il faudrait pouvoir restreindre le listage de 2 manières -nombre max de lieux traités

Dans la dernière révisons, 5467, le nombre max de lieu à traiter est 10 000.
Il faudrait surement le mettre dans une option pour laisser les magiciens le
gérer avec un choix par défaut (5 000 ?)

-tranche alphabétique; par exemple de Rumilly à Saint-Cyr

Je ne comprends pas cette question. Les lieux sont déjà présentés par ordre alphabétique
avec une limite d'affichage (comme pour la requête "afficher tous les patronymes").
Par contre, là où il y a peut être confusion, c'est que les lieux ne sont pas découpé,
c'est la string complète de la fiche.

Le dictionnaire complet pourrait ainsi être exploré complètement, mais par tranche de la taille qui convient pour avoir un temps de réponse acceptable et un affichage limité à 2 ou 3 écrans

Je ne comprends pas.

lledieu a écrit :

Est-il envisageable de faire un affichage structuré des lieux en se basant sur le principe de l'affichage par lieu / patronyme ?

A première vu, je ne pense pas. Parce que ça voudrait dire découper le lieu,
parcourir toute la base, trouver (un peu magiquement ?) quel est la subdivision
qu'on veut modifier... Ca me parrait plus gourmand que la solution (limitée peut être)
qui est en place.

Est-il envisageable de proposer la modification des lieux au sein même de l'affichage par lieu / patronyme ?

La encore je ne pense pas ... ou du moins pas tout de suite. Peut être que
dans une base parfaitement faite, on pourrait mais là, on a encore le problème de la subdivision.

Une évolution très intéressante serait d'avoir un nouveau type pour la gestion des lieux.
Ce à quoi j'ai pensé pour le moment serait exactement le même fonctionnement que pour la date.
On aurait soit le choix d'un champs texte soit le choix d'un champs découpés pour le lieu.
Cela permettrait beaucoup plus de chose d'ailleurs sur le traitement des lieux.

Sinon, lorsque j'appelle la requête MOP_P avec le paramètre s égal à un lieu complet existant en base, je me retrouve avec un : Wserver: uncaught exception: Invalid_argument("index out of bounds")

Ah oui ! C'est je pense une conséquence du "index_of_next_char". En fait,
en détournant la fonctionnalité en mettant directement un lieu complet, on
cherche tous les lieux commançant par ce lieu et comme il n'y a pas de
caractère après, on a une erreur ...

lledieu a écrit :

Est-il envisageable de lister les lieux qui se terminent par une chaîne à l'aide de MOD_P ?

A l'heure actuelle, avec la compatibilité base1 base2, la seule façon de
récupérer tous les lieux est de parcourir tous les individus et les familles.
Dès que le choix du format gwc2 serait adopté, il faudra alors implémenter les
fonctions first, next, find comme pour spi_first ... afin d'avoir une excellent
navigation dans les indexes de la base.

... donc pour moi, la réponse serait plutôt non.

xgen a écrit :

En parallèle, je serais très curieux d'avoir un retour de Christian sur les performances de la requête MOP_P_OK sur une base de la taille de roglo en fonction du nombre de personnes / familles impactées._

Le problème est que la requête MOP_P n'affiche qu'une page blanche, même si on ajoute ;s=y qui ne devrait pas trouver beaucoup de lieux. Donc je n'ai pas essayé la requête MOP_P_OK sur une grosse base...

C'est très étrange ça. De toutes les combinaisons que j'ai fait
(sauf le lieu complet) il retourne une liste qui est vide au pire
ou une liste à découper sinon ...

Fabien a écrit :

Sinon, lorsque j'appelle la requête MOP_P avec le paramètre s égal à un lieu complet existant en base, je me retrouve avec un : Wserver: uncaught exception: Invalid_argument("index out of bounds")

Ah oui ! C'est je pense une conséquence du "index_of_next_char". En fait, en détournant la fonctionnalité en mettant directement un lieu complet, on cherche tous les lieux commançant par ce lieu et comme il n'y a pas de caractère après, on a une erreur ...

Pas besoin de détourner la fonctionnalité !

Imaginons 2 lieux dans la base :
F
France

Si m=MOP_P;s=F on obtient l'erreur. Il faudrait donc laisser de côté les lieux trop petits par rapport à la taille du paramètre et n'appeler index_of_next_char que si la taille de la chaîne le permet...

Peux-tu essayer d'utiliser une hash table dans la fonction print_short ?

Fabien a écrit :

Une évolution très intéressante serait d'avoir un nouveau type pour la gestion des lieux. Ce à quoi j'ai pensé pour le moment serait exactement le même fonctionnement que pour la date. On aurait soit le choix d'un champs texte soit le choix d'un champs découpés pour le lieu. Cela permettrait beaucoup plus de chose d'ailleurs sur le traitement des lieux.

Personnellement, je préférerais un mécanisme chaîné.

Par exemple "Arras, Pas-de-Calais, France" serait représenté par 3 lieux chaînés :
Arras (lien vers Pas-de-Calais -> France)
Pas-de-Calais (lien vers France)
France (par de lien)

Au niveau de l'événement, on ne mettrait bien entendu que le lien vers Arras.

Ce chaînage devrait permettre de lister facilement tous les lieux rattachés au département Pas-de-Calais.

Petite question pratique :
Est-ce que la fonctionnalité "dictionnaire des lieux" est applicable sur une base créée par gwc2 (5.02) et maintenue par consang (5.02), ou seulement sur une base créée par gwc2 (6.2) ?

xgen a écrit :

Petite question pratique : Est-ce que la fonctionnalité "dictionnaire des lieux" est applicable sur une base créée par gwc2 (5.02) et maintenue par consang (5.02), ou seulement sur une base créée par gwc2 (6.2) ?

100% compatible (5.00 à 6.02), normalement