[fonctionelle] Api WRI pour l'export points/commentaires/photos

[leosw]

Lut le monde !

Donc dans mon périple, j'ai ajouté à ma version la fonctionnalité pour exporter le contenu de la bbox en GeoJSON, qui ajoute une ligne au select du formulaire des exportations.

Maintenant, pour avoir une application 100% AJAX et sans PHP j'ai besoin d'importer un point, pour l'instant seul l'export des coordonnées existe…
Est-ce que je peux ajouter un export point par point en fonction de l'ID en GeoJSON (ou XML) ?

Le fichier contiendrais le contenu d'une fiche point, avec les liens vers les photos et les 10 derniers commentaires. Et le lien vers cet export serais sur les fiche point avec les exports GPX et KML.

Ça pose un soucis à quelqu'un ? Sachant que je ne suis que sur mon fork à moi. C'est pour le futur que je demande.

Léo

mcapi mcexport

[sly]

Maintenant, pour avoir une application 100% AJAX et sans PHP j'ai besoin d'importer un point, pour l'instant seul l'export des coordonnées existe…
Est-ce que je peux ajouter un export point par point en fonction de l'ID en GeoJSON (ou XML) ?

C'est à dire ?
l'export existe pourtant, mais pas en géojson, tu as un exemple en gml (qui pourrait être simplifié par l'appel à postgis et aux templates dans /vues/exportation, mais sur cette idée, tu peux faire ton export géojson)

Le fichier contiendrais le contenu d'une fiche point, avec les liens vers les photos et les 10 derniers commentaires. Et le lien vers cet export serais sur les fiche point avec les exports GPX et KML.

Tu veux aussi exporter les photos et les commentaires ? sur une appli html5 avec une carte ?
il n'y a en effet pas de fonction pour ça, mais tu en as une pour exporter le point et une autre pour exporter les commentaires si besoin.

[leosw]

Yep, alors j'ai pas bien fouillé le site.

Pour le moment ce que j'ai trouvé c'est exporter une bbox (avec uniquement les infos de bases sur les points) et des exports de coordonnés de points (GPX et KML) mais aucune possibilité d'exporter une page point…

Je me trompe ?

Enfin ce qu'il faudrait, c'est regrouper tout ça dans une page API.php avec en variables PHP GET, les variables action (bbox, page_point, coordonnées), format, id_point (si action=page_point ou coordonnées), et bbox (si action=bbox).

Voilà tout ça.

[sly]

Je remonte ce sujet, non car je vais m'y atteler là, maintenant, mais j'ai l'impression que ça va devenir de plus en plus nécessaire (et la version mobile du site va devenir de plus en plus bancale si elle n'est pas maintenue à jour)
Une API devrait normalement rendre heureux la version mobile, openlayers, et chemineur, je couche donc par écrits mes pensées du moment pour récolter tranquillement les besoins d'une telle API, voire ceux qui voudraient y participer, voir des avis et des idées pour l'avenir.


Une API pour refuges.info
-------------------------
pourquoi faire ?
----------------
Nous utilisons une carte interactive sur notre site (avec openlayers) et le besoin que la partie javascript intérroge
notre base existe depuis longtemps, nous avons donc codé une sorte d'API assez spécifique au besoin d'affichage sur carte, et
conçue dans le but de bien marcher avec openlayer.
Par la suite, une version mobile du site a été créé qui devrait pouvoir s'installer de manière indépendante comme application html5
et là, c'est un peu la bidouille pour l'instant.
Des sites partenaires (comme chemineur.fr) intègrent ou synchronisent nos contenus (points, commentaires et photos) et pour l'instant
c'est un peu fait de bric et de broc

Pour tout ça, une API unique (assez stable) fournissant points et commentaires pourrait vraiment servir

existant (que j’appellerais API version 1)
------------------------------------------------
L'existant, c'est l'appel à:
/exportation/exportations.php
ça n'exporte que des points (pas les commentaires ni photos) et les paramètres sont passés en GET,
le résultat se fait en gml, gpx, json, kml selon le paramètre demandé &format=gml
exemple :
http://www.refuges.info/exportations/ex ... format=gml

