[réflexion] Diffusion par WFS/gml de nos points

Message par **sly** » 27 févr. 2013, 20:57

Ce thème étant éparpillé, je tente de regrouper ici tout ce qui concerne ce débat (désolé pour le charcutage).

J'en rajoute aussi suite à mes cogitations et recherches de la nuit

Message par **sly** » 27 févr. 2013, 20:57

pour feter l'import en PG, j'ai rajouté 2 3 tests avec les points de la base et 2 polygones
et j'ai monté un mini serveur WFS qui les exploite:
http://yip.refuges.info/nav2/zone/
Il a un fichier de conf de 10 lignes , 0 de PHP, 0 de PGSQL, et 10 lignes d'Openlayer pour arriver a ce resultat.
Il affiche 2 couches WFS:
- 1 avec les 3000 points de la base postGIS (ca rame un peu)
-1 avec 2 polygones (trop dur a faire les polys :( )
en WFS c-a-d avec toutes les infos qu'on veut faire transiter avec, contrairement au WKT qui est tout nu.
(OL officiel car j'ai pas réussi a ré-activer les fonctions du OL custom)
Si ca vous plait, perdez pas trop de temps aux exports XML type KML/GPX ... :)

Difficile de se faire une idée là comme ça. Je me doute que pour exporter toute notre base d'un bloc, avec des ronds orange, ça peut ne faire que 20 lignes de config au total. Comme tu aurais pû faire, en php, en seulement 2 lignes sans doute un :
$res=mysql_fetch_object("select ST_GeomFromGML(way) as gml from osm_points");
print($res->gml);

La question étant "le coût de la flexibilité" : Est-ce que customiser nos icones, les noms envoyés, les altitudes, le choix des points affichés, pourront être faire sans y passer plus de temps à trifouiller le tinyows qui est en C avec qui on ne pourra donc que très mal partager du code ?
Et cette question n'est pas simple à répondre sans avoir essayer de refaire ce qu'on a déjà, mettre par écrit la liste de ce qu'il nous faut et voir étape par étape si le tinyows est capable de faire tout ça

Message par **sly** » 27 févr. 2013, 20:57

yip a écrit :
sly a écrit : La question étant "le coût de la flexibilité" : Est-ce que customiser nos icones, les noms envoyés, les altitudes, le choix des points affichés, pourront être faire sans y passer plus de temps à trifouiller le tinyows qui est en C
<...>cette question n'est pas simple à répondre
Très simple pour moi ;)
jamais il ne me viendrait a l'idée de regarder dedans la boite.
de modifier une "brique", c'est LA source d'ennuis par excellence.
Après, exit les Howto, correctifs et autres tutoriaux glanés sur le net...
alors de deux choses l'une: ou bien tinyows (le WFS) fonctionne comme il est prévu pour, ou bien ca part a la benne. et on retourne sur le scripting XML a la mano, et la reception chez OpenLayers a la mano.
La brique sera intacte, et petite ou ne sera pas ;)
Pour la conf c'est pas pareil :roll: ...

je pensais a tout ce code dans les fonctions d'export (qui ne gere pas les polys a trous par exemple) en PHP, puis dans les fonctions d'import en Openlayers GMLSLD.
A mettre en balance avec les heures qu'il faut passer a fabriquer des schemas XML aux petits oignons pour le WFS, si toutefois c'est possible. :roll:
(La couche de transport est du GML, ou du GeoJSON, mais c'est invisible)
et peut etre quelques macros PGSQL complementaires pour lier quelques tables comme point avec poin_gps .

sly a écrit : <..>voir étape par étape si le tinyows est capable de faire tout ça
Sachant que nos outils supporteraient en natif WFS-T 1.1.0, la question est:
WFS-T 1.1.0 convient-il ?
En fait tinyows ou autre chose, je suis pas sectaire, peu importe. c'est juste le plus petit et le plus leger que j'ai trouvé.
Je vais regarder ca, et le protocole WFS finira peut etre a la trappe aussi.

Message par **Dominique** » 27 févr. 2013, 20:57

Je n'ai pas tout suivi (désolé, dispo quasi nulle)
Dites moi s'il y a des modifs à apporter à OL

yip · Message par **yip** » 28 févr. 2013, 18:21

Dominique a écrit : Dites moi s'il y a des modifs à apporter à OL

Dur sans savoir exactement ce qu'il y a dans le OL maison.
On fait quoi? on part sur du WFS ? comment ?
Je vous fais une présentation pour vous faire une idée ?
Si on part la dessus, ca changera beaucoup de chose pour la programmation OL.

Pour OL, je sais pas, qu'est-ce qui a été enlevé et rajouté par rapport à l'officiel 2.12 ?

j'ai vu que tu as créé une série de constructeurs de Layers en mode XYZ et OSM
Tu as aussi fais des patchs pour le textsymbolizer en SLD ?
les transfos d'EPSG peuvent-elles se gérer en OL officiel comme la doc semble le dire ?

sly: - d accord pour le SQL mixé au PHP, c'est plus lisible que le SQL mutant.
- OK pour les URL de nav, mais ça dépend d'OL et de ses choix techniques.

Message par **sly** » 28 févr. 2013, 18:30

yip a écrit : On fait quoi? on part sur du WFS ? comment ?

Aucune idée, je ne perçois pas l'état actuel des choses, les complications et avantages. Ça fait un peu trop longtemps que je n'ai rien trifouillé coté client ayant honteusement laissé cette partie à dominique, mais ayant bien plus géré le coté serveur.

Je vous fais une présentation pour vous faire une idée ?

Je suis tout ouïe et dispo dans le bar du coin et déjà sur IRC ou par email ;-)

