Le portail francophone de la géomatique

Aujourd'hui, le plus agréable pour stocker les données géographiques (mais pas pour les transporter, là, c'est autre chose), c'est à mes yeux la base PostGis.
Postgis est une base SQL Postgres, Opensource, étendue à la géographie par un module supplémentaire à y installer.
Le stockage de données géographiques y a de grands atouts car les requêtes SQL qu'on y fait peuvent être complétés d'opérateurs géographiques spéciaux pour faire à peu près tout ce que vous voulez d'examen ou de transformations de données (intersections, réunions, simplifications, recherche dans un périmètre, reprojections...) sans même avoir recours tout de suite à un QGIS ou un autre outil.

Après, en ce qui concerne l'affichage sur de cartes sur des pages web, je crois pouvoir dire qu'Openlayers domine et dominera encore un certain temps, même s'il n'est pas sans défaut.
Il est d'usage qu'on s'en serve en lui faisant afficher des couches géographiques qui concrètement ouvrent des liaisons au protocole WMS vers des serveurs web type Geoserver, qui sont dédiés au monde géographique, et qui rendent accessible à ce format de grandes variétés de sources de données.
En un mot, on met un Geoserver et on y déclare sa source Postgis, ou Shapefile, ou autre, et il "neutralise" tout cela pour que la partie web (openlayers donc) n'ait pas à se soucier du format d'origine des données qui lui sont transmises.

Dernière modification par grunt (Fri 12 October 2018 12:51)

Bonjour,

Merci pour ces précisions essentielles Jean-Yves!
Il me semble qu'il existe au moins une démarche, moins orientée business open source, du coté de l'OGC:
http://www.geopackage.org

Bruno

GeoJSON a un problème... c'est que c'est du JSON.

Comme tout les formats "à la XML", il a le défaut de répéter pour chaque feature qu'il décrit tous les noms des attributs de cette feature.

On est face à des listes de

[{"champ1": 15, "champ2": "Bonjour"}, {"champ1" : 25, "champ2": "Au revoir !"}]

où finalement, la répétition de "champ1", "champ2" finit par prendre beaucoup de place.
Ici, il faut 80 caractères pour transmettre une information d'une longueur binaire totale, selon comment on la comptera, d'environ 18 à 24 octets. On perd trois quart d'espace par l'expression textuelle et la répétition des noms d'attributs.

Il ne se valide pas, ou mal.
Ne s'indexe pas, ou mal.

Je vais la faire acerbe, mais :
le JSON, c'est pour envoyer quelque-chose quelque-part, à condition de ne pas avoir envie de s'en servir ensuite.

Dernière modification par grunt (Fri 12 October 2018 15:23)

Bonjour à tous,

Réponse partielle mais j'avais traduit de switchfromshapefile les principaux arguments contre ce format :

Le format Shapefile : pourquoi il faut l’abandonner ?

○ Format multi-fichiers (.shp, .dbf, .shx à minima) : problème d’échange fréquent
○ Noms des champs limités à 10 caractères (car basés sur la norme dBase IV - octobre 1988) : noms des champs très souvent tronqués
○ Limité à 255 attributs
○ Limitation dans les types de données (float, integer, date et text avec un maximum de 254 caractères)
○ Pas de possibilité de spécifier l’encodage des caractères
○ Limitation de la taille à 2Go par fichier (contourné parfois mais jamais au delà de 4Go)
○ Pas de topologie (aucune possibilité de fixer des relations topologiques)
○ Pas de possibilité de mixer les géométries (point, ligne ou polygone)
○ Structure des tables basiques (pas de hiérarchie, relations ou structure arbre)
○ Pas de stockage de données 3D avec textures
○ Incompatibilité des projections définies dans les .prj avec les définitions EPSG (noms et paramètres parfois différents voire manquants)

On entend encore beaucoup d’idolâtres de ce format. La nostalgie sûrement.

Un compte marrant à suivre : https://twitter.com/shapefiIe

Je plussoie sur l'avènement du Geopackage, en revanche côté raster le geotiff me semble avoir encore de beaux jours devant lui, geopackage étant limité à des bandes de 8bits.

Pour les fonds RGB l'IGN s'est largement investi dans le jpeg2000 avec des taux de compression assez impressionnants, par contre le driver opensource est encore mou de chez mou, du coup chez moi ça repasse en compression jpeg dans un conteneur tiff ou gpkg.

Dernière modification par dominique.lys (Fri 12 October 2018 17:45)

SHP a surtout la force de sa communauté, qui pour de bonnes ou mauvaises raisons l'utilise encore massivement.
Si bien que 7 mois après l'ouverture du plan cadastral nous avons cédé quant à l'ajout de ce format, en plus de GeoJSON (qui reste idéal pour le Web).

gpkg a quand même quelques défauts qui vont ralentir son adoption, et ne lui permettront pas d'être aussi universel qu'a pu l'être le SHP (pas compilé nativement avec GDAL/OGR à ce jour, pas streamable, support navigateur sous-optimal, écosystème expert).
Comme on dit, en informatique c'est souvent le plus con qui gagne

NB : GeoJSON, comme JSON et XML, est un format texte. Il se compresse donc très bien, et peut aussi être transféré en geobuf lorsque la chaîne est maîtrisée (entre une API et son application).
La répétition des noms de champs permet son "streaming", sans avoir à conserver un état complexe, et sans en-tête.