Le portail francophone de la géomatique

Bonjour a toutes, et a tous,

Il y a eu ces derniers temps de nombreux messages fort interessants, mais
aussi quelques imprecisions, et meme quelques fausses pistes ...
C'est pourquoi je voudrais - modestement - offrir un petit retour
d'experience.

1) opposition raster/vecteur : c'est a mon sens un faux debat: les
applications traitent toutes des vecteurs, et affichent toutes des rasters
;-) ... Pour l'utilisateur final, seuls les temps de reponses comptent. Des
qu'on a en back-office de vrais bases de donnees geo (volumineuses), la vraie
question est de savoir comment on effectue des requetes, qu'on les traitent
sous forme vectorielle ou non cote client. Pour l'utilisateur final, c'est a
peu pres transparent, a un gros detail pres: la necessite de charger un
plugin pour le vectoriel cote client.
Je travaille sur des applis web-gis qui offent online de meilleurs temps de
reponse qu'un SIG-Desktop de reference , qui lui ne tourne qu'en local .
Lors de demos, la question recurrente est mais vous etes online, la ? ;-)

2) flash/svg: j'ai fait pas mal d'experiences avec svg lors de sa sortie, en
tout cas assez pour en voir les limites, qui tiennent essentiellement a la
pietre implementation des plugins svg ... En ce qui concerne le volume de
donnees transmis, un argument anti-svg recurrent, il revele seulement une
meconnaissance du sujet (cf svgz). Les arguments anti-flash sont souvent
pertinents, mais l'enorme diffusion de flash les contrebalancent au moins
partiellement. Et avec open swf, flash n'est pas si proprietaire que ca, meme
si ce n'est pas une norme w3c.
shockymap, dryade (trop meconnu) , et les realisation du talentueux Eric
MAUVIERE montrent bien qu'on peut faire de jolis choses avec l'un comme avec
l'autre ...
Et pour repondre a Elisabeth BEAUJARD, oui, on peut superposer du svg sur de
l'ecw, comme sur n'importe quelle autre image. Il existe differentes
techniques pour cela.

3) Les solutions proprietaires: ca n'engage que moi, mais je n'aime pas trop
mapguide, comme toutes les solutions proprietaires issues d'entreprises dont
l'envergure n'est pas suffisante pour en assurer la perennite: le client
prend un gros risque avec ce genre de solutions. Est-ce que vous acheteriez
un traitement de texte a la ssii du coin ? ou meme a IBM ? Non ? Vous prenez
du Micro ? En geomatique, c'est pareil, il y a ESRI. Rendont toutefois
justice a ESRI: ce n'est pas Microsoft, et le respect du client y est
superieur. Neanmoins, les memes causes (la logique proprietaire) produisant
les memes effets, ESRI se fait regulierement incendier pour certains choix
strategiques (cf liste geomatique ces jours-ci). Je ne dit pas qu'il faut
acheter ESRI: je dit qu'il est aussi absurde de ne pas etudier une solution
ESRI en SIG que de ne pas consulter Microsoft en bureautique ...

4) Du web-mapping au web-gis: jusque la, je n'ai parle que de webmapping, ce
qui focalise trop le debat sur le poste client. Or les utilisateurs ont
besoin de veritables bases de donnees geographiques, de mises a jour,
d'interoperabilite, de requetes spatiales, de traitements geographiques plus
ou moins sophistiques, et de web-services. Et la, il n'existe pas 36
solutions ... La plus puissante, et la plus polyvalente, est le tandem
MapServer-PostGIS. En plus, c'est gratuit: il s'agit de logiciels libres. Il
serait tout aussi absurde de ne pas examiner cette famille de solutions que
d'acheter au prix fort Micro office sans avoir evalue openoffice
(www.openoffice.org: c'est gratuit, c'est libre, et ca marche aussi sous
windaube). Certains grands comptes ne s'y sont pas trompes ... Cote client,
on utilisera indifferement une sortie sous forme d'image pour une conformite
w3c totale, du swf, du svg, ou du pdf ...
J'ai realise recemment (pour camptocamp.com) un web-gis qui offre l'upload, le
download, les requetes spatiales, et tout un ensemble de fonctionnalites
encore hier reservee au SIG desktop, et fort peu courantes sur le web ...

5) Enfin, qu'on s'oriente vers du libre ou du proprietaire , il faut
raisonner en terme de TCO, et ne pas s'arreter au prix (ou a la gratuite) des
seuls logiciels & donnees ... Pour comparer vraiment, il faut tout compter,
et bien compter ;-)

Aussi, sans preconiser telle ou telle solution generique completement
deconnectee d'une analyse des besoins d'un projet precis, je voudrais
proposer quelques elements utiles a prendre en compte par celles et ceux qui
devront realiser des cahiers des charges:

- conformite w3c stricte (les fioritures devant etre facultatives, selon
l'equipement de l'internaute ou de l'intranaute ).
- separation fonctionnelle entre sgbd geo, serveur d'appli et serveur web.
- separation entre logique applicative, design du site, textes, donnees. ...
- respect des normes mondiales (w3c, OGC, ISO, ...)
- examen systematique des alternatives open-source (a fortiori pour les
organismes publics, tenus de respecter la circulaire du 4-12-2002 - cf site
ADAE).

Il ne s'agit que la ni plus ni moins que des canons actuels de developpement
d'applications web, qui evoluent toutes peu ou prou vers la notion de
web-service. A l'heure des WMS et des WFS, il serait absurde que les web-gis
restent a l'ecart des evolutions generales des applications web, car c'est le
chemin de l'interoperabilite.

Geomatiquement votre,
--
Daniel FAIVRE, webmaster@texte-a-enlever.geomaticien.com