LAS vs LAZ : quelle différence entre les fichiers LiDAR ?

Résumé

LAS vs LAZ désigne principalement la différence entre un fichier LAS non compressé et un fichier LAZ compressé sans perte au sein de la même famille de formats de nuages de points LiDAR. Un fichier LAS est un format d’échange ouvert pour les données de nuages de points, tandis qu’un fichier LAZ conserve la même signification des champs de points, mais stocke les données de points sous forme compressée. [1] [4]

En pratique, vous rencontrerez les deux en lidar aéroporté, cartographie par drone, relevés de corridors et livrables de capture de la réalité. La compression sans perte n’est ni un éclaircissage, ni une décimation, ni un rééchantillonnage ; LAZ ne réduit donc pas intrinsèquement la qualité des points. Le risque le plus important concerne le flux de travail : un logiciel peut mal interpréter ou supprimer les métadonnées de SCR, ignorer les schémas Extra Bytes, ou réécrire les valeurs d’échelle et de décalage durant une conversion si vous ne les vérifiez pas explicitement. [4] [2] [3]

LAS vs LAZ : la différence essentielle (et la réponse à « LAS compressé »)

Un fichier LAS est le conteneur binaire non compressé traditionnellement utilisé pour échanger des nuages de points LiDAR entre outils. Dans la définition du format, le fichier contient un Public Header Block, des VLR facultatifs, des enregistrements de données de points et des EVLR facultatifs, tous en ordre little-endian. Les charges utiles des VLR sont limitées à 65,535 octets, ce qui explique notamment pourquoi les blocs de métadonnées plus volumineux ou ajoutés ultérieurement peuvent être placés dans des EVLR. [2]

Un fichier LAZ conserve cette structure globale orientée LAS, mais applique une compression sans perte standardisée au bloc de données de points. L’actuel standard communautaire OGC LAZ 1.4 indique que LAZ 1.4 repose sur LAS 1.4 et ne modifie pas la signification des champs de points LAS non compressés. Autrement dit, LAZ modifie le stockage, et non la signification sémantique des coordonnées, classifications, retours ou autres attributs de points. [4]

Alors, LAZ est-il simplement un LAS compressé ? Oui, au sens où la signification des champs de points est conservée. Non, au sens où il ne s’agit pas d’une enveloppe ZIP générique autour d’un fichier .las. LAZ modifie la signalisation du conteneur en ajoutant 128 au format d’enregistrement des données de points LAS, ajoute un VLR spécifique à LAZ qui identifie le fichier et décrit la compression, puis remplace le bloc de données de points d’origine par un bloc compressé. Les métadonnées doivent toujours être vérifiées après ouverture ou conversion. [4]

Pour la plupart des utilisateurs, la différence pratique concerne davantage le flux de travail que la qualité analytique. LAS est plus simple pour les logiciels ou scripts qui attendent des enregistrements non compressés, tandis que LAZ réduit les coûts de stockage et de transfert lorsque le logiciel destinataire peut le décoder correctement et préserver les métadonnées qui vous importent. [4] [2]

Une chronologie claire : LAS comme format d’échange → référence LAS 1.4 → standardisation de LAZ 1.4

LAS existe afin que différents outils matériels et logiciels puissent échanger des données de nuages de points dans un format commun. Pour les discussions actuelles sur l’interopérabilité, LAS 1.4 constitue la référence principale, car le standard communautaire OGC LAS 1.4 a été publié le 1 mars 2018 sous le document 17-030r1. L’OGC avertit également que le contenu de ce standard communautaire est figé, même si l’ASPRS, l’organisme à l’origine du format, peut continuer à mettre à jour séparément la spécification. Cette distinction importe, car de nombreuses archives et de nombreux profils d’appels d’offres réels ciblent encore les conventions LAS 1.4, même si des révisions ASPRS plus récentes existent désormais. [1] [3]

LAS 1.4 n’inclut pas lui-même de compression, raison pour laquelle LAZ a nécessité une standardisation distincte plutôt que d’être traité comme une fonctionnalité du document LAS 1.4. Le standard communautaire OGC LAZ 1.4 a été approuvé le 23 avril 2026 et publié le 30 juin 2026 sous le document 24-070r1. Il formalise LAZ comme format de compression sans perte compatible LAS largement utilisé pour le stockage et la livraison lorsque de grands nuages de points doivent circuler efficacement entre organisations. [3] [4]

