| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 766 |
3951 d 3 h |
raphael |
/trunk/services/modules/0.1/baseveg/syntaxons/ |
syntaxon: fix d'une notice, Commun->traiterResultat() attend 2 arguments |
|
| 765 |
3951 d 3 h |
raphael |
/trunk/services/modules/0.1/ |
ontologies: follow-up r759 et r762: utilisation de Bdd::MODE_OBJET pour le fetch PDO [dépend de la r429 du Framework] |
|
| 764 |
3951 d 3 h |
raphael |
/trunk/services/modules/0.1/baseflor/ |
ontologies: suppression de l'appel au webservice des ontologies baseflor (InformationsBaseflor) par une requête SQL directe hyper-simplifiée [dépend de la r429 du Framework] |
|
| 763 |
3951 d 4 h |
raphael |
/trunk/services/modules/0.1/baseflor/ |
ontologies: suppression de l'appel au webservice des ontologies baseflor (CommunGraphiques) par une requête SQL directe hyper-simplifiée [dépend de la r429 du Framework] |
|
| 762 |
3951 d 5 h |
raphael |
/trunk/services/modules/0.1/baseflor/ |
ontologies: suppression de l'appel au webservice des ontologies baseflor (InformationsTaxonsSup) par une requête SQL directe hyper-simplifiée |
|
| 761 |
3951 d 5 h |
raphael |
/trunk/services/modules/0.1/baseflor/ |
baseflor: gestion d'erreur: reformulations/typo mineures |
|
| 759 |
3951 d 21 h |
raphael |
/trunk/services/modules/0.1/bdtfx/ |
ontologies: suppression de l'appel au webservice des ontologies "communes" par une requête SQL directe hyper-simplifiée |
|
| 758 |
3952 d 20 h |
raphael |
/trunk/services/modules/0.1/commun/ |
ontologies communes: correction de 2 notices PHP dans le cas de l'absence de passage de
masque et de retour_champs.
Ex: /service:eflore:0.1/bdnt/ontologies/rangTaxo:220/nom |
|
| 751 |
3958 d 4 h |
alex |
/trunk/services/modules/0.1/moissonnage/cartes/ |
Correction bug sur requete SQL |
|
| 750 |
3958 d 4 h |
alex |
/trunk/services/modules/0.1/moissonnage/cartes/ |
|
|
| 747 |
3958 d 4 h |
alex |
/trunk/services/modules/0.1/moissonnage/ |
Mise à jour du web service de moissonnage generant les cartes SVG de repartition des observations pour e-Flore.
Ajout de commentaires dans les classes |
|
| 743 |
3958 d 22 h |
alex |
/trunk/services/modules/0.1/nasa-srtm/ |
Mise à jour de la classe altitude : correction des paramètres acceptés par le web service et ajout d'un cartouche de commentaire en début de code. |
|
| 742 |
3958 d 22 h |
alex |
/trunk/services/modules/0.1/ |
Renommage service altitude. Le nouveau nom du web service est maintenant nasa-srtm (pour être plus en adéquation avec les ressources utilisées que sont les fichiers HGT du modèle SRTM de la NASA) |
|
| 740 |
3962 d 23 h |
raphael |
/trunk/services/modules/0.1/bdtfx/ |
service noms: debug ajout de __FILE__ comme commentaire suffixé aux requêtes
afin de faciliter l'identification des appels en cas d'activation du general_log MySQL. |
|
| 736 |
3965 d 5 h |
alex |
/trunk/services/ |
Ajout d'un nouveau web service altitude qui calcule l'altitude pour un point dont on passe les coordonnees longitude/latitude dans les parametres de l'URL.
Dans le dossier présentations, ajout d'un dossier SRTM contenant les fichiers MNT par secteurs de 1*1 degré, décrivant l'altitude d'échantillons de points situés tous les 90 m |
|
| 735 |
3972 d 3 h |
alex |
/trunk/services/modules/0.1/moissonnage/cartes/ |
Correction bug sur les requêtes de récupération des stations pour un genre donné |
|
| 734 |
3977 d 0 h |
raphael |
/trunk/services/modules/0.1/nvjfl/ |
nom-vernaculaires: support de requêtes multi-critères pour NVJFL, côté client: ACTIVATION
Ce commit active la recherche d'ontologie par multi-critères
pour le web-service de nom vernaculaire JFL.
Un define(), nécessaire mais malheureusement précédemment omis, a été rajouté. |
|
| 733 |
3977 d 0 h |
raphael |
/trunk/services/modules/0.1/commun/ |
ontologies: support de requêtes multi-critères pour les ontologies (partie 2/2).
Lorsque des ontologies sont demandées, celles-ci peuvent désormais être regroupées
au sein d'une même requête.
La modification, portée à Commun/Ontologie.php affecte donc les web-services n'ayant *pas*
redéfini leur classe d'accès aux ontologies, c'est à dire (au 28/06/2013):
* nvjfl
* bdnt
Exemple:
Avant, 3 requêtes:
/service:eflore:0.1/nvjfl/ontologies/numStatut:1
/service:eflore:0.1/nvjfl/ontologies/numStatut:2
/service:eflore:0.1/nvjfl/ontologies/genreNombre:10
Après, 1 requête:
/service:eflore:0.1/nvjfl/ontologies/numStatus:1,numStatus:2,genreNombre:10
Dans le seul cas d'une requête multi-critères le format de retour du web-service
a été modifié: Un ensemble de clef-valeurs est retourné dans lequel chaque clef
représente le nom d'un des critères demandés.
Si un critère ne correspond à rien dans la BDD, celui-ci est absent de l'ensemble retourné.
$ ddiff \
<(GET "http://eflore/$i"|json_pp) \
<(GET "http://www.tela-botanica.org/$i"|json_pp)
# service:eflore:0.1/nvjfl/noms-vernaculaires/attributions?masque.nt=1382&masque.lg=fra&retour.champs=conseil_emploi
# 2 appels d'ontologies nvjfl, résultat identique
# service:eflore:0.1/bdtxa/taxons/13517/relations/inferieurs
# 1 appel d'ontologie bdnt/nom, résultat identique
$ diff \
<(GET http://eflore/service:eflore:0.1/bdnt/ontologies/rangTaxo:70|json_pp) \
<(GET http://eflore/service:eflore:0.1/bdnt/ontologies/rangTaxo:70,rangTaxo:-1|json_pp) \
|grep -v rangTaxo:70
# même résultat (-1 n'existe pas)
Le comparatif suivant provient de l'étude de la requête suivante,
représentative d'une recherche de nom commun (cf: Cel/export XLS):
"/service:eflore:0.1/nvjfl/noms-vernaculaires/attributions?masque.nt=1382&masque.lg=fra&retour.champs=conseil_emploi"
Avant Après
Requêtes HTTP 3 2
Connexions SQL 4 3
SELECT 15 10
Temps sur 300 (*) 1m36 1m30
(*) $ time \
mysql -N tb_eflore<<<"SELECT num_taxonomique FROM bdtfx_v1_01 WHERE num_nom = num_nom_retenu ORDER BY ORD(SUBSTRING(nom_sci, 4, 1)) LIMIT 300;" | \
xargs -i -t -n 1 curl -so /dev/null "http://eflore/service:eflore:0.1/nvjfl/noms-vernaculaires/attributions?masque.nt={}&masque.lg=fra&retour.champs=conseil_emploi";
Le faible différentiel de temps observable s'explique partiellement par le fait que toutes les recherches de nom vernaculaire
n'aboutissent pas systématiquement à l'émission de plusieurs requêtes d'ontologie.
Le différentiel n'en reste pas moins décevant. |
|
| 732 |
3977 d 0 h |
raphael |
/trunk/services/modules/0.1/commun/ |
ontologies communes: fix cosmétiques.
1° usage du paramètre retour.champs qui n'était pas utilisé jusqu'ici et n'aurait
pas pu être utilisé dans le cas d'un retour.format différent de "max".
2° ajout d'un commentaire relatif aux SELECT imbriqués actuellement utilisés et
auxquel une série de JOIN serait à préférer.
3° clarification de formaterOntologiesId()
4° réécriture et renommage afficherDonnees() en calculerClassID().
Une variable est passée par référence en paramètre de la fonction et
les conditions imbriquées sont remplacées par des return rapides.
La gestion des champs demandés est améliorée. |
|
| 731 |
3977 d 20 h |
raphael |
/trunk/services/modules/0.1/nvjfl/ |
nom-vernaculaires: support de requêtes multi-critères pour NVJFL, côté client (partie 1).
Lorsque des données ontologiques propres à la base NVJFL sont nécessaires, celles-ci sont
chargée en une seule fois en tirant parti des requête ontologiques multi-critères.
ATTENTION: le code effectif est encore désactivé (par un if(FALSE...))
car le commit correspondant dans la classe d'ontologie NVJFL n'est pas encore présent.
(partie 2, cf: services/modules/0.1/commun/Ontologies.php)
Le fonctionnement est le suivant:
1) NvjflOntologieIndex()
Concaténer tous les critères nécessaires, exemple: numStatut:1,numStatut:2,...
et faire un lien entre d'une part
* un tableau temporaire associant requête et résultat
et d'autre part:
* le tableau général associant résultat existant [ champs standards ] et requête
2) NvjflOntologieExpand()
Obtenir une URL vers le web-service multi-critère, l'appeler et
enregistrer les résultats à la place qui leur est destinée dans le
tableau temporaire "requête -> résultat"
L'index spécial créé en 1), du tableau des résultats généraux est mis
à jour automatiquement puisqu'il s'agit d'une référence.
3) NvjflOntologieCombine()
Nettoyer les éléments de résultats pour et copier les valeurs demandée dans
un index correctement nommé (dépendant du web-service, et plus directement de
la variable $champ_infos).
Un modèle similaire pourrait être reproduit pour d'autre partie de code effectuant
des requêtes sans que des modification majeures du concept soient nécessaire.
Cependant une manière plus générale d'aborder la résolution consisterait à effectuer
l'indexation à partir des URL déjà générées plutôt que sur les éléments de tableau de
résultats, cependant le faible nombre de web-service supportant le multi-critère et la
diversité des schémas d'URL ne plaident pas en faveur d'une généralisation trop précoce. |
|