- OK pour les URL de nav, mais ça dépend d'OL et de ses choix techniques.

Je pensais surtout au coté navigateur et internaute, ce que fais OL et les appels qu'on choisira de lui faire faire, c'est à la sauce qu'on veut

Message par **Dominique** » 01 mars 2013, 12:56

Bienvenu au club !

Message par **Dominique** » 01 mars 2013, 13:57

Réponse à post http://refuges.info/forum/viewtopic.php?p=18338#18338 ce post et MP

A priori, je serais fana d'un SW déjà fait pour passer directement de PG à WFS. En tout cas, il faut essayer !

+ Evite un gros paquet de PHP

C'est l'idée directrice

un vrai PostGIS va permettre plein de simplifications et de standardisations

? C'est quoi cet outil?

L'equivalent du WMS pour le vectoriel. un export en OGC standard peut aussi permettre a d'autre site d'afficher en live les poins WRI (comme les points WRI sur les cartes chemineur ...

ok c'est pas nouveau, sur des softs SIG de PC, de phone)
Le soft lui meme est le plus petit que j'ai trouvé avec une conf XML ultra simple.

Est ce que je peux avoir accès à un serveur de ce flux pour faire qqus tests

Pour tester sans OpenLayers, tu prends un lecteur de flux OGC, comme Gaia, tu fait pointer un nouveau layer WFS1.1.0 sur yip.r.i/tinyows/tinyows.cgi
Si tu veux faire des tests en reel: yip.r.i/nav3

? Comment est déclaré / envoyé le style ? Logiquement dans l'outil qui ajoute un StyleMap ? ou faut il le gérer à la main en JS / récupérer un SLD ...
# J'aimerais ne pas perdre la puissance du SLD

Oui, le protocol WFS ne gere pas les styles.
donc j'ai repris ton SLD, et OL applique le SLD aux layer via StyleMap. en gros, Il faut charger le SLD via OL avec read.format.SLD(URLduSLD) après avoir créé les layers.
les variables du SLD telle "property.Equal-to" ... restent applicables, et permettent d'ailleurs de changer l'icone en fonction du point par exemple

? Quid de l'export avec limite (aujourd'hui à 120 POI) pour ne pas charger JS quand on a un BBOX large ?

dans le fichier config.xml, il y a une variable LIMIT. pour chaque requete.
Le protocole peut aussi renvoyer un truc s'il a atteinds la limite mais je sais pas comment OL receptionne.

J'aime bien l'idée des vues PG car le boulot est fait au plus prés de la BDD donc, en principe, optimisé

Faut esperer... comme il est collé au PG et programmé pour ça, le mini serveur WFS est censé booster dans ses requetes.

Pas de pb d'en faire beaucoup puisque c'est lisible

Au depart, mon idée c'est 1vue = 1layer OL. pour simplifier le code JS.
ce qui permet de ne plus faire de checkbox, mais d'utiliser directement le layerswitcher d'OL.

mais le compromis, c'est que du coup, ca fait un paquet de vues PG. faut pas vouloir rajouter des type_cabane type_poly tous les 4 matins...
tu peux voir les vues dans l'interface de PG, rubrique vues.