La doc de cette API n'est documentée nulle part (ce qui faudrait faire) ainsi qu'une uniformisation avec notre API
interne de récupération d'info pour factoriser ce code.
L'ajout de la récupération des commentaires serait un vrai plus.
Le débat peut continuer ici :
http://www.refuges.info/forum/viewtopic.php?t=5259

[sly]

Déterrage de sujet super vieux !
Auquel j'ai oublié de répondre

Pour le moment ce que j'ai trouvé c'est exporter une bbox (avec uniquement les infos de bases sur les points) et des exports de coordonnés de points (GPX et KML) mais aucune possibilité d'exporter une page point…

Je me trompe ?

En effet, ça manque, aujourd'hui, le mieux qui existe c'est ça :
http://www.refuges.info/exportations/ex ... _point=393
ça une partie de la fiche (alti, coordonnées, description, accès, infos proprio, nombre place, type de point, id interne) au format gpx pour les infos de base, et tout le reste en <extensions> gpx

Enfin ce qu'il faudrait, c'est regrouper tout ça dans une page API.php avec en variables PHP GET, les variables action (bbox, page_point, coordonnées), format, id_point (si action=page_point ou coordonnées), et bbox (si action=bbox).

Totalement d'accord sur l'idée, sur le protocole (GET voire POST aussi tant qu'a faire), sur l'idée du format (kml, gpx, gml, geojson), ça nous permettrait de fusionner l'existant avec une version étendue.
Il faudrait commencer à écrire une page sur cette API sur, ce qui existe déjà et ce qui est utilisé, et voir comment intégrer les ajouts

[leosw]

Je vais essayer de me lancer dans ça, parce que ça me plait, donc faire une doc et un interface API, mais ça implique remplacer les exportations et les points-geojson pour la version mobile.

[sly]

Présent pour discuter+doc !
Je pense que dominique pourrait être intéressé si cette API pouvait exporter aussi les commentaires.

Dans mes rêves les plus fous, cette API pourrait rester retro-compatible avec ce qui existe déjà (ça permettrait d'évoluer en douceur et que le /exportations/exportsions.php puisse marcher comme il marche déjà)

Mais si on voit que c'était pas assez pratique pour réaliser tel ou tel appel, ok pour changer si c'est nécessaire.

Si je trouve un moment, je tenterais de lister ce que faisait l'ancienne API (/exportations/exportsions.php) pour qu'on puisse déjà savoir ce qui était, avant de discuter de ce qui sera

[leosw]

Sinon le plus simple serait de faire un api.refuges.info, avec un nouveau projet git, et de laisser tout comme c'est actuellement sur WRI.

Après, au long terme, WRI questionnera l'API et s'occupera uniquement de la mise en forme. Exactement comme fonctionne la version mobile.

Donc pour commencer, ce qu'il est possible de faire c'est un API pour exporter la recherche dans une bbox/massif dans différents formats.

[sly]

Je n'ai pas encore réfléchis à tout, donc je vais juste donner ce qui me passe par la tête sans réflexion profonde :

Sinon le plus simple serait de faire un api.refuges.info

Héberger sur un autre FQDN me semble à proscrire, si on décide d'un accès par cookie/authentification autant que cela profite de l'authentification générale du site. Je préfère donc un truc genre : http://www.refuges.info/api?*

avec un nouveau projet git, et de laisser tout comme c'est actuellement sur WRI.

c'est pas le risque de dupliquer du code à tour de bras entre l'api et wri ?

Après, au long terme, WRI questionnera l'API et s'occupera uniquement de la mise en forme. Exactement comme fonctionne la version mobile.

ça me semble un peu usine à gaz : sur la version mobile, il existe le besoin d'avoir l'api en local/offline, ce besoin n'existe pas sur le site (sauf les cartes en js) vu que tout est distant.

Appeler (fopen("http://xxx) dans le code php des urls qui appelent le code php pour le formater puis le re-convertir en tableau de donnée php ça me semble se prendre la tête.
Par contre avoir une api http et une api "php" très proche l'une de l'autre pour mutualiser le code ça oui

J'avais comme idée un truc comme ça :
url d'appel : http://www.refuges.info/api?bbox=1,2,3,4&type_refuge=7
pseudo code de "api":

Code : Tout sélectionner

<?php
print&#40;format_export&#40;points&#40;$_GET&#41;,"gpx"&#41;&#41;;
?>

Et si on est en interne du code (donc sans passer par http) ça donnerait :

Code : Tout sélectionner

<?php
$query = new class stdclass;
$query->bbox="1,2,3,4";
$query->type_refuge=7;
$points=points&#40;$query&#41;;
print_r&#40;$points&#41;;
?>

Ainsi, on mutualise au maximum le code, et l'api "interne" permet de simplifier l'appel au données

[Dominique]

Salut

Quelques réflexion assez générales et diverses propositions en vrac

- Je suis fan de l'idée d'API

- Penses tu à une API affichage ou aussi saisie ?

- Faut il partir sur une API "programmme" (PHP) ou XML (URL refuges.info/extractions/format...) ou autre (voyez vous une interface adapté - lecture - écriture genre GML) ?

- Je suis en train d'étudier les apps mobiles. Une appli WRI risque bien d'être mon premier essai et j'aurai besoin d'une API serveur.

- Il serait intéressant pour la modularité du site de sortir la partie gestion des polygones : On peut parfaitement en faire un sous systéme isolé (avec sa partie saisie des polygones et infos) et l'interfacer comme une API. D'ailleurs cette API existe déja : http://refuges.info/exportations/locali ... &lat=45.42 puisque je m'en sers pour localiser les points chemineur (dans une version pas encore livrée).


Autre point de vue : je pense depuis un moment à repartir sur une base PhpBB3, en laissant PhpBB gérer les fiches, commentaires, photos et toute la saisie, recherche, news,... 

Ça permettrait de factoriser un max de code avec PhpBB.

L'idée est d'aller jusqu'au bout de 1 fiche = 1 topic du forum "refuges", avec un template d'affichage similaire à l'affichage de la fiche WRI actuelle quand on veut visualiser le topic comme un point. Les commentaires du point seraient les posts possédant un flag adéquat. Cela permet de factoriser la saisie et de passer rapidement des commentaires de la fiche au forum et vice-versa.

Les données des fiches (mur, poil, ... géographiques) seraient ajoutées à la table phpbb_topics et on laisse PhpBB gérer l'accès lecture/écriture (il y a 2 ou 3 lignes de code à ajouter au kernel pour faire le lien avec le template point).

Pas de crainte, je vois bien comment faire en minimisant les interactions avec le code PhpBB et si j'ai un peu merdé sur la conversion chemineur, c'est surtout au niveau de la synchro et dédoublonage avec les autres sites. Je pense être prêt pour WRI et faire une maquette.

Je maitrise assez bien la récup de bases et les templates.



Pour en revenir au sujet API : il devient trivial avec les templates PhpBB. On peut développer un template "mobiles", un template "XML", ... Ce sont des fichiers à chaque fois bien séparés et indépendants du code PHP du kernel.

Dans ce cas, je prendrais en charge la reprise de l'interface actuel + une sortie flux XML lecture/écriture + une interface mobile si Léo m'en donne la syntaxe.



Autre point de vue qui n'a rien à voir : j'ai acheté récement un smartphone (je n'en étais jusque là qu'au mobile où on parle dedans et c'est tout) et je peine sur WRI

- les cartes sont catastrophiques : impossible de faire un zoom, de changer de fond de carte, de passer plein écran... 

- La localisation ne marche pas, ce qui est un comble sur un mobile

- que constatez vous sur vos mobiles et quels O.S. avez vous ?

Je pensais  que OL 2.12 était compatible mobile mais pas testé = ne marche pas. Gros travail pour moi pour passer sur 2.13 (ou attendre 2.14 qui ne devrait pas tarder ou OL V3 beta qui semble assez stable et sympa sur mobile) et faire un truc qui marche aussi sur smartphone.

- Les pages d'accueil et de points passent assez bien mais pas la barre de menu qui se met en vrac. Et sans menu, on ne va pas loin.

- Par contre, tout se gâte sur les pages de saisie : le CSS [censuré] complètement, la taille des champs varie ridiculemet et on passe son temps à zoomer. De plus, la barre de menu surgit intempestivement (c'est déja le cas mais avec un tout petit écran, c'est redibitoire) notamment sur un pavé de saisie ce qui fait qu'au lieu d'insérer un caractère, on se retrouve sur la page des cartes...

Je n'ai pas encore regardé ce qui pose pb mais  faudra en profiter pour refaire un template de saisie propre.

Quelle est votre expérience de l'entrée de points ou commentaires via mobiles ?

Le but est de se pointer devant la cabane et de créer ou comenter le point en un nombre réduit de clics (devrais-je dire tapotage ?)


Je résume la modularité et factorisation de mes prooositions:

- Un coeur sur base PhpBB3 + un min de modifs au kernel (moi)

- Une moulinette de récup de la base + photos + forum (moi)

- Un template PhpBB standard pour le forum (un de ceux de PhpBB)

- Un template PhpBB à coder pour l'affichage des fiches et des pages d'accueil (moi)

- Un template PhpBB entrée/sorties fiches + commentaires format XML (moi)

- Un template PhpBB spécifique API mobile si Léo m'en donne la syntaxe.

- Un module localisation d'un point par rapport à une base de polyones et données associées (interface ouvert à d'autres sites) localisation.php?lon=5&lat=45  Dans un premier temps, on peut utiliser le site de prod. Aprés, j'apprécierais un coup de main de SLY car je ne me suis pas trop investi dans les postgres.

- Le sous systéme d'affichage de cartes existant mais à reprendre pour une bonne gestion des mobiles et à documenter (il s'agit de javascript entièrement objet suivant les règles de codage openlayers mais une bonne doc ne nuit pas). Point indépendant de la refonte API. Utiliser l'existant pour la maquette.

- Un interface mobile (actuel Léo)

- Une ou des apps smartphone à venir

Difficuté : identifier toutes les petites fonctions bien utiles accumulées au ciurs du temps. Je compte sur Sly


Je vais essayer de faire une maquette de tout ça pour septembre. Je suis sur que vos idées y ajouteront des +. Ma dispo étant incertaine, ne m'attendez pas pour progresser de votre côté.

[leosw]

- Penses tu à une API affichage ou aussi saisie ?

Dans un premier temps je pensais affichage, parce que c'est le plus simple, ensuite saisie si la demande est là et si l'API fonctionne bien.
Je partais sur une idée API PHP, mais j'avoue ne pas comprendre ce que tu veux dire par XML.

- Je suis en train d'étudier les apps mobiles. Une appli WRI risque bien d'être mon premier essai et j'aurai besoin d'une API serveur.

Alors je pense que tout le monde sur Terre est au courant que je fais une appli pour Firefox OS (visible sur leo.refuges.info/mobile) . Cette appli est une WebAPP, c'est à dire qu'elle a de nombreuse fonctionnalités :
* Site web mobile accessible depuis tous navigateur (mobile ou bureau)
* Application intégrée aux smartphones/tablettes... équipés de Firefox OS
* Application intégrée aux smartphones/tablettes... équipés d'Android (Firefox Mobile requis)
* Application intégrée aux PC équipés de Windows (Firefox requis)
* Application intégrée aux PC équipés de Linux(Firefox requis)
* Application intégrée aux PC équipés de Mac OS (Firefox requis)

Autre point de vue : je pense depuis un moment à repartir sur une base PhpBB3, en laissant PhpBB gérer les fiches, commentaires, photos et toute la saisie, recherche, news,...

Je suis désolé mais je suis réticent sur ce point, j'ai toujours privilégié la maitrise totale du CMS et même si c'est plus simple sur certains points, je trouve ça au final plus compliqué... L'utilisation de phpBB pour le forum et l'authentification centralisée est pour moi justifiée, mais pour la gestion des fiches je ne trouve pas, ça limite sur les panneaux d'administration, etc.

Pour en revenir au sujet API : il devient trivial avec les templates PhpBB. On peut développer un template "mobiles", un template "XML", ... Ce sont des fichiers à chaque fois bien séparés et indépendants du code PHP du kernel.

Tu as raison, mais en utilisant un modèle MVC c'est aussi simple, une page php s'occupe de la récupération et mise en variable, la vue n'est autre que le fichier.extension avec l'extension choisie par l'utilisateur. Comme je l'ai fait pour l'export en json des fiches points.

- que constatez vous sur vos mobiles et quels O.S. avez vous ?

WRI est votre oeuvre et j'arrive après la guerre, mais je me permet de critiquer. Il y a eu une mode OL où le manque de choix dirigait tout le monde vers cette librairie, aujourd'hui je pense que les applications migrent toutes vers leaflet (openstreetmap.org pour l'exemple), j'ai utilisé leaflet et j'ai pu tout faire marcher sans rien coder, les plugins existaient déjà tous.


Pour conclure, je suis désolé d'être réticent à phpBB, mais je ne suis pas certain que ce soit le bon choix.

[sly]

API GET -> dans une phase 1, je pense en en effet à de l'extraction de données, donc ni affichage (c'est quoi ça une "api d'affichage" ?), ni ajout/modif mais pourquoi pas pour plus tard.

API XML ? genre XML RPC ? ben pouquoi pas si on me prouve les avantages, mais ça me semble plutôt compliqué pour pas grand chose.

API programme -> de fait, elle existe déjà, c'est l'ensemble de ce qu'il y a dans le dossier /modeles mais j'aimerais rationaliser en fusionnant la syntaxe de l'API php et de l'API GET

phpBB, même (grosse) méfiance que leo. Ce qui fait la qualité d'un programme n'est pas son langage, son framework, son MVC ou autres critères techniques, ce sont les humains qui y passent du temps pour l'embellir (et je commence sérieusement à croire que dans un développement, l'étape initial le "ça marche" c'est 10% du tout avant d'obtenir un truc donc chaque détail a été pensé, chaque protection vérifié, chaque accès modération établie, etc. Et je ne suis pas super chaud pour tout refaire.

Rien n'empêche de faire une démo cependant, mais le risque et de la voir "refusé" et donc temps passé pour rien

smartphone, j'ai android 2.3 avec firefox mobile :

- les cartes sont catastrophiques : impossible de faire un zoom, de changer de fond de carte, de passer plein écran...

OL n'est pas terrible en effet, certains contrôles ne répondent pas, mais ça reste jouable, et pour compléter, y'a www.refuges.info/mobile ;-)

- La localisation ne marche pas, ce qui est un comble sur un mobile

ici ça marche

mais pas la barre de menu qui se met en vrac. Et sans menu, on ne va pas loin.

ici ça marche

- Par contre, tout se gâte sur les pages de saisie : le CSS [censuré] complètement, la taille des champs varie ridiculemet et on passe son temps à zoomer.

ici ça marche.
Seul regret, la saisi des coordonnées plutôt que "je suis devant la porte" ;-) et le viseur jaune que je n'arrive pas à déplacer
L'ajout d'un commentaire semble lui avoir un mini bug, le champ de saisie est énorme, mais j'imagine que ça ne doit pas être trop dur à corriger en css

Difficuté : identifier toutes les petites fonctions bien utiles accumulées au ciurs du temps. Je compte sur Sly :)

