3 Les logiciels libres en géomatique

Sorte d’inventaire à la Prévert des logiciels libres en géomatique, cette liste n’a pas la prétention d’être ni exhaustive ni complète. En revanche, elle s’efforce d’offrir un bon aperçu de la diversité des solutions. Il existe de nombreux logiciels libres en géomatique (en anglais, Free OpenSource Software for Geospatial – FOSS4G).

Ces logiciels peuvent être regroupés en plusieurs catégories:

  • SIG bureautiques
  • Applications serveurs
  • Languages de programmation
  • Briques logicielles de bas niveau
  • Standards

Les standards sont un cas particulier mais permettent la communication entre les différents outils. Il est donc pertinent d’en avoir un aperçu.

3.1 SIG bureautiques

* projets non membres de l’OSGeo.

QGIS GRASS SAGA

3.2 Serveurs

3.2.1 Services web

  • MapServer
  • GeoServer
  • qgis-server
  • degree
  • zoo-project

3.2.2 Stockage

  • PostGIS
  • pgRouting
  • Rasdaman
  • spatialite / GeoPackage

pgRouting PostGIS

3.3 Télédétection

  • Orfeo Toolbox / Monteverdi

3.4 Traitement de données

Les languages de programmation Python et R ne sont pas des projets OSGeo, toutefois leurs capacités géospatiales sont fournies par des connecteurs aux outils GDAL, GEOS ou Proj.

3.4.1 Python

  • Pandas
  • GeoPandas

Pandas

3.4.2 R

R est un language de programmation dédié aux statistiques et au traitement de données. Il dispose de nombreux packages étendant ses capacités, notamment géospatiales.

R

3.4.2.1 Traitement

  • sf (sp/rgdal, rgeos)
  • raster
  • stars

3.4.2.2 Cartographie

  • ggplot
  • cartography

3.5 Briques logicielles de bas niveau

Beaucoup des logiciels cités plus haut ont recours à des bibliothèques logicielles contenant des algorithmes spécifiques. Le fait d’utiliser ses bibliothèques présente de nombreux avantages:

  • ne pas coder des fonctions souvent complexes
  • bénéficier des derniers avancements de la communauté
  • moins de maintenance

Dans le milieu de la géomatique, une poignée de bibliothèque de bas niveau sont disponibles et sont utilisées dans un grand nombre de logiciels. Tous les logiciels n’y ont pas recours, par exemple GRASS et SAGA disposent de leurs propres algorithmes. Il est intéressant de savoir d’où proviennent les algorithmes proposés pour pouvoir chercher une alternative si une fonctionnalité est manquante ou ne renvoit pas le résultat attendu.

Dans le monde de la géomatique libre, les plus connus sont proj, GDAL, GEOS et JTS. QGIS pouvant accéder à GRASS et SAGA via une API, ces derniers pourraient aussi avoir ce statut si ils n’étaient pas des SIG complets.

Ces briques de base ne proposent pas d’interface graphique et proposent des API permettant à d’autres logiciels d’accéder à leurs méthodes. Détaillons un peu ces différentes bibliothèques.

3.5.1 Proj

Proj est une bibliothèque qui contient les définitions de plusieurs milliers de projection. Elle fournit à la fois les formules de transformation et peut aussi transformer des coordonnées géospatiales d’un système de référence de coordonnées à une autre.

Proj est capable de travailler avec des systèmes de référence de coordonnées cartographiques comme géodésiques. Proj comprend différents catalogues de projection comme le catalogue EPSG ou IGNF (projections légales françaises).

La version stable a lontemps été la version 4, une version 5 a récemment légèrement moderniser en ajoutant de nouvelles projections et corrigeant quelques bugs.

La version 6 de Proj sortie en mars 2019 commence à être adoptée par les différents projets. Il s’agit toutefois d’une refonte complète entrainant non seulement des changements dans l’API mais aussi dans la façon de calculer les transformations.

Les versions précédentes avaient une étape intermédiaire de transformation passant par WGS84. Depuis la version 6.0, Proj effectue les conversions directement de système de référence à système de référence.

Cela améliore non seulement la rapidité mais aussi la précision. Attention donc les deux API renvoient des résultats différents.

3.5.2 GDAL/OGR

GDAL est une bibliothèque permettant de lire un grand nombre de formats d’image raster. La fusion avec OGR apporte à l’outil la capacité d’ouvrir les formats vectoriels.

Quelques formats supportés par GDAL (source: geopandas)

3.5.3 JTS

La Java Topology Suit (JTS) est comme son nom l’indique une bibliothèque Java. Elle fournit des algorithmes de traitement géométriques des données vectorielles. Elle implémente les spécifications Simple Features access (points, polylignes, polygones) définies par l’OGC et l’ISO.

3.5.4 GEOS

GEOS est le portage en C des outils de la suite JTS. Elle est utilisée par les outils développés en C/C++.

3.6 Standards

Standards OGC

Utiles pour faciliter les communications entre les outils, les standards sont très importants. Vous pouvez avoir le meilleur outil du monde si il ne lit et n’écrit que son propre format de données, il va avoir du mal à se diffuser.

