[migration] Passage à PG

[sly]

ça avance !
Rien de tel qu'une après midi de libre pour faire avancer le code.

A priori, les fonctions d'accès aux points refonctionnent avec du spatial plein les pattes ! et ça dépote !

le calcul de distance, de bbox, d'appartenance : tout est fait avec postGIS.

Quelques détails encore (moins les bugs) à contourner ou améliorer mais le principal est là (le reste avec des FIXME)

J'attaque la questions des commentaires qui ne fonctionnent pas (problème avec PDO->prepare bindValue( ) qui ne semble pas marcher)
Mais je tente une autre option, sans imposer, ou je me passe de cette méthode de prepare avec requête mutante à rallonge.

Mes objectifs pour les commentaires :

Code : Tout sélectionner

$conditions->id_point -> pour récupérer tous les commentaires d'un point particulier du site
$conditions->id_commentaires -> pour récupérer les commentaires dont les ids sont au format 45 ou 78,412,4
$conditions->avec_photo -> pour ne prendre que ceux avec photo (saisir "oui" ou "non" par défaut c'est tous)
$conditions->limite -> pour imposer une limite au cas où
A venir :
$conditions->id_auteurs -> pour récupérer les commentaires dont l'auteur est id_auteur au format 4 ou 7,8,14
$conditions->auteur -> condition sur le champ "auteur" pour les utilisateurs non authentifiés
$conditions->texte -> condition sur le contenu du commentaire
$conditions->id_polygones -> commentaires ayant eu lieu sur un point appartenant aux polygones d'id fournis

Et j'ai peur que ça soit particulièrement indigeste avec une requête en "prepare", donc je tente une variante ou je mutualise tout dans une fonction. je comprends bien que des if en php ou des if en SQL ça fait le même merdier à la fin, mais je trouve plus propre que la requête envoyée ne fasse que ce qui est nécessaire. Mais question de point de vue.
Je tente, ça devrait être rapide et on compare

[Dominique]

je comprends bien que des if en php ou des if en SQL ça fait le même merdier à la fin, mais je trouve plus propre que la requête envoyée ne fasse que ce qui est nécessaire. Mais question de point de vue.
Je tente, ça devrait être rapide et on compare

Pas sur au niveau des perfs (mais il faudrait voir la requette: sur un champ calculé, j'ai bien peur que ça revienne au même, sinon, ça doit valoir le coup)

[sly]

je pense que au niveau perf, ça doit pas changer grand chose et même si l'un est 5 fois plus rapide que l'autre, c'est de toute façon pas là que se situera le temps de calcul. Vu que ce qui contera sans doute sera le tant d'execution de la requete et de la récupération des données.

Si y'a 5 "if" qui se battent, ça va pas faire bien de différence.


Mais ce qui m'inquiète moi c'est la flexibilité : on veut limiter le nombre de requêtes écrites, donc on essaye d'en faire par exemple 1 seule à 1 seul endroit pour tout ce qui ira récupérer des commentaires.
Mais pour notre requête qui a besoin d'être un minimum mutante, et peut aller d'un simple :
select * from commentaire where id=5;

à une plus complexe avec plusieurs conditions et des appels (ou non) à d'autres tables.

Et autant je vois que : https://github.com/sletuffe/www.refuges ... d.php#L136

C'est super propre est bien lisible (puisque la requête n'est pas obscurcies par multiple variables qui peuvent cacher plein de trucs)
contrairement à ici :
https://github.com/sletuffe/www.refuges ... s.php#L263
(pour la même chose)

Mais j'ai quand même l'impression que pour les cas complexes, php nous offira plus de flexibilité (et d'habitude) que de faire en SQL des conditions sur : on veut une photo ou pas, on veut %toto% dans le commentaire ou pas, on veut les infos du points qui y sont rataché, etc.

[sly]

Sinon, ça commence a avoir de la tronche : http://sly.refuges.info/

[sly]

Je me suis re- bagarré un petit moment avec cette histoire de migration (on dirait ce qu'on voudra mais y'a bien 36 SQL différents), j'ai dû reprendre au moins 50% des requêtes tant plus rien ne marchait pareil entre PG et My.
Et il ne faut plus se leurrer maintenant, la portabliité de notre code n'est toujours pas garantie si on choisi de revenir à MySQL par exemple. Tant pis, on va pas faire 5 requête au lieu d'1 sous prétexte de mettre la portabilité avant toutes choses.

Donc voilà, j'ai charcuté le code, j'ai refais des API internes, j'ai homogénéiser le nom et les méthodes d'appels aux fonctions, j'ai enlever des pan entier de code redondant (ça va plaire à yip), j'ai factorisé toujours un peu plus et je m'approche toujours plus de quelque chose de fonctionnel.

Si on met de coté les cartes qui sont en cours de refonte par yip, je vais bientôt pouvoir déclarer ouverte la chasse aux bugs. Notez que j'ai touché à tout sur tout, et un peu plus, donc il est quasi sûr que j'ai cassé de nombreux appels, mais on verra bien.

Le gros morceau restant, c'est donc la ré-écriture de nav.php pour inclure les fonctionnalités de massif.php et nav.php actuel.

note : les appels aux polygones sur carte ont été homogénésié dans le code à ce format :
http://sly.refuges.info/nav/2/massif/Chartreuse/

2, l'id et le reste doit être considéré comme sans importance et uniquement cosmétique,
http://sly.refuges.info/nav/2/ devant se comporter comme http://sly.refuges.info/nav/2/massif/Chartreuse/ et comme http://sly.refuges.info/nav/2/ce-qu-on-veut-bigre

[sly]

Bon, hier j'ai un peu rêver pour lancer la chasse aux bugs la tout de suite, y'en a déjà 2 bien visible qui nous attendent :

- Gestion des zones
ça http://sly.refuges.info/massifs.php nous sort toute la liste des massifs du monde et le choix de la zone est encore fait en dur dans le code alors qu'on a maintenant tout ça dans notre base.

- MRI ne couvrant pas toute la terre, j'ai chunté la gestion du "choix de carte par défaut" en attendant une solution concernant les zones ou les corresondances cartes <-> pays
http://sly.refuges.info/point/3598/refu ... -Bernardo/

Les deux sont liés en fait, et correspondent à ce qui est aujourd'hui la fonctionnalité "massif.php"

des avis pour faire ça bien ? le nom de la carte par défaut à choisir dans un champ des polygones ?

[sly]

je vais encore radoter, mon on y est presque ;-)

4 Bugs connus restants dont le 1 est à corriger avant la migration :
- /nav/ ne zoom plus sur le massif dont on veut voir les points
- la gestion des "zones" en page accueil et massif affiche un lien vers laquelle on est déjà
- les zones qui ne font apparaitre qu'un seul polygone demandent un clic de plus pas forcément érgonomique, pour résoudre ce problème pas simple, il faudrait calculer si une zone ne contient qu'un seul polygone a afficher et alors choisir de faire apparaitre directement les points plutôt que les "massifs", à régler ultérieurement, je pense, avec la fusion massif/nav et partageant du code avec l'index

** Ajout **
- L'affichage des points OSM (hotel/camping/superette) est à reprendre complètement ou presque

[sly]

Finalement, le cas des points openstreetmap est tombé en marche après une ligne de changée. ça n'empêche pas que la question de tout reprendre pour faire du GIS reste de mise, mais au moins, ça marche comme avant.

[Dominique]

- /nav/ ne zoom plus sur le massif dont on veut voir les points

Je te le laisse

Il faudrait que /modeles/fonctions_polygones.php function infos_polygones($conditions) retourne les valeurs suivantes:
<?=$infos_polygone->longitude_minimum?>,
<?=$infos_polygone->latitude_minimum?>,
<?=$infos_polygone->longitude_maximum?>,
<?=$infos_polygone->latitude_maximum?>

J'ai vu des paramètres de requettes PostGIS qui donnent les enveloppes. Je te laisse les traduire (pas assez confiant en PostGIS )

[Dominique]

- la gestion des "zones" en page accueil et massif affiche un lien vers laquelle on est déjà

J'ai remis la bonne syntaxe de liens
Avec la correction du zoom sur le massif, ça devrait aller mieux
Reste l'Europe sur la page d'accueil qui foire complètement
La reprise de la gestion massif.php / nav.php / accueil sera bien nécessaire, mais après la migration

[sly]

Il faudrait que /modeles/fonctions_polygones.php function infos_polygones($conditions) retourne les valeurs suivantes:
<?=$infos_polygone->longitude_minimum?>,
<?=$infos_polygone->latitude_minimum?>,
<?=$infos_polygone->longitude_maximum?>,
<?=$infos_polygone->latitude_maximum?>

Elle le fait mais sous d'autres noms :
$polygone->sud / ouest / nord / est
et
$polygone->bbox="ouest,sud,est,nord" (format compatible OL et assez courant pour une bbox)

J'ai vu cette idée dans un autre programme et j'avoue que c'est un peu plus court à écrire que ce que j'utilisais avant de longitude_maximum, au choix :
- revenir au format longitude_maximum pour les fonctions de polygones
ou
- passer la fonction infos_points() qui utilise le format longitude_maximum à est

Je n'ai pas de préférence mon logiciel d'édition complète les mots, mais yip semblait en utiliser un qui l'oblige à taper le nom complet

J'ai vu des paramètres de requettes PostGIS qui donnent les enveloppes. Je te laisse les traduire (pas assez confiant en PostGIS )

Elle s'appelle ST_Box2D(la géométrie) et c'est elle que j'utilise dans infos_polygones (ST_Enveloppe fourni le contour externe d'une géométrie)


