Le portail francophone de la géomatique

Bonjour,

Pour ceux qui, comme moi, sont moins familiers que Samir DOUADI avec les
notions d'architecture, j'ai trouve des informations interessantes sur ce
sujet a l'adresse suivante :
http://cedric.babault.free.fr/rapport/node1.html

Je partage son avis sur l'organisation actuelle du document, qui me gene un
peu, car elle me semble fondee sur un decoupage en type de produit. Il
serait peut-etre necessaire d'avoir une partie preliminaire qui presente
succinctement et simplement ces notions d'architecture, ce qui permettrait
de resituer ensuite les differents types de produit.

Ce qui me semble particulierement important, c'est la repartition des
charges entre le serveur et le client. En cela certaines solutions SVG
peuvent etre tres proches des serveurs carto (presque tout se passe cote
serveur), et d'autres s'en eloigner completement (beaucoup de chose se passe
cote client).

Un des interets majeurs du SVG – je ne parlerai que du SVG car c'est le
sujet que je maitrise le mieux -, est d'offrir la possibilite de gerer tres
finement cette repartition des charges.

Le SVG est une application du XML et a ce titre il est dote d'un Modele
d'Objet de Document (DOM). Il s'agit d'une interface de programmation
d'applications (API : Applications Programming Interface) qui definit la
structure logique, les modes de gestion et d'acces des documents et permet
un acces dynamique a des documents et la mise a jour de leur contenu, de
leur structure et de leur style par l'intermediaire de programmes ou de
scripts. Chaque objet graphique possede un identifiant tres simple a
recuperer par le biais d'evenements (onclick par exemple), et inversement il
est possible d'atteindre un objet et de modifier ses caracteristiques via
cet identifiant.

Cela signifie qu'avec du javascript cote client, il est possible de faire
beaucoup de chose sans solliciter le serveur, ou en le sollicitant au
minimum.

- Fonctionnalites basiques telles que zoom, panoramique, affichage/masquage
des couches, infobulle.

- Modification du style des objets graphiques, ce qui permet de realiser des
analyses thematiques choropletes par exemple. Pour peu que les donnees aient
ete chargees en meme temps que la carte, la discretisation des donnees et la
modification du style des objets graphiques se passent cote client. Mieux
encore, il est possible de creer des objets (par exemple des cercles
proportionnels), toujours cote client.

- La derniere version d'Adobe SVG Viewer offre egalement des methodes
d'echange avec le serveur, ce qui permet de ne charger des donnees qu'en cas
de besoin. Les applications sont multiples : chargement des couches a la
demande, chargement d'objets graphiques suivant le niveau de zoom, creation
d'objets graphiques cote client puis enregistrement de la definition de ces
objets sur le serveur, chargement des donnees necessaires a une analyse
thematique. Compte tenu des capacite de traitement cote client, il est
possible de minimiser la taille des donnees echangees en les transmettant
sous une forme minimaliste : par exemple au lieu de transmettre la
definition complete d'un cercle (), on ne
transmet que les elements indispensables ( c1|100|200|50 ), et le reste du
traitement s'effectue cote client.
Pour peu que la definition des objets graphiques soit stockee dans une base
de donnees sur le serveur, il est possible d'elaborer des applications qui
ne necessitent pas la creation de multiples fichiers SVG en dur sur le
serveur. Toutes les cartes sont fondees sur un meme squelette SVG de
quelques Ko, modifie et complete de facon dynamique et interactive.

Quelques remarques complementaires sur le document ( partie 2.1 Les formats
vecteurs Internet, caracteristiques)

A propos des interrogations spatiales.
Pour l'instant, a ma connaissance, Adobe SVG Viewer n'offre pas de fonction
elaborees d'interrogation spatiale. Il faut soit construire des fonctions
javascript cote client, mais les algorithmes sont complexes et les temps de
calcul importants, soit stocker sur le serveur la definition des objets
graphiques dans une base de donnees qui permet les requete spatiales
(PostgreSQL+PostGIS par exemple), ou ecrire les fonctions adequates
(PHP+MySql).

A propos des plug-ins
Il existe d'autres plug-ins pour le SVG (Batik, CSIRO,..)
cf. http://www.w3.org/Graphics/SVG/SVG-Impl … tm8#viewer

