Memoire Online - Mise en place d'une plateforme de cartographie dynamique

Dans cette partie, nous allons nous intéressé à une étude comparative de trois système de gestion de base de données qui intègrent des cartouches spatiaux. Il s'agit notamment de MySQL^9(*), Oracle^10(*) et PostgreSQL^11(*). Cette étude à été réalisée par LINAGORA et CampToCamp^12(*) pour le compte du CNES^13(*) qui est le Centre National d'Etudes Spatiales.

Les comparaisons seront effectuées par rapport aux points suivant : Model Objet, Index Spatiaux, Système de Référence Spatial(SRS), Prédicats, Opérateurs, Autres fonctions, Métadonnées.

Il s'agit d'un model constitué essentiellement des objets suivants : Point, Linestring, Polygon, GeomCollection, MultiPoint, MultiLinestring, Multipolygon.

MySQL

PostgreSQL

Oracle

- Point

- Linestring

- Polygon

- GeometryCollection

- MultiPoint

- MultiLineString

- MultiPolygon

- 2D (X-Y)

- Point

- Linestring

- Polygon

- GeometryCollection

- MultiPoint

- MultiLineString

- MultiPolygon

- CircularString

- CompoundCurve

- CurvePolygon

- MultiCurve

- 2D (X-Y)

- 3D (X-Y-Z)

- 3D (X-Y-M)

- 4D (X-Y-Z-M)

- Point

- Linestring

- Polygon

- GeometryCollection

- MultiPoint

- MultiLineString

- MultiPolygon

- Rectangle

- ArcLinestring

- ArcPolygon

- CompoundLinestring

- CompoundPolygon

- Circle

- 2D (X-Y)

- 3D (X-Y-Z)

- 3D (X-Y-M)

- 4D (X-Y-Z-M)

Il permet la gestion des systèmes de coordonnées, le changement de systèmes et la prise en compte de coordonnées géocentriques.

MySQL

PostgreSQL

Oracle

- Stockage SRID

- Pas de gestion des SRS

- Moteur de projection

PROJ4

- Définitions issues d'EPSG

(2670+ systèmes)

- Ajout de systèmes possible

- Pas de transformation

implicite (mêmes SRID pour les objets)

- Faible support des coordonnées géocentriques

- Package SRS: sdo_cs

- Schéma complet

décrivant les SRS

- Définitions issues

d'EPSG (codes EPSG +

codes Oracle)

- Gestion géocentrique

- Conversion d'unités

- Transformations complexes et implicites (filtres uniquement)

- Quelques restrictions

Des exemples de prédicats répondants aux spécifications de l'OGC sont : Crosses, Touches, Within, Disjoint.

Voici une liste non exhaustive des opérateurs répondant à la norme OGC. Il s'agit de Union (mot réservé SQL...), Intersection, Difference, Symmetric Difference(SymDifference), Buffer, ConvexHull.

Tableau 6.7: Comparaison base de données spatiaux : Gestion des métadonnées

Dans cette partie nous présenterons l'évaluation en termes de temps d'exécution et des critères de notations.

MySQL

PostgreSQL

Oracle

- Requête généralement les plus rapides des 3

systèmes

- Jointures entre tables très rapides

- Temps prometteurs

- Jointures entre tables relativement lentes

- Buffer, ConvexHull prenant beaucoup de temps

- Opérateurs performants

- Buffer, ConvexHull très performants

- Jointures entre tables très longues (plusieurs dizaine de minutes)

- Union de gros polygones très longue (plusieurs heures)

- Ordre des opérandes

important

La notation est effectuée suivant les quatre critères suivants : Conformité OGC, Fonctionnalités principales, Autres fonctionnalités, Outillage. Le tableau ci-dessous donne la moyenne associée à chaque système de gestion de base de données pour chacun des critères.

Critères	Note
Critères	MySQL	PostgreSQL	Oracle Spatial	Oracle Locator
*Conformité Norme OGC*	1.5	1.75	1.25	0.75
Portabilité Niveau d'Implémentation Respect des nommages	2	1	1	1
	1	2	2	1
	2	2	0	0
*Fonctionnalités principales*	0.5	1.5	2	1.67
Model Objet Prédicats Spatiaux Opérateurs Gestion SRS Index Spatiaux Coordonnées Géocentriques	1	1	2	2
	1	2	2	2
	0	2	2	0
	0	1	2	2
	1	2	2	2
	0	1	2	2
