neogeo

La mise en place d’un serveur cartographique complet est parfois complexe et douloureuse. Au fil des ans, j’ai enrichi un document de travail décrivant toutes les étapes relatives à la compilation depuis les sources ainsi qu’à l’installation et à la configuration d’un serveur carto sous Linux, avec PostGIS et PHP. Cette documentation comprend la description d’une configuration en php-cgi ou php-module, ainsi que la description de la prise en charge d’Oracle ou du format ECW

Lisez ce document, critiquez-le, corrigez-le, améliorez-le, de sorte qu’on puisse mettre à disposition de tous une documentation fiable et complète.

Téléchargement au format OpenOffice, Microsoft Word, PDF.

Nul doute que le succès de PostGIS fait des envieux. Ses performances en font même un sérieux challenger aux solutions Oracle, à tel point que des organismes prestigieux le privilégient (voir Oracle, PostGIS et MySQL : éléments de comparaison, via postGIS.fr et surtout l’étude de cas de l’IGN).

Les grands de ce monde se devaient donc de réagir. A la conférence annuelle des utilisateurs des produits ESRI (ESRI International User Conference 2007), Jack Dangermond a ainsi répondu à la question : “Will ESRI support the PostGIS open-source spatial extension for PostgreSQL?” :

- Yes, ESRI will provide our customers with the option of using either the ISO/OGC spatial type or the PostGIS spatial extension.

Comme Paul Ramsey le remarque malicieusement, Jack induit ainsi le doute quant au respect des normes ISO/OGC dans PostGIS, ce qui est habile mais légèrement tendancieux. Plus précisément, si ArcSDE envisage bien une interconnexion postGIS, ce n’est pas forcément sur le format natif de celui-ci, mais le format maison SDEBINARY simplement intégré à postGIS. Ca peut permettre à votre ArcMap d’utiliser des données stockées dans postGIS, mais quel intérêt si ces données, de par leur format spécifique, sont inutilisables hors de la passerelle ArcSDE (dans MapServer par exemple) ? L’interropérabilité en prend un coup.

Dans le même temps, Microsoft, singulièrement à la traîne pour ce qui était des bases de données spatiales, introduit dans SQL Server 2008 (nom de code Katmai) le support complet des données géographiques, pour lequel on annonce déjà une intégration parculièrement poussée avec les produits ESRI (”The spatial database offerings of specific ESRI partners were developed using core, underlying ESRI technology and hence have a high degree of similarity“). Est-ce à dire que SQL Server 2008 va devenir le SGBD “naturel” de la gamme ArcGIS ? Du subtil dénigrement de PostGIS mentionné plus haut et de l’étroite collaboration ESRI-Microsoft autour de SQL Server, on peut raisonnablement le déduire.

On sent surtout la crainte de voir les utilisateurs ArcQuelquechose migrer vers les solutions OpenSource pour le stockage ou la diffusion des données sur le web, tout en conservant leur Arc comme client SIG desktop, pour la manipulation et la visualisation des données. Qui n’a pas son égal en OpenSource, force est de le constater.