Ce qu’un fichier LAS peut stocker (et ce qu’il ne peut pas stocker)

Un fichier LAS stocke des enregistrements de points ainsi que des attributs de points, mais l’ensemble exact des attributs dépend du format d’enregistrement de données de points choisi, ou PDRF. Dans LAS 1.4, les formats 0 à 10 sont définis, tous les enregistrements de points d’un même fichier doivent utiliser le même PDRF, et les formats 6 à 10 constituent l’ensemble moderne privilégié. Ainsi, deux fichiers LAS peuvent être valides tout en contenant différentes combinaisons de temps GPS, couleur, NIR ou champs liés aux formes d’onde. [3]

En pratique, le fichier est organisé avec l’en-tête d’abord, puis les VLR facultatifs, les enregistrements de points, puis les EVLR facultatifs. L’en-tête indique au logiciel combien de points existent, quel PDRF est utilisé et comment interpréter les coordonnées mises à l’échelle. Les VLR hébergent une grande partie des métadonnées, mais chaque VLR est limité à 65,535 octets. Les EVLR autorisent des charges utiles plus importantes et peuvent être ajoutés à la fin du fichier, ce qui est utile lorsque des métadonnées telles que des informations de projection doivent être ajoutées sans réécrire l’intégralité du bloc de données de points. [2]

LAS et LAZ stockent des nuages de points, et non des maillages finalisés, MNT ou géométries de type STL. Ceux-ci peuvent être dérivés ultérieurement des points, mais ce sont des produits de données différents. Les attributs de points courants que vous pouvez rencontrer comprennent les suivants. [1] [2] [3]

• Coordonnées X, Y et Z, stockées à partir de valeurs de points entières plus échelle et décalage. [2]
• Intensité, représentant généralement la magnitude du retour d’impulsion dans un champ entier normalisé. [2]
• Numéro de retour et nombre de retours, qui décrivent le comportement multi-retours d’une impulsion. [2] [3]
• Classification et drapeaux associés, dont la richesse dépend de la génération de PDRF utilisée. [3]
• Temps GPS, obligatoire dans PDRF 6 et dans la conception de la famille apparentée 6–10. [3]
• Valeurs RGB et, lorsque pris en charge, NIR dans les formats de points compatibles couleur. [3]
• Champs liés aux formes d’onde, mais uniquement dans certains formats de points plutôt que dans chaque fichier LAS. [3]
• Extra Bytes ou autres dimensions personnalisées, lorsqu’un producteur ajoute des valeurs supplémentaires par point au-delà des champs standard. [3]

Ce qu’un fichier LAZ modifie (uniquement au niveau du conteneur)

Au niveau du stockage, LAZ remplace les données de points non compressées par des données de points compressées sans perte. Cela signifie que les valeurs sont restituées à l’identique après décodage ; LAZ n’est donc pas une étape d’éclaircissage, de décimation ou de rééchantillonnage. LAZ stocke également les données de points par blocs, et chaque bloc peut être décompressé indépendamment, ce qui permet un accès aléatoire à la granularité des blocs au lieu d’exiger le déballage préalable du fichier entier. [4]

Au niveau du conteneur binaire, plusieurs éléments changent même si la signification des points ne change pas. LAZ ajoute 128 à la valeur du Point Data Record Format, de sorte que les valeurs 128 à 138 correspondent aux formats LAS 0 à 10. Il ajoute un VLR spécial LAZ obligatoire qui identifie le fichier et décrit la compression, et place un bloc de données compressé là où LAS aurait stocké des enregistrements de points bruts. Facultativement, un pointeur de table de blocs peut apparaître à la fin du fichier. C’est pourquoi LAZ doit être compris comme une compression compatible LAS, et non comme « LAS dans ZIP ». [4]

Métadonnées & SCR : où elles résident et ce qui peut mal se passer

L’une des erreurs les plus faciles à commettre lors de la manipulation de LAS ou LAZ consiste à confondre les coordonnées stockées avec les métadonnées du système de coordonnées de référence. Les valeurs X, Y et Z stockées sont des valeurs d’enregistrements entières interprétées via une échelle et un décalage, tandis que le SCR est une métadonnée distincte portée par les VLR ou EVLR. Un fichier peut donc avoir des coordonnées numériquement valides tout en possédant des métadonnées de référence spatiale manquantes, ambiguës ou incorrectes. [2]

