Le portail francophone de la géomatique

Très bon mouvement que d'aller vers des formats plus "modernes".

L'étape suivante, c'est l'adoption de formats optimisés cloud, pour permettre un usage indifférencié avec des fichiers téléchargés localement ou utilisé directe à distance et sans logiciels serveur dédié nécessaires.

Pour les raster, une diffusion au format COG (non sur-compressés en 7z) irait dans ce sens.

Pour le vecteur, il faudra envisager GeoParquet et PMtiles (aussi utilisable en raster).

Les nuages de points (Lidar) ont aussi leur format optimisé cloud, le COPC "Cloud Optimized Point Cloud".

libsqlite est opensource, sous licence MIT : https://github.com/tursodatabase/libsql

Le format sqlite est sauf erreur documenté ici: https://www.sqlite.org/fileformat.html

Je ne comprends donc pas trop votre message.

GML en terme de modernité (et efficacité), ça peut être un beau sujet de discussion en soit.

Dernière modification par cquest (Wed 22 January 2025 14:29)

Bonjour,

Non, le Code de la propriété intellectuelle dit ceci à propos des contrats de licence (L.131-3) :

Et rien de ce qui est écrit sur SQLite ou dans le code source ne satisfait cette définition. Le site de SQLite précise : https://sqlite.org/copyright.html

Ce qui est une exigence d'acheter une licence en France. Et l'auteur de SQLite, dans un entretien à Stephen Shankland, déclare : https://framablog.org/2008/05/10/domain … iel-libre/

À partir du moment où même l'auteur affirme que son oeuvre n'est pas libre chez nous, quelle légitimité avons-nous à l'utiliser ?!

(Note : l'article n'a pas été écrit dans une perspective franco-centrée et son sujet de fond n'intéresse pas notre débat)

Le format est certes documenté, mais sa mise en oeuvre (en France) n'est pas possible en vertu de ce qui précède, il y a trop de risques de faire une contrefaçon de SQLite en refaisant le code de l'API et de la lecture du fichier. En outre, il n'est pas ouvert puisque Hwaci se réserve la faculté de le modifier unilatéralement : « Open-Source, not Open-Contribution ».

Quant à libSQL, c'est tout bon et ça fait du bien (du moins jusqu'à ce qu'un juge de chez nous leur demande par quel droit ils concèdent sous licence une contrefaçon de SQLite).

On y va, Christian. Doucement, mais on y va!
Les nuage de points LiDAR HD sont en copc.laz
Sur le raster, on devrait prochainement proposer des trucs en cog...
Sur le vecteur, on part d'un peu plus loin sur le GeoParquet...

Il faudrait citer, pour le vecteur, également FlatGeobuf, qui est réellement conçu pour être "streamé" et affiché très rapidement.

(Geo)parquet (que j'aime beaucoup), qui est avant tout du Parquet avec quelques métadonnées et conseils de structure, n'est pas à l'origine conçu pour un affichage carto ultra rapide à partir du cloud - il est un peu abusif de le définir comme format optimisé cloud, ce n'est pas sa vocation première. Parquet date de 2016, vient du monde du big data, c'est un format orienté colonnes optimisé pour les traitements analytiques (agrégations, jointures, filtrages multi-critères...).

Mais comme il est très efficacement compressé, partitionné en colonnes, groupe de lignes voire en une multitude de fichiers de même structure, accessibles par range requests, il est en effet possible de l'utiliser directement en ligne et d'extraire par exemple par une série de range requests le seul contenu d'une bounding box avec uniquement les attributs (colonnes) que l'on souhaite. La base Overture Maps est ainsi accessible en géoparquet.

Mais la visualisation carto ne se fera pas de façon aussi fluide qu'avec FlatGeobuf (qui indexe toutes les entités avec un tri Hilbert, et pas seulement des groupes d'entités) ou des tuiles vectorielles.

Noter enfin que GDAL gère très bien Géoparquet (lecture/écriture), et donc QGIS de même - je crois aussi qu'Esri et FME s'y sont mis.

Enfin, le format Parquet va bientôt adopter un véritable type de colonne géographique, ce qui fait que Geoparquet n'aura à terme plus de sens en tant que spec additionnelle.

Je suis d'accord avec ta reformulation.

Je réagis juste sur ceci :

Pour FlatGeoBuf toutefois, on a une vraie structure tabulaire dans un fichier unique, il est donc possible d'interroger un dataset des mairies avec x attributs dans un format FlatGeobuf.

Par exemple avec DuckDB : FROM st_read('mairies2025.fgb') WHERE REG = '44'.

FlatGeobuf se présente comme une alternative au shapefile par exemple. Mais il est orienté lignes, il est moins performant pour l'analyse qu'un format orienté colonnes comme Parquet.