Sur la question vues VS filtres, la complexité étant proportionnelle au nb de vues + nb de filtres, la puissance (combinatoire d'utilisation) au produit des 2, l'efficacité max est quand V = F. Je dirais qu'il faut mixer les 2
- Multiplier les vues en ce qui concerne les types d'info (à définir)

L'invariable est celui la : 1 vue = 1 flux = 1 layerswitcher "Overlay" OL
Il faut mixer c'est clair. Dans les rares WFS que j'ai vu sur le net, il me semblait que chaque flux correspondait a un seul type d'objet, quite a avoir un nombre de flux WFS important.

- Utiliser les filtres OL pour les coches, ce qui permet de:

Ca revient a dire, se coder soit meme son layerswitcher. car c'est ça en fait, nos coches ne sont qu'un LayerSwitcher sauce maison.
Ca fait du code redondant, qui peut etre fait par le LayerSwitcher d'OL en d'autres circonstances.

* éviter les N chargement de couches WFS

Il faut voir que les N chargement WFS ne sont pas plus lourd que 1 seul chargement WFS.
la liste des cabanes, plus la liste des gites, c'est la meme chose que la liste cabane+gite. (bien sur il y a l' overhead XML, les négo protocolaires diverses et avariées et leur chances de foirage ...)
Bon ok c'est pas pareil, mais la Data utile est la même,
ce qui fait le volume du data, ce sera surtout les polygones à X arretes genre reserve. Ca rends tout le reste negligeable en comparaison.

* permettre de gérer la limite de P POI affichés simultanément (ce qu'on ne sait pas faire avec N chargement de couches)

exact. la limite est par requete. avec 12 vues (12 flux WFS), on a 12x LIMIT. Une limite a 120 peut donc renvoyer 500 points si il y a des centaines de points de chaque type.
en rassemblant tous les infos en 1 ou 2 vues, la limite est respectée. Je vois pas d'autres solution.
Mais le prix a payer en JS est lourd ! (layerswitcher inutilisable, JS conditionnel de partout, ca m'a fait peur c'est pourquoi j'ai refait le test avec 12 vues)

- Il faut que je regarde ce que font ces filtres OL. J'ai vu de loin, mais pas pratiqué

les filtres WFS, c'est la meme syntaxe que les filtres SLD. Un mot clé qui est mal documenté si tu t'interesse aux filtres: filtres CQL. Ils font du Within, Intersects(polygon) et ces trucs la que j'utilise dans nav3.

Idée de YIP à explorer: extraire localement d'OL les autres formats (KML, gpx, GGearth, ...)
+ OL embarque une tripotée de formats, comme c'est codé objet donc modulaire, on doit pouvoir coder 1 fois l'export et profiter de tous les formats
- JS vers disque PC pas trop standard (j'utilise pour l'éditeur une bidouille particulièrement atroce, en attendant HTML5 FileWriter sur tous les explo)
- Vérifier lesquels de ces formats sont codés en lecture / écriture
- Vérifier que ce que produit OL est bien compatible avec GARMIN, ... (C.F. GPSBABEL)
- ça fait beaucoup de JS qui n'a rien à voir avec OL en tant que viewer
? OL n'exportera que ce qu'il voit dans la BBOX. Et si on a un affichage avec limite de nb de points, pas tout. ça peut être un avantage ou pas

Je savais pas trop... on va pas pouvoir utiliser OL pour ca donc.

OL12 modifié standard / pas standard / modifs un peu partout ?
Les modifs sont documentées ici: http://www.refuges.info/ol2.12.1.3/build/build.log.html
- 13 lignes héritées du http://trac.osgeo.org/openlayers/ticket/1249 (qui ne marche malencontreusement pas suite à 1 ou 2 bugs)
- http://trac.osgeo.org/openlayers/ticket/2551 : Apply text symbolizer properties
- http://trac.osgeo.org/openlayers/ticket/2349 : Add label background color and border (+ quelques déclarations pour les activer depuis un SLD)
- http://trac.osgeo.org/openlayers/ticket/2965 : Add halos to vector labels (+ quelques déclarations pour les activer depuis un SLD)
Toutes ces modifs sont pérènes et devraient être releasées OL13

Arf..

j'avais pas vu le changelog...
Tous les change SLD sont vraiment intéréssants. Sans ça c'est du hack de popup OL qui a l'air bien crade...

- Un contrôle LayerSwitcher qui grise les layers out of bounds (une idée piquée à VtTrack)

C'est vrai qu'il ne grise a ce que j'ai vu que les OutOfRange (ce qui est différent)

- Quelques classes Layer/... pour habiller proprement les accès aux fournisseurs
- Quelques classes propres à l'éditeur (qui n'a pas grand chose à voir avec WRI)
Le but final est bien d'avoir une lib OL cohérente dans ses règles de codage, voir officialisée

Cool !

Les baselayer multiprojections ne sont pas une vue de l'esprit, mais bien l'avenir d'OL: http://dev.openlayers.org/sandbox/edgem ... tions.html

Surtout qu'on en bouffe pas mal a cause des suisses (et de notre institut préféré ?)

Je commence à regarder tout ça
OK pour un IRC ce soir ou ce week end, vers 20h

Dac ce soir

edit: on dirait que la complexité va se jouer en nombre d'arrete de polygone, plus qu'en nombre de points. on arrive a 20000 arretes tres vite avec 1 seul poly, 20000 points jamais.
La limite concerne un nombre d'objets, pas la complexité desdits objets.
je sèche là...

Message par **sly** » 01 mars 2013, 14:19

Dominique a écrit : OK pour un IRC ce soir ou ce week end, vers 20h

Merci beaucoup à toi dominique pour cette synthèse, dur de prendre tous les points par le forum et les détailler un à un, mais ce soir, je suis dispo pour être sur IRC vers 20h et même avant.

Ton message nous fourni un plan de discussion, ce qui évitera de partir trop dans tous les sens.

A la lecture de ton message, je te sens bien motivé et tu devrais rejoindre l'avis de yip. Pas de problème, il fallait bien quelqu'un pour trancher ;-) Si les deux masters carte sont d'accord, c'est que mes craintes doivent être un peu trop légères...
Bilan ce soir ;-)