Dans LAS 1.4, les métadonnées de SCR résident normalement sous l’ID utilisateur LASF_Projection. Les enregistrements fondés sur WKT sont l’ID d’enregistrement 2111 pour Math Transform WKT et 2112 pour Coordinate System WKT. Les enregistrements de style GeoTIFF sont les ID d’enregistrement 34735, 34736 et 34737 pour les structures GeoKeyDirectory, GeoDoubleParams et GeoAsciiParams. Les fichiers réels peuvent contenir WKT, GeoTIFF, les deux ou aucun des deux, et les logiciels peuvent les interpréter incorrectement ou les omettre pendant une conversion. C’est pourquoi un flux de travail sûr consiste à inspecter les métadonnées de SCR avant toute analyse, reprojection, découpage en tuiles ou export, plutôt que de supposer que la vue cartographique « semble correcte ». [3]

Il existe également une réserve liée aux versions. ASPRS LAS 1.5 Revision 00 a été publié le 26 août 2025, et ses principaux changements comprennent une prise en charge WKT du SCR étendue et la suppression de l’encodage GeoTIFF du SCR. LAS 1.5 rend également les PDRF 0 à 5 invalides pour les fichiers LAS 1.5. Malgré cela, la plupart des discussions d’échange doivent rester centrées sur LAS 1.4 et LAZ 1.4, car c’est là que fonctionnent de nombreuses archives, de nombreux livrables et chaînes d’outils. L’échelle et le décalage contrôlent la précision de stockage, non la précision topographique. Les modifier peut changer la façon dont les coordonnées sont quantifiées dans le fichier sans rien indiquer, à eux seuls, sur la précision du relevé sur le terrain. [6] [2]

Formats de points (PDRF) vs Extra Bytes (dimensions personnalisées)

Les champs définis par le PDRF sont les champs garantis par le format de point sélectionné. Dans LAS 1.4, tous les points d’un fichier doivent partager un seul PDRF, et les formats modernes privilégiés vont de 6 à 10. PDRF 6 est la structure centrale de 30 octets partagée par 6 à 10, ajoutant notamment la prise en charge de jusqu’à 15 retours, 256 classes, un stockage de l’angle de balayage en 16 bits de plus haute précision au lieu de 8 bits, ainsi qu’un temps GPS obligatoire. Si une dimension fait partie du PDRF choisi, un logiciel conforme devrait savoir où se situe ce champ. [3]

Les Extra Bytes sont différents. Ce sont des dimensions personnalisées par point ajoutées après les champs PDRF standard, et leur signification est décrite par le VLR Extra Bytes sous l’ID utilisateur LASF_Spec, ID d’enregistrement 4. C’est puissant, mais la portabilité dépend de la conservation de ce schéma tout au long du flux de travail et de sa prise en compte par l’outil suivant. La documentation du writer de PDAL concrétise cette question de conservation : le transfert des valeurs d’en-tête, de l’échelle, du décalage et du contenu VLR est un comportement explicite, et non quelque chose dont vous devez supposer qu’il se produit automatiquement dans chaque conversion. [3] [9]

Un exemple pratique est que RGB peut être défini par le PDRF dans un format de points compatible couleur, tandis qu’une dimension personnalisée telle que l’amplitude ou la largeur d’écho peut être stockée dans Extra Bytes. Si le schéma de ces Extra Bytes est supprimé ou reconstruit incorrectement, les points peuvent toujours s’ouvrir, mais la dimension personnalisée peut ne plus avoir de sens pour les logiciels en aval. [3] [9]

Données de formes d’onde : pourquoi certains fichiers LAS/LAZ ne s’ouvrent pas partout

Les fichiers compatibles avec les formes d’onde constituent un cas particulier. Dans LAS 1.4, les PDRF 4, 5, 9 et 10 ajoutent des champs de paquets de formes d’onde. Cela ne signifie pas que tous les fichiers de ces formats gèrent en pratique les formes d’onde de manière identique, mais cela signifie que les lecteurs doivent faire davantage que la logique habituelle XYZ et attributs. Un fichier par ailleurs valide peut échouer dans un outil simplement parce que cet outil n’implémente pas ces formats de points liés aux formes d’onde. [3]