Note: c'est le seul truc qui me chagrine avec mon système de passer un objet en paramètre (valable aussi si on passe un tableau) c'est que c'est pénible de retrouver qu'est-ce qu'on peut mettre en entrée et on est obligé d'aller lire le commentaire que j'ai mis en début de ces fonctions.
Si l'éditeur de code pouvait en proposer la liste d'une façon ou une autre, ça serait top

[sly]

- la gestion des "zones" en page accueil et massif affiche un lien vers laquelle on est déjà

J'ai remis la bonne syntaxe de liens

Tu parles du menu en haut "Zones couvertes" ?
D'ailleurs, histoire de pousser la logique jusqu'au bout, est-ce qu'on le générerait pas dynamiquement ce menu, histoire de faire une bonne usine à gaz ?

Reste l'Europe sur la page d'accueil qui foire complètement

En page d'accueil ce sont les alpes qui sont montrées et ça marche. Mmmmm ha oui, avant la zone n'était pas si grosse... ha oui, on a pas "Alpes occidentales" dans notre base... je l'ajoute à la main

La reprise de la gestion massif.php / nav.php / accueil sera bien nécessaire, mais après la migration

D'accord avec ça.

[sly]

Reste l'Europe sur la page d'accueil qui foire complètement

C'est déjà mieux, mais un truc m'échappe : alors que j'ai mis une bbox "très serrée" le openlayers continue à garder un "buffer" très très généreux autour de la box que j'ai choisi, et c'est pareil pour toutes les zones en fait.