Message par **Dominique** » 01 mars 2013, 19:00

Dominique a écrit :
? C'est quoi cet outil?
L'equivalent du WMS pour le vectoriel. un export en OGC standard peut aussi permettre a d'autre site d'afficher en live les poins WRI (comme les points WRI sur les cartes chemineur ... ok c'est pas nouveau, sur des softs SIG de PC, de phone)
Le soft lui meme est le plus petit que j'ai trouvé avec une conf XML ultra simple.

OK, ja'avis compris. Je veux dire c'est quoi le nom, l'URL, la description, le code

Message par **Dominique** » 01 mars 2013, 19:28

Dominique a écrit :Au depart, mon idée c'est 1vue = 1layer OL. pour simplifier le code JS.
ce qui permet de ne plus faire de checkbox, mais d'utiliser directement le layerswitcher d'OL.
mais le compromis, c'est que du coup, ca fait un paquet de vues PG. faut pas vouloir rajouter des type_cabane type_poly tous les 4 matins...
tu peux voir les vues dans l'interface de PG, rubrique vues.

Dans les rares WFS que j'ai vu sur le net, il me semblait que chaque flux correspondait a un seul type d'objet, quite a avoir un nombre de flux WFS important.

- Utiliser les filtres OL pour les coches, ce qui permet de:
Ca revient a dire, se coder soit meme son layerswitcher. car c'est ça en fait, nos coches ne sont qu'un LayerSwitcher sauce maison.
Ca fait du code redondant, qui peut etre fait par le LayerSwitcher d'OL en d'autres circonstances.
* éviter les N chargement de couches WFS
Il faut voir que les N chargement WFS ne sont pas plus lourd que 1 seul chargement WFS.
la liste des cabanes, plus la liste des gites, c'est la meme chose que la liste cabane+gite. (bien sur il y a l' overhead XML, les négo protocolaires diverses et avariées et leur chances de foirage ...)
Bon ok c'est pas pareil, mais la Data utile est la même,
ce qui fait le volume du data, ce sera surtout les polygones à X arretes genre reserve. Ca rends tout le reste negligeable en comparaison.

Bon. Noway. On ne va pas refaire un SwLayer !
OK pour 1 layer par type

Message par **Dominique** » 01 mars 2013, 19:32

