• Liste des exemples

  • Évaluation mil-sym-ts

    28/11
  • Étendre Geoman

    07/12
  • Édition avec mil-sym-ts

    09/01
  • Édition avec aperçu

    09/01

    Toutes les fonctionnalités de Geoman & GeoCollections avec peu de données

  • Édition avec aperçu

    09/01

    Toutes les fonctionnalités de Geoman & GeoCollections avec peu de données

  • Spécification missions

    05/01
  • Import de fichiers

    21/04
  • Symboles tactiques

    29/04
  • Tuiles 3D

    31/03
  • Lidar IGN

    01/04
  • Maplibre GL Lidar

    01/04

    Évaluation de la librairie

  • Deck GL

    03/04
  • Mapbox GL Draw Performances

    02/07

    experiment latences

  • Donnée de l'IGN pour chaque point:

    • intensity: pourcentage
    • Classification:
      • Never Classified
      • Unclassified
      • Ground
      • Low Vegetation
      • Medium Vegetation
      • High Vegetation
      • Building
      • Water
      • Bridge Deck
      • Class 67

    maplibre-gl-lidar

    la librairie intègre toute la pipeline.

    On fournit le fichier laz brut de l'ign en entrée.

    • reprojection
    • conversion en tuile 3d
    • création d'une couche custom compatible MapLibre via Deck.gl

    c'est presque trop car on a un monolithe pas très flexible.

    Important

    maplibre-gl-lidar intègre la librairie laz-perf qui possède du web assembly via un import bizarre. Grosse incompatibilité avec vite qui optimise les dépendances en les changeant de dossier node_modules/.vite/deps, le chemin est cassé. Impossible de faire un build pour le poc sous react-router (environnement hybride avec ssr).

    Pour pouvoir fonctionner actuellement, j'ai été obligé de hard coder la librairie (cela empêche vite de lancer son dependency pre-bundling).

    Pas viable mais ok pour poc.

    monolithe limitations : Exemple 1

    le code d'intégration ne met pas en avant les layers MapLibre utilisés par la librairie. (pas de commande d'ajout implicite map.addLayer seulement un map.addControl).

    const lidarControl = new LidarControl({
      title: "LiDAR Viewer",
      collapsed: true,
      pointSize: 2,
      colorScheme: "classification",
      zOffset: 0,
      terrainEnabled: false,
    });
    
    map.addControl(lidarControl, "top-right");
    
    lidarControl.loadPointCloud(
      "https://vecmilmaps-public-data.deliastrat.pentatrion.com/3d-tiles-threejs/crest.copc.laz",
    );

    On retrouve notre import dans une méthode privée du PointCloudManager. Ce sera compliqué lors d'une intégration poussée dans une app complète. Comment permettre le zOrder de cette couche si on n'a pas la main dessus.

    class PointCloudManager {
      private _createLayer(id: string): void {
        // some code
        this._deckOverlay.addLayer(`pointcloud-${id}-chunk${chunk}`, layer);
      }
    }

    monolithe limitations : Exemple 2

    La librairie accepte une option pour afficher le relief 3d. Ils n'ont pas porté leur choix sur mapterHorn, du coup si on ne fait pas les mêmes choix techniques qu'eux, la librairie est bancale.

    Voir exemple ci-dessous ou on utilise MapterHorn pour l'élévation. Lorsqu'on trace une ligne, leur fonctionnalité de cross-section ne prend pas en compte l'élévation et la ligne en bleu apparait dessous (-180 m en dessous de crest qui est à une altitude de 180m)

    Elevation

    Conclusion

    Excellente source d'inspiration pour une pipeline complète.

    • import à la volée, pas besoin de conversion préalable.
    • outils avancés notamment la colorisation personnalisable, la cross-section.

    le point noir étant le manque de flexibilité de la librairie. Utilisée dans un projet vide c'est super, dès lors qu'on a des contraintes, on va se retrouver bloqués.