3.6.1 Fichiers

  • shapefile (standard de facto)
  • geojson (webmapping)
  • GeoPackage

3.6.2 Standards de flux

Les standards de flux sont des protocoles de communication permettant l’échange de données entre un client et un serveur via le protocole internet HTTP.

Les méthodes GET ou POST sont généralement disponibles.

La plupart des serveurs géospatiaux libres (MapServer, GeoServer, QGIS Server) ou non (ArcGIS Server) implémentent ces protocoles.

Les spécifications des standards évoqués ci-dessous sont maintenues par l’OpenGIS Consortium (OGC).

Ils proposent généralement une requête GetCapabilities permettant d’obtenir des métadonnées sur le service (couches, emprises, fonctionnalités, …).

Exemple de requête GetCapabilities interrogeant un service WFS fournit par un serveur GeoServer (source : documentation GeoServer):

http://example.com/geoserver/wfs?
  service=wfs&
  version=1.1.0&
  request=GetCapabilities

3.6.2.1 Web Feature Service (WFS)

Le standard Web Feature Service permet d’obtenir les entités correspondant aux contraintes formulées dans la requête (emprise géographique, couches, etc). Le serveur renvoit des objets géographiques (points, lignes, polygons) avec lesquels il est possible de travailler ensuite (filtrage, symbologie, etc).

Exemple de requête WFS tiré de la documentation de l’État du Massachussets :

http://giswebservices.massgis.state.ma.us/geoserver/wfs?request=GetFeature&
service=wfs
&version=1.0.0
&typename=massgis:GISDATA.TOWNS_POLY
&outputformat=SHAPE-ZIP

3.6.2.2 Web Map Service (WMS)

Le Web Map Service est un service fournissant une carte en réponse à une requête comprenant généralement une emprise et une ou plusieurs couches ainsi que les dimensions de l’image.

Un serveur WMS renvoit une carte au format image en réponse à une requête. Il peut servir aussi bien des cartes vectorielles rasterisées que de l’imagerie.

Exemple tiré de la documentation de GeoServer:

http://localhost:8080/geoserver/wms?
request=GetMap
&service=WMS
&version=1.1.1
&layers=topp%3Astates
&styles=population
&srs=EPSG%3A4326
&bbox=-145.15104058007,21.731919794922,-57.154894212888,58.961058642578
&width=780
&height=330
&format=image%2Fpng

Selon la taille demandée, l’image peut être lourde, ce qui pose parfois des problèmes. Surtout si la connexion internet n’est pas fiable. En effet, en cas d’erreur, l’intégralité de l’image est renvoyée.

Pour remédier à ce problème, un autre protocole a été développé, le WMTS. #### Web Map Tile Service (WMTS)

Héritier du Web Map Service, le WMTS porpose lui aussi de permettre la transmission d’images cartographiques. Les images sont prégénérées et découpées selon un quadrillage régulier. L’image est reconstituée à partir de tuiles assemblées.

Pyramide de tuiles (source IGN)

3.6.2.3 Web Coverage Service (WCS)

Le WCS fournit des données de couverture (ortho-images, données météorologiques, modèles numériques de terrain).

A la différence du WMS, il gère les aspects spatio-temporels de ces données.

http://www.example.com/wcs?
service=wcs&
AcceptVersions=1.1.0&
request=GetCapabilities

3.6.2.4 Web Processing Service (WPS)

Le WPS est un standard standardisant les échanges entre un client et un serveur dans le but de faire réaliser un traitement par ce dernier.

Le standard défini comment le client peut demander un service et comment le résultat peut être transmis en retour.

3.6.2.5 OGC API

L’OGC API est un projet récent visant à fournir un standard unique pour remplacer les standards vu précédemment (WFS,WMS, …).

Des implémentations sont en cours de développement:

3.6.2.6 GeoAPI

La GeoAPI vise à favoriser l’interopérabilité entre les applications en proposant une interface commune.

La GeoAPI a été implémentée avec Java et Python.

3.6.2.7 Symbology Conceptual Model

Ce standard récent vise à fournir un langage commun de description de la cartographie. Ce standard vise donc à codifier le style des objets cartographiques et permettre de partager et diffuser les bonnes pratiques cartographiques et améliorer la qualité des visualisations.

3.6.3 Standards de métadonnées

Il existe plusieurs standards de métadonnées suivant les recommandations de la Dublin Core Metadata Initiative qui ont été transposés dans le monde géospatial.

Le FGDC états-unien recence les standards de métadonnées utilisés en géospatial.

En Europe, la directive Inspire impose l’ouverture des données publiques et impose un standard de métadonnées pour leur cataloguage.

3.6.3.1 Catalogue Service for the Web (CSW)

Ce standard permet de découvrir, parcourir et requêter les métadonnées de données, services et ressources disponibles au sein d’une organisation.

3.7 Aller plus loin

Page des projets inclus dans OSGeoLive: live.osgeo.org/contents/