Grosse difficulté, car le sly, il n'a pas vraiment envie de refaire sans avoir la sensation que ça apporte vraiment un truc. Et en effet, il y a plein de petits détails de ce type accumulés au cours des demandes qui font que wri est ce qu'il est.

[leosw]

Pour les projets à refuser, vu que c'est fait et que ça va partir à la poubelle, voici une idée de style que j'ai fait pour un projet (abandonné) et qui pourrait bien aller à WRI :

http://leo-serre.legtux.org/OutdoorSports/redirect.php

[Dominique]

Pour les projets à refuser, vu que c'est fait et que ça va partir à la poubelle, voici une idée de style que j'ai fait pour un projet (abandonné) et qui pourrait bien aller à WRI :

http://leo-serre.legtux.org/OutdoorSports/redirect.php

Moi je trouve la présentation très bien
Reste àfaire les pages de consultation de fiche, création de point, saisie de commentaires...

[sly]

Comme promis, une mini page indiquant comment fonctionne l'api actuelle (celle qui exporte des points) et qui est utilisé par :
- OL
- leaflet (confirmation leo ?)
- la page exportation : http://www.refuges.info/formulaire_exportations/
-- qui elle peut servir soit depuis le formulaire pré-cité
-- ou pour des "sites partenaires" mais je ne sais pas si c'est toujours utilisé

http://www.refuges.info/wiki/api-refuges.info/