Le portail francophone de la géomatique

Bonjour,

Mon dernier message sur cette liste appellait debat, et tant mieux ! Nous
sommes tous plus ou moins specialises sur une technologie ou une famille de
solutions, dont nous essayons tous, professionnellement, d'en tirer la
quintessence Or, je crois beaucoup a la complementarite des bonnes
solutions
Quitte a trop detailler au risque d'ennuyer les specialistes, je vais
expliciter un peu mieux certaines opinions, personnelles, qui vous ont fait
reagir. Je pense que de ce debat peuvent naitre des solutions mixtes
reunissant le meilleur des deux mondes ;-)
Plus precisement, je crois a l'interet d'une optimisation de charge entre
client(s) et serveur(s), donc a une reelle convergence des deux. En effet,
dans toute belle solution vectorielle, ou le bitmap d'affichage est calcule
cote client, on affiche un raster, une image non vectorielle, donc non
active , comme fond de plan. Inversement, les solutions serveur, ou le bitmap
d'affichage est calcule sur un serveur distant, stockent elles aussi des
donnees sous forme vectorielle, et peuvent les servir ainsi a la demande
(MapServer en OutputFormat swf , WFS, requete PostGIS, ...).
Les cartes produites cote serveur necessitent effectivement un temps de
calcul, de l'ordre de 50 a 2000 millisecondes, generalement negligeable
devant le temps de transfert d'une page web normale , d'un fichier svg,
svgz, swf, d'un gros fichier vectoriel, ou d'un service web plus complexe.
La meme solution permet de renvoyer au client une carte a imprimer au format
pdf a 300 dpi en un temps raisonnable (tres inferieur au timeout ;-).

Il est vrai que certaines applications comme la geostatistique se passent
souvent d'un raster fond de plan . mais dans nombre de projets, il y a tres
souvent des donnees vectorielles a valoriser sur des fonds de plan raster, a
des echelles tres variees. Comme il ne saurait etre question d'envoyer des
giga, voire des tera-octets de donnees bitmaps ET vectorielles cote client,
il faut bien gerer ca cote serveur ;-)

Ensuite, il est incontestable que les plugins posent des problemes, que Java
pose des probleme aussi, et que le developpeur doit souvent choisir entre un
grand respect des standards et certaines fonctionnalites interessantes mais
qui ne tournent que avec douze plugins sous ie768 ...

Inversement, les solutions performantes cote serveur ne s'appuient pas sur
MySQL, mais plutot sur PostgreSQL Il faut donc effectivement un hebergement
specifique. Comme il existe des hebergements php/MySQL gratuits, ce sera donc
toujours plus cher, pour qui n'a pas son serveur. Il faut quand meme
relativiser ce point: les hebergements MapServer se developpent, les pannes
recurrentes des sites gratuits font hurler les webmasters des sites
concernes, qui finissent par prendre un hebergement pro . Donc si on compare
ce qui est comparable en terme de qualite de service, il faut tenir compte
que les hebergements MapServer offrent generalement un ou plusieurs Go, et
comparer avec le cout du meme espace ailleurs. Si on compte ainsi, MapServer
n'est pas hors de prix.

Concernant AutoDesk, je ne compare pas le leader mondial inconteste de la DAO
sur PC a la ssii du coin ! Mais en comparant a ce qui se passe pour les
systemes d'exploitation ou la bureautique, et en constatant les phenomenes de
concentration en cours sur le marche des SIG proprietaires, je pense
clairement que certains logiciels SIG vont progressivement disparaitre (avant
MapGuide !). Meme IBM, qui n'est pas la ssii du coin , s'est retire de
certains marches domines par Microsoft. IBM invetit egalement des millions de
dollars dans le logiciel libre.
C'est pourquoi l'on risque, en ne prenant pas assez en compte les normes
existantes, ou en s'enfermant dans un seul systeme proprietaire qui ne serait
pas assez communiquant , de ne pas se permettre assez d'interoperabilite
avec ses partenaires institutionnels.
Le respect de standards ouverts, et les licences libres se sont reveles etre
d'excellente garanties pour les utilisateurs, et expliquent par exemple la
domination d'Apache sur le marche des serveurs web.
C'est pourquoi l'ADAE a effectivement publie un ensemble de recommandations,
qui, tout en n'excommuniant personne, preconise l'examen systematique des
alternatives open-source. In fine, personne n'est OBLIGE de s'en servir ;-)
Quand au TCO de solutions libres et de solutions proprietaires, il est a
evaluer en fonction de ses besoins, et de ses ressources. Il s'agit bien la
d'une analyse purement technologique a faire au cas par cas selon les
besoins ET le budget de l'utilisateur final, tels qu'ils sont exprimes.
Souvent, l'interoperabilite entre systemes est une exigence forte. Que les
logiciels utilises soient libres ou non, cela passe et passera a mon avis de
plus en plus par l'usage de formats ouverts et/ou tres largement utilises.

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