La documentation actuelle de readers.las de PDAL précise explicitement qu’il ne prend pas en charge les formats de points de formes d’onde 4, 5, 9 et 10. LAZ 1.4 ajoute une autre contrainte : les données de formes d’onde stockées en interne dans un EVLR ne sont pas prises en charge ; les paquets de formes d’onde doivent donc utiliser un fichier auxiliaire tel que .WDP, et le standard indique que le stockage interne des formes d’onde est également obsolète dans LAS 1.4. Lorsqu’un fichier de formes d’onde ne s’ouvre pas correctement, la première hypothèse doit être une limite de prise en charge, et non une corruption automatique. [7] [4]

Comment ouvrir des fichiers LAS/LAZ (visualisation + conversion sans perte de métadonnées)

Ouvrir correctement un LAS ou un LAZ dépend de deux facteurs : la capacité du logiciel à décoder le fichier et son interprétation des métadonnées conformément à vos attentes. LAZ nécessite un lecteur compatible LAZ, et non un utilitaire de décompression générique. La prise en charge évolue aussi avec le temps ; il est donc utile de consulter la documentation de la version ou compilation exacte que vous utilisez, particulièrement si le fichier emploie des PDRF modernes, des champs de formes d’onde ou des dimensions personnalisées. [4] [7] [18]

QGIS 3.44 est un bon exemple d’un comportement important dans la pratique. Sa documentation sur les nuages de points indique que, lorsque la source est LAS ou LAZ, QGIS la convertit en EPT lors du premier chargement et crée un sous-dossier ept_... à côté des données sources. Cela signifie que la première ouverture peut prendre du temps et consommer de l’espace disque supplémentaire, tandis que les ouvertures ultérieures sont plus rapides parce que QGIS réutilise la structure EPT mise en cache. [10]

D’autres outils ont des limites différentes. La documentation actuelle de Create LAS Dataset d’ArcGIS Pro indique que les jeux de données LAS peuvent référencer des fichiers .las, .zlas et .laz, et elle avertit que des informations de référence spatiale manquantes ou incorrectes peuvent laisser des fichiers avec une référence spatiale inconnue. CloudCompare doit être considéré comme dépendant de la compilation, car la documentation officielle de compilation indique que la prise en charge de LAS/LAZ nécessite LASzip via le chemin qLASIO. La page des formats pris en charge par Autodesk ReCap liste l’import LAS et l’export RCP/RCS, mais ne liste pas LAZ ; une étape de conversion en amont peut donc être nécessaire dans certains flux de travail CAO/BIM. [11] [18] [12]

Un flux de conversion sûr est simple, mais rigoureux. [2] [3] [9]

1. Inspectez d’abord l’en-tête et les métadonnées de SCR, notamment la présence de VLR de projection WKT ou GeoTIFF. [3]
2. Confirmez le format de points et l’existence éventuelle d’Extra Bytes, car les dimensions personnalisées ne sont portables que si le schéma est conservé. [3] [9]
3. Utilisez des outils compatibles LAZ et des flux de travail validés par la documentation, tels que QGIS 3.44, les étapes LAS/LAZ de PDAL, les outils de jeux de données LAS d’ArcGIS Pro, ou une compilation de CloudCompare compilée avec la prise en charge de LASzip. [10] [7] [11] [18]
4. Lors de la conversion, préservez explicitement l’échelle, le décalage, les choix de format de points compatibles, ainsi que le schéma VLR/EVLR et Extra Bytes. La documentation du writer de PDAL montre que le comportement de transfert est configurable plutôt qu’automatique ; « convertir » ne garantit donc pas la conservation des métadonnées. [2] [9]
5. Traitez les exports MNT, maillage et CAO comme des produits dérivés plutôt que comme la simple « ouverture » d’un fichier LAS ou LAZ. Un nuage de points reste un nuage de points jusqu’à ce que vous en dériviez intentionnellement autre chose. [1]

Taille des fichiers & performances : ce que disent réellement les sources