*Autres fonctionnalités*	0	0.5	2	0
Paquets SIG Gestion Rasters	0	1	2	0
Paquets SIG Gestion Rasters	0	0	2	0
*Outillage*	1	2	1.5	1.5
Outils d'insertion Outils de visualisation/Traitement	1	2	1	1
	1	2	2	2

Figure 6.1 : Représentation de la note de chaque SGBD selon les critères choisis

Si nous avions à effectuer une classification sur l'ensemble des fonctionnalités offertes par les SGBDR étudiés ci-dessus, Oracle Spatial viendrait en tête suivie de PostgreSQL/PostGIS.

Cependant, nous portons notre choix sur le second du fait qu'il n'est pas propriétaire donc libre et gratuit, et qui est quasiment aussi performant que Oracle Locator qui est quand à lui un produit propriétaire et non gratuit.

Le serveur cartographique est le guichet automatique auquel l'utilisateur fait appel pour afficher des cartes sur son poste informatique, il peut être contrôlé par des langages de script tels que PHP, JavaScript, Python ou Perl qui lui permettent de générer dynamiquement une carte en réponse à une requête préparée par une interface utilisateur^14(*).

Dans cette partie nous allons vous présenté trois(3) serveurs cartographiques qui sont : GéoServer, MapServer et ArcIMS.

GéoServer^15(*) est un moteur cartographique Open Source développé en environnement JAVA, et basé sur la librairie GeoTools^16(*). GéoServer implémente de nombreuses spécifications Web Service de l'OGC (WMS, WFS-T, WCS, SLD...), il est de plus application de référence pour l'OGC pour le support de la norme WFS. GéoServer permet de rapidement mettre en place un Web Service proposant données vectorielles et/ou rasters.

GéoServer gère de nombreux formats de sortie pour les données (PNG, SVG, KML, JPEG, PDF, GeoJSON...). De plus il est aisé pour un utilisateur averti de rajouter son propre module de sortie personnalisé pour des données vectorielles. C'est un outil de représentation cartographique lourd. Dans le sens où il nécessite l'installation d'un JDK 1.4 ou supérieur. Il dispose d'une vitesse d'affichage correcte mais d'une finesse d'image supérieure. Son interface est soigné et conviviale.

Cette partie est entièrement consacrée à tout ce qui tourne autour de MapServer

MapServer^17(*) est un programme CGI^18(*) qui s'exécute donc sur un serveur web. En quelques mots, son rôle consiste à piocher dans des bases de données et autres ressources afin de générer des images de type matriciel, qui seront transmises à un client par l'intermédiaire d'un serveur web.

La naissance de cet outil intervient dans un contexte caractérisé par une forte demande de mutualisation et d'accès à l'information. Il est disponible sur de nombreux OS : Unix, Linux, MacOs X, Windows et s'appuie sur de nombreuses librairies libres, telles que la Shapelib pour lire des shapefile, FreeType pour gérer du texte dans les cartes, et Proj4 pour gérer les systèmes de coordonnées et projections. Il existe enfin des API pour plusieurs langages (PHP, Python, Java, Perl, C#).

L'usage "simple" de MapServer consiste à régler quelques paramètres dans un fichier de configuration (le mapfile), et cela suffit pour mettre en place un serveur WMS conforme aux normes OGC.

Dix ans après sa création, MapServer est aujourd'hui devenu une des alternatives les plus sérieuses aux logiciels propriétaires spécialisés dans le webmapping. Son statut de Logiciel Libre aidant, MapServer est en passe de devenir une solution de webmapping de référence grâce à ses performances remarquables et des fonctionnalités de plus en plus nombreuses.

MapServer peut être utilisé en CGI ou avec MapScript. En CGI, Common Gateway Interface littéralement « Interface passerelle commune », MapServer fonctionne comme un exécutable retournant le contenu généré. CGI est le standard industriel qui indique comment passer l'information du serveur HTTP au programme et comment en récupérer le contenu généré.

CGI permet de passer des paramètres au programme, de telle manière qu'il en tienne compte pour générer les données. Avec MapScript, MapServer est commandé par phpmapscript ou javamapscript ou perlmapscript....

Plus dur à mettre en oeuvre, il est aussi beaucoup plus souple et permet d'obtenir précisément le résultat attendu. MapScript est une API^19(*) C qui s'interface avec PHP, Perl, C#, Java. Elle permet d'utiliser les fonctions de MapServer à partir de ces scripts.

