Le portail francophone de la géomatique

J'avais effectivement déjà trouver ces documents... mais en fait ça reste abstrait pour moi... En fait j'ai du mal à saisir la différence et du coup la solution idéale par rapport à mon besoin...

Le Ouistiti

En fait, c'est bien ce que j'avais compris... mais dit comme ça bizarrement, ça a fait un déclic...

C'est certainement le deuxième qui sera pour moi le plus adapté...

Merci encore.

Le Ouistiti

Bonjour,

coder quoi ? Un serveur WMS ? Il vaut mieux utiliser MapServer. Mais dans ce cas il y a rien à coder, jsute MapServer à installer et configurer.

Un framework a l'avantage de simplifier le développement.

Y.

Aujourd'hui il est conseillé d'utiliser un système client-serveur avec côté serveur un serveur carto qui propose des services OGC (comme mapserver ou geoserver) et côté client avoir une interface qui gère ces services comme openlayers.

Un framework comme symfony intégrera la lib openlayers pour la partie spécifiquement carto, mais pour la partie design, formulaire et accès BdD autre que carto.

Tu peux visualiser un exemple ici http://rendezvoussurlaplace.com (accès libre et gratuite mais après inscription, techno utilisée symfony, openlayers, postgis et mapserver). La version date un peu mais cela donne l'idée d'intégration de ces techno.

Tu n'as accès qu'au front, pas au back office Non, dans le cas de l'appli présentée nous utilisons mapserver mais pour la mise à jour carto (des points sur une carte) nous mettons à jour directement la base de données  via symfony.

Non, si tu veux utiliser MapFish tu n'auras pas à coder l'interface avec OepnLayers.

non, un framework = des outils pour développer, reste à bien comprendre que ces deux framework n'ont pas le même objectif. Donc ils sont complémentaires. Tu peux soit utiliser Symfony + MapFish soit Symfony + OpenLayers.

Si tu as du temps et de la motivation tu en apprendras beaucoup plus

Y.

Ben si justement, c'est pour cela que j'ai mis un "ou" entre les deux possibilités. Je ne suis pas sur par contre que MapFish client soit plus compliqué qu'OpenLayers pour l'installation et la configuration, j'aurais même tendance à dire/penser le contraire. Je ne parle pas de MapFish server

openlayers et/ou MapFish se chargent de la partie purement carto, si tu as des données attributaires, tu as là encore plusieurs moyens pour mettre à jour tes données attributaires. Généralement cela se passe par un formulaire, puis  gérer la validation des données et enfin les insérer dans la base de données. Cela est facilement mis en place avec un framework tel que Symfony.

Y.

Yves, penses-tu que le fait que la mise-à-jour des données carto soit faite dans votre appli symfony soit uniquement lié à l'utilisation de MapServer plutôt que GeoServer ? En d'autres termes, utiliseriez-vous WFS-T si GeoServer était votre moteur carto ?

Je pense que dans certains cas l'utilisation de GeoServer et WFS(-T) peut être trop contraignante. Par exemple, avec GeoServer, il n'est pas possible de créer une couche WFS représentée par une jointure dans la base de donnée ; à moins de créer une vue dans la base de donnée, mais ceci implique plus de complexité au niveau de la gestion de la base elle même (pour la migration de données, etc.).

Le framework fourni par MapFish ajoute des spécificités géographiques au framework web généraliste Pylons. Ainsi, une application créée avec le framework MapFish est une application Pylons comme les autres mais qui bénificie de fonctions d'ordre géographique spécifiques. Notamment, le framework MapFish permet en une ligne de commande de créer un web service (appelé "layer") pour lire et écrire des objets géographiques dans PostGIS.

Je ne vois pas pourquoi les données géographiques doivent forcément être lues et écrites par l'intermédiaire d'un logiciel dédié, ce sont des données métier comme les autres. A mon sens, l'utilisation d'un framework pour créer une application web est tout aussi pertinente que les données exploitées soient géographiques ou non.

Vos avis m'intéressent :-)

--
Eric

Bonjour,

Bonne question, je ne pense pas que passer à GeoServer poserait problème puisque nous utilisons maintenant 100 % de service OGC (WMS et/ou WFS) pour l'appli. Seules les possibilités de Geoserver en WFS-T pourraient poser problème. La mise à jour passe par symfony uniquement pour des questions historiques (nous utilisions cartoweb3 et donc mapserver).

Comme tu le dis, si l'utilisation de WFS-T est trop contraignante, je n'hésiterai pas à passer autrement, d'ailleurs il n'est pas prévu de passer à du WFS-T juste pour une simple édition carto telle que la notre.

Cela mérite d'être posé et je suis assez en accord même si les besoins (fonctions dans une base de données, connaissance autour des concepts) en font quand même des attributs un peu à part. Si on regarde les autres types d'une base de données, seuls le type géométrique présente cette complexité à mon avis. Cela la rend un peu à part dans sa gestion. Or ces fonctionnalités sont rarement incluses dans les gestionnaires et utilisateur de données spatiale (gestionnaire = BdD, utilisateur = logiciels). Prenons l'exemple de pgsql : il faut une cartouche spatial, postgis, et pgAdmin III ne gère pas les aspects spatiaux des données, et sous Symfony il faut bidouiller

C'est aussi l'avantage que je vois pour MapFish ou GeoDjando, ce sont des framework qui ont pleinement intégré l'aspect géographique. Donc même s'ils peuvent être vue comme des données comme les autres, cela ne l'est pas dans les faits, et c'est bien dommage.

Tout à fait !

Très intéressant et cela pourrait bien tomber Je suis très intéressé par ce plugin MapFish (surtout si geoBI est intégré ). Pour info, l'idée est de faire évoluer notre appli avec une bibliothèque type ext (ou autre, le choix final n'est pas encore fait).

Y.