Les chiffres publiés de taille et de vitesse doivent être lus comme des exemples, non comme des garanties. Dans l’article LASzip de Martin Isenburg de 2013, la taille compressée rapportée représente 7 à 25 pour cent de la taille du fichier d’origine, avec un encodage et un décodage d’environ 1 à 3 millions de points par seconde et une prise en charge de l’accès aléatoire à une granularité par défaut de 50,000 points. La documentation de l’atelier PDAL donne une règle empirique différente, indiquant que la compression LASzip typique est de 5:1 à 8:1 selon le LiDAR. La documentation ArcGIS Pro d’Esri fournit un autre chiffre orienté jeu de données, indiquant que les fichiers compressés utilisent généralement environ 30 pour cent de l’espace de stockage des fichiers non compressés. Il est préférable de conserver ces chiffres séparés plutôt que de les moyenner en un slogan. [16] [8] [11]

Pourquoi les ratios varient-ils autant ? Parce que la compression dépend des données elles-mêmes : le mélange d’attributs, l’ordre des points, la présence de contenu couleur ou lié aux formes d’onde, les choix de précision des coordonnées, le bruit et les détails d’implémentation ont tous leur importance. LAZ est assurément sans perte, mais aucune source crédible ne soutient l’affirmation universelle « réduit toujours de X pour cent » pour l’ensemble des nuages de points. [4] [8] [16]

LAS/LAZ vs COPC (et notes rapides sur EPT et ZLAS)

COPC n’a pas une signification brute des points différente de LAZ. La spécification COPC définit un fichier COPC comme un fichier LAZ 1.4 dont les données de points sont organisées dans un octree groupé. Les attributs de points proviennent toujours des conventions LAS/LAZ, mais l’organisation spatiale est optimisée pour le streaming et l’accès partiel, raison pour laquelle COPC semble souvent différent dans les flux de travail web, cloud ou de très grands jeux de données. [17]

La limite est que COPC n’est pas « n’importe quel fichier LAZ ». La spécification exige uniquement les PDRF LAS 6, 7 ou 8 ; un fichier .laz générique et un fichier .copc.laz ne doivent donc pas être considérés comme des libellés interchangeables. EPT se comprend ici au mieux comme une structure de stockage et de streaming indexée qui apparaît aussi dans le flux de travail de premier chargement de QGIS pour LAS ou LAZ. ZLAS est une précision propre à l’écosystème Esri : la documentation d’ArcGIS Pro traite .zlas aux côtés de .las et .laz, ce qui suffit à ne pas le confondre avec LAZ, bien que les deux soient des conteneurs de nuages de points compressés. [17] [10] [11]

Normes actuelles & profils du monde réel

L’état des normes au 21 septembre 2026 est simple. OGC LAS 1.4 a été publié le 1 mars 2018. OGC LAZ 1.4 a été approuvé le 23 avril 2026 et publié le 30 juin 2026. Séparément, ASPRS LAS 1.5 Revision 00 a été publié le 26 août 2025, avec des changements notables tels que l’abandon des PDRF 0 à 5 pour LAS 1.5 et l’extension de la prise en charge des SCR fondés sur WKT. Ce statut ASPRS plus récent est réel, mais doit être traité comme une réserve circonscrite plutôt que comme une raison de réinterpréter les fonds plus anciens LAS 1.4 et LAZ 1.4. [3] [4] [6] [2]

Pour un exemple de marché concret, la spécification Lidar Base Specification 2025 rev. A de l’U.S. Geological Survey, publiée le 10 juin 2025, impose des livrables de points en LAS 1.4-R15 utilisant les PDRF 6 à 10 et exige une livraison en LAZ 1.4. Elle indique également que les fichiers LAZ 1.4 compressés en mode compatibilité ne doivent pas être utilisés. Il s’agit d’un exemple d’appel d’offres américain, et non d’une règle mondiale universelle, mais c’est un indicateur fort de la réalité actuelle du terrain pour les grands livrables du secteur public. La restriction du mode compatibilité importe parce que ce mode historique stocke les PDRF 6 à 10 comme 0 à 5 plus Extra Bytes sous des en-têtes LAZ 1.2 ou 1.3 plus anciens, plutôt que comme un LAZ 1.4 normal. [15] [14] [13] [4]

LAS vs LAZ : lequel choisir ?