C'est un comportement que tu as choisi ?
Est-ce qu'on aurait pas intérêt à choisir nous une zone précise et que OL s'y conforme (reste une histoire de ratio à concerver pour éviter que ça ne s'étire par exemple)

[Dominique]

Il faudrait que /modeles/fonctions_polygones.php function infos_polygones($conditions) retourne les valeurs suivantes:
<?=$infos_polygone->longitude_minimum?>,
<?=$infos_polygone->latitude_minimum?>,
<?=$infos_polygone->longitude_maximum?>,
<?=$infos_polygone->latitude_maximum?>

Elle le fait mais sous d'autres noms :
$polygone->sud / ouest / nord / est
et
$polygone->bbox="ouest,sud,est,nord" (format compatible OL et assez courant pour une bbox)

J'ai vu cette idée dans un autre programme et j'avoue que c'est un peu plus court à écrire que ce que j'utilisais avant de longitude_maximum, au choix :
- revenir au format longitude_maximum pour les fonctions de polygones
ou
- passer la fonction infos_points() qui utilise le format longitude_maximum à est

Je n'ai pas de préférence mon logiciel d'édition complète les mots, mais yip semblait en utiliser un qui l'oblige à taper le nom complet

Pas de pb, du moment que j'ai l'info quelque part, je peux adapter le nav.js
Je regarde ce soir

[sly]

Pas de pb, du moment que j'ai l'info quelque part, je peux adapter le nav.js
Je regarde ce soir

J'en ai donc profité pour uniformiser le code de partout, quand on veut parler des éléments d'une bbox, ça devient nord et sud et est et ouest

Note : la fonction renvois aussi un $polygone->bbox au format de la bbox attendue par OL s'il n'y a pas besoin d'accéder spécifiquement à nord ou sud ou est ou ouest