Premier essai avec les clusters: http://n.refuges.info/ol2.12.4/clusters.php
Comme au passage j'ai perdu la feuille de style, il affiche des petits carrés sous Chrome et rien sous Moz, mais ça permet un peu de voir comment ça marche
On a un gros point (faudra mettre une icone adéquate) pour un groupe de point qui disparait et est remplacée par les points quand on zoom
On a bien chargement de tous les POI et affichage par groupe. Donc ça fait ramer JS
Aucune utilité pourles points superposés: ils resteront superposés
ça ne me plait que très moyennement

yip · Message par **yip** » 01 mars 2013, 19:34

Wouah je confonds tout
le quotquot, l'edit ...
les neurones chauffent trop

OK, ja'avis compris. Je veux dire c'est quoi le nom, l'URL, la description, le code

nom tinyows
URL tinyows.org , une branche independante de mapserver
description : tiny WFS server, ils se targuent d'etre rapides et OGC compliant. pour ce que j'y connais ... le reste de la description, dans yip.r.i/tinyows ou dans mon post de 3 pages au dessus
code : bah je sais pas, langage C ? c'est une réponse valable ? mais on est bien daccord pour pas se lancer dans de la recompil ?

Bon allez je te laisse bosser

Message par **sly** » 02 mars 2013, 13:14

Donc, après avoir regroupé comme j'ai pu, et suite à notre long débat hier soir ou j'ai appris beaucoup de choses sur WFS, et où j'ai aussi compris en partie pourquoi cette voie de recherche avait tout son sens afin de simplifier un maximum coté interface OL le javascript là ou aujourd'hui nous sommes un peu obligé de codé coté serveur et re-coder coté client.

N'ayant pas pu dormir tout de suite après, je me suis lancé dans une lecture de documentation sur WFS pour percevoir le rôle que l'OGC a voulu lui faire jouer et dans quels type de cas d'utilisation il libère toute sa force.
J'ai passé également du temps à le lecture du format de style standard SLD actuellement utilisé pour me demander si : 1) on ne le sous utilise pas et 2) quel sens y aurait-t-il à lui donner une place plus importante.
J'ai en effet toute de suite penser à la cuisine interne dans notre base pour faire des icones qui changent et c'est une partie que je souhaite refaire depuis longtemps car c'est vraiment ingérable et trop bidouille. base=données mais la représentation de ces données, c'est un style (penser données->HTML->CSS) et le mettre juste au niveau des données est merdique.

== WFS ==
Je crois avoir pigé quand ça s'utilise : quand on veut pouvoir rendre accessible des données par plusieurs applications sur lesquelles on a pas forcément la main. Comme ça n'est pas trop notre cas pour l'instant, ça n'a que peu de sens, et c'est donc se contraindre. Se contraindre oui, mais surtout parce que le tinyows n'est pas adapté à notre besoin : il tape en direct dans la base et on ne peu pas finement fournir ce qu'on veut, comme on veut. Mais ça ne remet pas forcément WFS en cause.

L'une des forces de WFS, c'est d'être capable de présenter les type de donnée qu'il peut fournir (getCapabilities) de manière standard et donc de devenir interfaçable par exemple dans :
- chemineur ou site partenaire
- applications type qgis
et, pourquoi pas, à l'avenir, dans des applis mobile qui saurait gérer un serveur WFS et nous fournirait (voir file sur la mobilité) une option pour laisser le choix de l'appli à l'utilisateur mais lui fournir une méthode de récupération.
*

Et là, mais non yip ne part pas en courant ;-), j'ai pensé à la solution de développer notre moteur WFS sur lequel on a le contrôle et interfaçable avec nos fonctions existantes. J'ai regardé la doc, et ça n'a rien d'incroyable sachant qu'on a déjà l'export GML.
je ne parle bien ici que d'avenir éventuel dans l'optique *

finalement SLD : à coté

Message par **sly** » 02 mars 2013, 13:52

Pour yip : ça serait possible que tu publies ton nav3.php sur github ? (+ modifs liées)

Comme décidé hier soir, je vais nettoyer le plan de travail de tinyows, mais j'aimerais avoir une version dans l'historique git qui fonctionne avec cette solution, rien ne dit que je reparte pas de ça et tente un truc à base de WFS perso.

Ça va te paraître bizarre, mais une fois que tu l'aura publié, je vais le supprimer, c'est pas pour te faire bosser pour rien, mais c'est pour l'arrchiver sur github et j'en ferais une "branche" séparée pour tester