Pour la plupart des flux de travail modernes d’échange et de livraison, LAS vs LAZ n’est pas une question de perte de qualité. C’est une question de compatibilité, de stockage et de rigueur concernant les métadonnées. Choisissez LAZ lorsque votre chaîne d’outils le prend en charge et que l’efficacité du stockage ou du transfert importe. Choisissez LAS lorsqu’un outil en aval, un script ou une remise à un fournisseur exige spécifiquement des enregistrements non compressés. Envisagez COPC lorsque vous avez besoin de contenu compatible LAZ et d’un meilleur comportement d’accès partiel pour de grands jeux de données ou des jeux de données distants. Dans tous les cas, préservez les métadonnées de SCR, la fidélité du PDRF, l’échelle et le décalage, ainsi que tout schéma Extra Bytes. Souvenez-vous également qu’un nuage de points n’est pas identique à un maillage ou un MNT, même si vous prévoyez de les dériver ultérieurement. [4] [17] [13]

• Choisissez LAZ lorsque vous souhaitez des livrables plus petits, des transferts plus rapides et que le logiciel destinataire est confirmé compatible LAZ. [4] [13]
• Choisissez LAS lorsque un outil requis ou partenaire d’échange attend du LAS non compressé, ou lorsque vous avez besoin du chemin de débogage le plus simple possible pour l’inspection des métadonnées. [1] [2]
• Envisagez COPC lorsque vous avez besoin de la sémantique LAZ 1.4 plus une organisation de type octree pour les flux de travail cloud ou d’accès partiel. [17]
• Ne faites jamais ceci : exportez vers du XYZ brut ou un autre format appauvri en supposant que les classifications, le SCR, le temps GPS, la couleur ou les Extra Bytes resteront intacts. N’utilisez ces formats que lorsque vous acceptez sciemment la perte d’attributs. [3] [9]

FAQ

LAS vs LAZ : quelle est la différence ?

LAS est le conteneur d’échange non compressé pour les données de nuages de points, tandis que LAZ est la variante compressée sans perte et compatible LAS. Les attributs de points ont la même signification après décodage, mais LAZ modifie la couche de stockage en ajoutant la signalisation LAZ et un VLR de compression, et en remplaçant les enregistrements de points bruts par un bloc de données compressé. [2] [4]

LAZ est-il simplement un LAS compressé ?

Oui, si vous voulez dire que LAZ préserve la même signification des champs de points que LAS. Non, si vous voulez dire « un fichier LAS enveloppé dans ZIP ». LAZ dispose de sa propre signalisation au niveau du conteneur, dont les valeurs PDRF 128 à 138, un VLR spécial LAZ, un stockage de points compressé par blocs et des mécanismes facultatifs de table de blocs pour l’accès aléatoire. [4]

LAZ réduit-il la qualité d’un nuage de points ?

Pas en lui-même. LAZ est sans perte ; les valeurs de points décodées sont donc les mêmes valeurs que celles qui ont été encodées. Le problème potentiel ne vient pas de la compression elle-même, mais du flux de travail environnant : une mauvaise conversion peut modifier la gestion de l’échelle et du décalage, supprimer les métadonnées de SCR ou perdre les définitions Extra Bytes. [4] [2] [3]

Où le système de coordonnées est-il stocké dans un fichier LAS/LAZ ?

Dans la pratique de l’ère LAS 1.4, le SCR est stocké dans des VLR ou EVLR, et non dans les entiers XYZ eux-mêmes. Les principaux enregistrements LASF_Projection sont 2111 et 2112 pour le contenu WKT, et 34735, 34736 et 34737 pour les métadonnées de SCR de style GeoTIFF. C’est pourquoi consulter uniquement l’en-tête ne suffit pas si vous ignorez les enregistrements de métadonnées. [3]

Quelle est la différence entre les champs PDRF et Extra Bytes ?

Les champs PDRF sont les champs standard garantis par le format de points choisi pour chaque point du fichier. Les Extra Bytes sont des dimensions personnalisées ajoutées, décrites par le schéma LASF_Spec Record ID 4. Si le VLR Extra Bytes est absent, ignoré ou reconstruit incorrectement, les points peuvent toujours se charger, mais les dimensions personnalisées peuvent ne plus être interprétables. [3] [9]

Pourquoi certains outils n’ouvrent-ils pas mes données de formes d’onde LAS/LAZ ?