C'est l'élément essentiel, la pièce maîtresse de l'agencement et de la sémiologie des couches. C'est lui qui donne les instructions à MapServer. Il se compose d'objets comportant eux même d'autres objets. Un mapfile^20(*) est un fichier texte ASCII structuré en plusieurs paragraphes qui définissent les paramètres de la carte (cadre, échelle, légende et couches). En pratique, il est appelé par un script et renvoie les différentes couches (layers) sous la forme d'images. Celles-ci peuvent provenir de différentes sources telles qu'une base de données spatiale locale ou distante, un serveur distant grâce à une requête GetMap, un fichier géométrique ou image dans le disque dur local par son shapefile.

MAP // Ouverture du bloc map

EXTENT -17.5352 12.0287 -11.3558 16.9701 // définit la fenetre géographique de la carte

IMAGECOLOR 255 255 255 // Couleur d'arriere plan de l'image

IMAGETYPE png // Type de l'image de sortie

SYMBOLSET "C:\wamp\www\ltisig\symbole\symbol.sym« // Chemin du fichier des symboles

SIZE 600 480 // Dimensions de l'image

STATUS ON // Activer le mapfile

UNITS METERS // L'unité de la carte

NAME "ltisig« // Nom du mapfile

OUTPUTFORMAT

NAME "png"

MIMETYPE "image/png"

DRIVER "GD/PNG"

EXTENSION "png"

IMAGEMODE "PC256"

TRANSPARENT FALSE

SUITE du tableau 6.11

END

LAYER // Début d'un bloc Layer (couche)

CONNECTION "user=postgres dbname=ltisig host=localhost« // Connexion à Postgres

CONNECTIONTYPE POSTGIS // Type de connexion : POSTGIS

DATA "the_geom from senegal« // Source de la donnée géographique

LABELITEM «nom« // Nom de la colonne à afficher

NAME "senegal« // Nom de la couche

STATUS ON // Activer la couche

TYPE POLYGON // Type de la donnée géographique

UNITS METERS

CLASS // Debut d'un bloc class

NAME "Territoire« // Nom de la classe

LABEL

.....

END // Fin du bloc LAYER

.......

END // Fin du bloc MAP

Nous détaillons ici de manière schématique le mécanisme d'une requête à un serveur cartographique de type MapServer.

L'arrivée de MapServer dans le monde des serveurs cartographiques a joué un rôle important dans la diffusion de la cartographie dynamique en ligne, non seulement du fait de ses performances et de sa fiabilité reconnues, mais également par la diversité de ses fonctionnalités. Son statut de logiciel libre (qui se traduit entre autres par un code source ouvert) lui confère une certaine richesse de ce point de vue grâce à une communauté active d'utilisateurs/développeurs. En outre, MapServer s'appuie sur des librairies qui s'enrichissent également en fonctionnalités avec le temps. Nous recensons ici quelques caractéristiques importantes de MapServer :

Développé à la base sur des systèmes d'exploitation libres, MapServer est aujourd'hui utilisable sur un grand nombre de systèmes d'exploitation : Windows (95 à XP), Linux, Mac OS X, BSD, Solaris.

Une caractéristique fondamentale de MapServer est sa compatibilité avec les différents types de serveurs web existant actuellement. Il fonctionne aussi bien sur les serveurs libres que propriétaires : Apache, Microsoft IIS/PWS, Netscape Enterprise, NCSA Httpd.

L'utilisation de la librairie PROJ.4 permet à MapServer de projeter des couches à la volée depuis et vers toute projection et système de coordonnées supportés par la librairie (en raster et en vecteur). Un millier de projections sont ainsi prédéfinies.

MapServer supporte directement une grande diversité de formats aussi bien en raster qu'en vecteur. Il lit nativement les images au format TIFF, EPPL, PNG, JPEG, GIF ainsi qu'une trentaine d'autres formats à travers la librairie GDAL.

MapServer peut lire de nombreux formats de données vectorielles : Shapefile, DGN, UK .NTF, SDTS, etc. Cette caractéristique lui fournit une interopérabilité avec la presque totalité des solutions de SIG actuellement sur le marché.

MapServer peut produire des images sous un grand nombre de formats. On utilise principalement les sorties PNG, JPEG, PDF, GIF, BMP, GeoTIFF, etc.