Les principales difficultes ne proviennent pas des plug-ins eux-memes mais
de la gestion des echanges entre le navigateur et le plug-in. Etant donnee
que le DOM HTML d'IE et de Netscape sont tres differents, il est assez
laborieux d'elaborer une meme page HTML contenant un document SVG pour ces
deux types de navigateurs, pour peu que cette page implique des echanges
entre le document HTML conteneur et le document SVG (ex. formulaire HTML qui
gere la carte SVG, gestion des frames, des div, des layers…).

Sur les inconvenients (2.1.2)

Transformation des donnees de type SIG dans un format adequat : pour peu que
le SIG puisse exporter ces donnees dans un format texte, cette
transformation est relativement simple.

Usage des bases de donnees spatiales difficile (Scans ou BD vecteurs de
l'IGN). Pour les scans, il n'y a pas de difficulte majeure des lors qu'on
dispose des infos de calage. Avec PHP et la librairies GD, il est possible
de creer des tuiles ou meme de generer a la volee un extrait de scan
correspondant au besoin de l'utilisateur. Pour les BD vecteurs, elles sont
disponibles dans des formats texte, me semble-t-il.

Peu oriente travail cooperatif :
pour les donnees alphanumeriques c'est vraiment tres simple
pour les donnees graphiques, il faut ecrire les fonctions.

En fait les inconvenients du SVG sont liees a sa jeunesse. Peu de
bibliotheques de fonctions et d'outils d'importation sont encore
disponibles, mais il s'en elabore chaque jour.

Cordiales salutations

Gaetan GABORIT

PS : comme l'un des participants le reclamait, il m'apparait egalement
souhaitable que chacun precise un peu d'ou il parle . Pour ma part,
j'appartiens a la societe Netagis (http://www.netagis.com) qui elabore des
solutions cartographiques en SVG.

Samir DAOUDI a ecrit:

> Pour ce qui est du planing de ce projet, je suis entierement d'accord avec
> Ludovic sur le lot 1, ou phase court terme, seulement, il faudrait se donner
> des dates butoir pour aboutir a quelque chose de reference en la matiere.
Donner des dates butoir me parait delicat.
- Pour la plupart, nous travaillons sur ce projet sur notre temps
libre, voir personnel.
- Definir un etat arrete peut s'averer hardu, il ya toujours quelque
chose a ajouter. C'est pourquoi je prefere le principe du numero de
version qui donne une idee dans la progression du document. Mais pour
cela, il faudrait tout de meme definir au prealable quelques grands
numeros de version.
Il est donc delicat de donner des contraintes de date.

> Pour ce qui est du draft version 0.2, la table des matieres semble isoler la
> diffusion cartographique sur internet du reste des architectures web standards.
> Alors, que la seule particularite de cette premiere reside au niveau du serveur
> applicatif (serveur cartographique en l'occurence) et les donnees geographiques
> qui viennent enrichir les donnees DBMS.
En effet l'objectif initial etait tres cible. Mais pourquoi pas une
grande partie architecture de la diffusion internet, avec une
orientation rapide vers ce qui est utile pour la cartographie.
Je m'avoue pas assez competent pour me lancer sur le sujet.
Si quelqu'un veut se charger de rediger cette partie ?

> De mon point de vue, je pense qu'il faudrait plus aller dans le sens d'une
> architecture 3 tiers standard avec la seule particularie (serveur et donnees
> geographiques). En effet, tout le reste est commun avec une architecture
> web non cartographique si l'on puisse dire.
Je ne te comprends pas trop, voila des propos qui rentrerai tres bien
dans cette partie architecture web . Attention tout de meme a ne pas
faire de conclusion, peser les points forts et les points faibles de
chaque solution technique, mais pas de conclusions, le lecteur les fera
lui-meme.

> Je pense qu'a terme de ce travail, il faudrait faire en sorte qu'il n'y aurait
> plus d'ambiguite concernant l'etat de l'art en matiere de serveurs
> cartographiques car c'est la ou le bas blesse pour tous ceux qui tentent de
> faire de la cartographie en ligne.
C'est bien notre objectif a tous.

Cordialement
Ludovic

--
LESTRAT Ludovic, Geo-Hyd
386 rue du rond d'eau
45590 Saint Cyr en Val
bur : 02.38.64.01.94 (Direct)
mob : 06.63.36.37.46