Parce que la prise en charge des formes d’onde est plus spécialisée que la prise en charge ordinaire des points. Les champs liés aux formes d’onde apparaissent dans les PDRF 4, 5, 9 et 10, et certains logiciels ne les implémentent pas. Le readers.las de PDAL ne prend explicitement pas en charge ces formats de formes d’onde, et LAZ 1.4 n’autorise pas les données EVLR de formes d’onde stockées en interne, exigeant à la place un fichier .WDP auxiliaire. [3] [7] [4]

Comment convertir du LAZ en LAS sans perdre les métadonnées ?

Commencez par inspecter les métadonnées de SCR, le PDRF, l’échelle et le décalage, ainsi que l’existence éventuelle d’Extra Bytes. Utilisez ensuite un outil permettant de préserver ou de transférer explicitement les valeurs d’en-tête et le contenu VLR pertinent. Après conversion, revérifiez le résultat au lieu de supposer que les métadonnées ont été transférées automatiquement, car le comportement des writers dépend de l’outil. [2] [3] [9]

Sources

1. Introduction ASPRS LAS 1.5 (objectif + statut) — https://lasformat.org/latest/01_intro.html
2. Définition du format ASPRS LAS 1.5 (structure, VLR/EVLR, stockage X/Y/Z, échelle/décalage) — https://lasformat.org/latest/02.00_definition.html
3. Standard communautaire OGC LAS 1.4 (17-030r1, publié 2018-03-01) — https://docs.ogc.org/cs/17-030r1/17-030r1.pdf
4. Standard communautaire OGC LAZ 1.4 (24-070r1, publié 2026-06-30) — https://docs.ogc.org/cs/24-070r1/24-070r1.pdf
5. Page de liste des normes OGC LAS (découvrabilité des numéros de documents LAS + LAZ) — https://www.ogc.org/standards/las/
6. Versions GitHub ASPRSorg/LAS (principaux changements LAS 1.5 R00 ; statut LAS 1.4 R16) — https://github.com/ASPRSorg/LAS/releases
7. PDAL readers.las (lecture LAZ + limitation des formes d’onde) — https://pdal.org/en/latest/stages/readers.las.html
8. Note d’atelier sur la compression PDAL (5:1–8:1 typique) — https://pdal.org/en/latest/workshop/introduction/compression.html
9. PDAL writers.las (notes sur le transfert d’en-tête/VLR ; comportement des dimensions supplémentaires/Extra Bytes) — https://pdal.org/en/2.6.3/stages/writers.las.html
10. Manuel des nuages de points QGIS 3.44 (conversion LAS/LAZ → EPT au premier chargement ; mention COPC via le contexte VPC) — https://docs.qgis.org/3.44/en/docs/user_manual/working_with_point_clouds/point_clouds.html
11. Outil Create LAS Dataset d’Esri ArcGIS Pro (note sur 30% de stockage) — https://doc.esri.com/en/arcgis-pro/latest/tool-reference/data-management/create-las-dataset.html
12. Formats de fichiers pris en charge par Autodesk ReCap (import LAS ; export RCP/RCS) — https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
13. USGS Lidar Base Specification 2025 rev. A — Livrables (LAZ 1.4 ; aucun mode compatibilité) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-deliverables
14. USGS Lidar Base Specification 2025 rev. A — Traitement/gestion des données (LAS 1.4-R15 ; PDRF 6–10) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-data-processing-and-handling-requirements
15. Présentation en ligne USGS LBS (date de publication 10 juin 2025) — https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-online
16. PDF de l’article LASzip d’Isenburg (exemples de compression + performances) — https://www.cs.unc.edu/~isenburg/lastools/download/laszip.pdf
17. Site de spécification COPC 1.0 (COPC = LAZ 1.4 + octree ; contraintes PDRF) — https://copc.io/
18. Documentation de compilation CloudCompare (la prise en charge LAS/LAZ dépend de LASzip / plugin) — https://github.com/CloudCompare/CloudCompare/blob/master/BUILD.md
19. FDD de la Library of Congress : description LAS 1.4 (langage clair + contexte de préservation) — https://www.loc.gov/preservation/digital/formats/fdd/fdd000418.shtml
20. Annonce OGC (contexte uniquement, pas pour les dates fermes) — https://www.ogc.org/announcement/ogc-announces-publication-of-the-laz-1-4-community-standard/