MapServer offre la possibilité de se connecter à différents types de bases de données spatiales (libres comme propriétaires) : PostgreSQL/PostGIS, ArcSDE, Oracle Spatial/Locator etc.

Même si MapServer est à la base écrit en C, celui-ci est compatible avec la plupart des langages et environnement de script actuellement utilisés : PHP, Python, Perl, Rubis, Java et C#.

En plus de ces fonctionnalités de base, MapServer offre une multitude de fonctionnalités annexes permettant entre autres : l'affichage des légendes de la carte, l'affichage d'une carte de référence, l'affichage d'une barre d'échelle, la mise à disposition d'outils de contrôle et de navigation (déplacement et zoom sur la carte), la possibilité de faire des requêtes ...

Cette diversité de fonctions fait aujourd'hui de MapServer un des logiciels de cartographie en ligne les plus complets et les plus extensibles. Ceci est un des piliers de son succès grandissant.

Remarque : Il faut noter que MapServer à lui tout seul « n'est rien ». Il est « manipulé » à l'aide langages de script tels que php, perl, java...

ArcIMS : Serveur cartographique Internet évolutif. Il est beaucoup utilisé pour publier des cartes, des données et des métadonnées SIG à un grand nombre d'utilisateurs sur le Web.

ArcSDE : Serveur de données spatiales qui permet à une application cliente quelconque, de stocker, gérer et utiliser des données spatiales dans un SGBD.

Par contre ArcIMS est le seul serveur qui permet le Webmapping, la publication Web des SIG et qui prend en charge les applications cartographiques Java et HTML nécessaire a notre application. Il s'agit en réalité d'une offre double puisqu'elle comporte deux technologies différentes :

Des traitements Serveur qui affichent des images cartographiques générées par le serveur dans des pages HTML classiques, éventuellement agrémentées de scripts clients pour améliorer les capacités fonctionnelles de celles-ci ;

Une applet Java pour afficher et interroger (requêtes spatiales, analyses thématiques ...) des données vectorielles au format Shape File d'ArcView, transférées au poste client dans un format compressé.

ArcIMS est par ailleurs intégrable avec des solutions plus générales, et dispose d'un véritable gestionnaire de publication, fort utile aux auteurs de sites.

Cette offre se distingue particulièrement par son caractère « serveur centralisé de données géographiques ». Il ne s'agit en effet pas simplement d'une offre pour la consultation et l'interrogation des informations. Plusieurs fonctionnalités originales sont en effet disponibles : extraction de données vectorielles vers le poste afin de réaliser des traitements locaux, croisement des données « classiques » résidant sur le poste client ou sur un réseau local.

GéoServer et MapServer offrent quasiment les mêmes fonctionnalités et les mêmes performances. Certes GéoServer offre un meilleur rendu, néanmoins il nécessite l'installation du JDK avec une version supérieure à 1.4. Il est également très difficile de trouver une bonne documentation pour GéoServer. Notons que ArcIMS est propriétaire et distribué sous licence payante. Par contre MapServer lui hérite d'une large communauté qui évolue rapidement et qui peut s'interfacer avec plusieurs langages de scripts comme php, perl, java, etc. C'est ce qui à motivé notre choix pour MapServer.

L'univers des serveurs web est un petit monde clos, arc-bouté autour de la domination sans partage de deux acteurs : Microsoft IIS^21(*) et Apache^22(*). Selon l'enquête de Netcraft en septembre 2007, IIS possédait environ 34,94% des parts de marché. A pareille date, une autre enquête, réalisée par SecuritySpace, n'accordait quant à elle qu'un maigre 20,47% des parts au serveur IIS par rapport à 73.28% pour Apache. Il reste donc bien peu de place pour la concurrence. Cependant, du haut de ses 1,4 % du gâteau des serveurs, Zeus^23(*) s'impose comme un outsider incontournable : quelques uns des plus gros Intranets et des plus gros sites Web ont opté pour lui. Un critère qui a conduit à le retenir dans notre comparatif.

Dans le tableau suivant, chacun de ces trois serveurs Web est passé au crible de quatre critères : coût, ergonomie, performances et efficacité du support.

Points forts et points faibles de chaque produit
Nom du produit	*Apache*	*Microsoft IIS*	*Zeus*
Points forts	- Gratuité - Peu gourmand en ressources matérielles - Excellente stabilité	- Grande simplicité d'installation et d'utilisation	- Peu gourmand en ressources matérielles - Excellente stabilité - Capacité à tenir de très gros pics de fréquentation - Interface native avec certaines bases de données
Points faibles	- Installation et administration plus laborieuses (pas d'interface graphique) - Pas de support technique	- Coût du support technique - Très gourmand en ressources matérielles	- Coût de la licence (1700 €) - Coût du support technique

L'utilisation de Microsoft IIS se justifie en effet toujours dans certains contextes, de même que celle de Zeus ou d'Apache. Les portraits brossés ci-après permettront de se faire une idée du profil de l'entreprise qui trouvera intérêt dans l'un ou l'autre de ces serveurs web :

Le Serveur Web de Microsoft est très facile à installer et relativement facile à administrer. Il dispose d'une fonction de redémarrage automatique en cas de plantage. Et il est inclus par défaut dans l'OS serveur de Microsoft. Mais si l'on souhaite confier à IIS un gros site Web ou un gros Intranet, la facture hardware monte beaucoup plus vite que celle d'Apache ou Zeus, de même que la facture logicielle : la base de données Microsoft SQL devient rapidement indispensable, et l'on sait son tarif conséquent.
On réservera donc IIS aux entreprises qui disposent de compétences informatiques moyennes, et dont les exigences en termes de performances vont de modérées à moyennes.

Le Serveur Web le plus populaire est fort complexe à paramétrer et à administrer : tout se passe sur un écran noir, en mode ligne de commande. Aucun support technique téléphonique n'est fourni puisqu'Apache n'a pas de distributeur officiel.

Il faut donc assurer soi même son support en naviguant sur les sites d'information consacrés à Apache, ou encore souscrire à un contrat de support auprès d'une société spécialisée. Cependant, Apache est gratuit, il consomme des ressources matérielles très modestes, et il est irréprochable en termes de fiabilité.

Apache est donc un très bon choix pour les entreprises qui disposent de compétences informatiques fortes et plus spécifiquement sous Unix et Linux. Notons qu'il sera parfois intéressant d'acquérir ces compétences : les linuxiens chevronnés se font de moins en moins rares sur le marché, et Apache demande à charge égale beaucoup moins de ressources matérielles qu'IIS, ce qui rend son TCO (Cout Total de Possession) excellent pour les applications lourdes.

Zeus simplifie la tâche de l'administrateur. L'installation démarre en mode ligne de commande, mais elle est rapidement facilitée par des boites de dialogue judicieusement conçues.

L'administration se fait à distance à travers un navigateur Web : c'est un modèle d'ergonomie. Quant aux performances de Zeus, elles sont équivalentes à celles d'Apache, avec un avantage de taille : Zeus est capable de tenir le choc de plusieurs milliers de requêtes par seconde. Une assurance contre le plantage en cas de pic de fréquentation. Zeus est compatible en natif avec une foule d'API qui lui permet de s'interfacer sans effort avec un grand nombre de bases de données. Le seul défaut de Zeus : son prix (1700 € pour la licence sans compter le support)^24(*). Zeus sera le meilleur choix pour les entreprises aux exigences très fortes aussi bien en nombre de connexions simultanées qu'en termes de disponibilité.

Le tableau qui suit donne des informations supplémentaires sur le prix et compatibilité de ces trois serveurs web.

Tableau 6.14 : Tableau donnant des informations sur le Prix et la compatibilité pour les serveurs web

Cette étude, nous a permis de mettre en mettre en évidence les trois serveurs web du marché les plus connus. En ce qui nous concerne, nous avons porté notre choix sur apache du fait non seulement de son statut libre et gratuit, mais aussi de sa vaste part de marché.

Après une étude comparative très rigoureuse, nous avons pu choisir les outils qui répondent mieux à nos besoins. Il s'agit du serveur cartographique MapServer avec PHP/MapScript, du célèbre serveur web apache, et du SGBDR PostgreSQL avec sa cartouche spatiale PostGIS.

Après avoir effectué notre choix pour les outils dont nous avons besoin, nous allons passer dans le chapitre qui suit à la phase implémentation.

* ¹⁸ Un programme CGI est exécuté côté serveur. Il permet l'échange de données entre le serveur et le navigateur. Quand il reçoit une requête du poste client, le CGI détermine (en fonction de l'extension) l'action à effectuer

* ¹⁹ Il s'agit ici de l'ensemble des commandes permettant d'accéder aux fonctionnalités du noyau MapServer

Mise en place d'une plateforme de cartographie dynamique

Choix des outils à utiliser