WIP: Add visualization/titiler pages

docs/explanation/titiler-ecosystem.md

@@ -0,0 +1,53 @@
+# Components of the TiTiler Ecosystem
+
+The TiTiler ecosystem is a comprehensive suite of Python tools for creating dynamic tile servers from geospatial datasets. The components are organized by their primary function:
+
+## Core TiTiler Framework
+
+**titiler.core** - Foundation libraries for creating FastAPI applications that serve dynamic tiles from Cloud Optimized GeoTIFFs (COGs) and SpatioTemporal Asset Catalog (STAC) items.
+
+**titiler.xarray** - Specialized libraries for creating dynamic tile servers from multi-dimensional datasets stored in Zarr or NetCDF formats.
+
+**titiler.extensions** - Plugin system providing additional functionality for TiTiler factories, such as custom algorithms, authentication, and data processing extensions.
+
+**titiler.mosaic** - Libraries for creating dynamic tile servers that can serve mosaicked imagery from multiple sources using the MosaicJSON specification.
+
+**titiler.application** - Complete reference implementation demonstrating a FastAPI application with full support for COGs, STAC items, and MosaicJSON mosaics.
+
+## Specialized Applications
+
+**titiler-cmr** - NASA-focused application that accepts Concept IDs and uses the Common Metadata Repository (CMR) to discover and serve associated granules as tiles.
+
+**titiler-multidim** - Application specifically designed for multi-dimensional datasets, built on titiler.xarray for handling complex scientific data formats.
+
+## Core Libraries
+
+**rio-tiler** - The foundational library that handles the core tile generation logic, dynamically creating map tiles from raster data sources including COGs.
+
+**rio-cogeo** - Command-line tool and library for creating and validating Cloud Optimized GeoTIFFs, ensuring optimal performance for tile serving.
+
+**rio-viz** - Lightweight visualization tool for locally exploring and debugging raster datasets during development.
+
+## Infrastructure Components
+
+**cogeo-mosaic** - Serverless infrastructure toolkit (designed for AWS Lambda) that implements the MosaicJSON specification for creating and serving mosaicked tile sets.
+
+## Development Tools
+
+**tilebench** - Performance analysis tool that measures how many HTTP requests are required to generate tiles from different data sources, helping optimize tile server configurations.
+
+## Extensions and Plugins
+
+**rio-tiler-mvt** - Plugin that extends rio-tiler to generate Mapbox Vector Tiles (MVT) from raster data sources, enabling vector-based visualizations.
+
+## Standards and Specifications
+
+**MosaicJSON** - Open specification for creating spatial indexes that efficiently link multiple COGs to XYZ tile coordinates, enabling seamless mosaicking of large datasets.
+
+## Legacy Components
+
+**riotiler_mosaic** - **(Deprecated)** - Former rio-tiler plugin for creating tiles from multiple observations. This functionality has been integrated directly into rio-tiler and cogeo-mosaic.
+
+---
+
+*The TiTiler ecosystem provides a complete stack for building scalable, cloud-native tile servers that can handle everything from simple COG serving to complex multi-dimensional scientific datasets.*

docs/explanation/visualization.md

@@ -0,0 +1,24 @@
+# Overview of datacube visualization
+
+Datacube visualizations can be sub-divided into two categories: static and dynamic. The contents of a static visualization do not change after creation, similar to printing a map to a piece of paper. Dynamic visualizations respond to user input. For example, a user could change the visualization by zooming in, panning to a different location, or changing the color scheme. This explanation focuses on dynamic visualizations.
+
+## What does it take to dynamically visualize data?
+
+- Rendering engine: A library that displays the data, commonly consisting of a graphics context (e.g., WebGL, SVG, or DOM elements), drawing primitives (points, lines, shapes, textures, meshes), and coordinate systems (e.g., screen space, world space, data space transformations)
+- Framework: Rather than interacting with a rendering engine directly, developers often use frameworks that provide helpful abstractions. Frameworks typically handle layer management and composition, efficient data binding and updates, built-in interaction patterns, and performance optimizations like culling and batching. Geospatial examples include deck.gl and mapbox-gl-js.
+- Data source(s): The data sources for the visualization may be hosted on the site or delivered by a backend server.
+- Backend services: The backend services take requests from the user interface and provide well-formatted responses. This process may involve I/O, format conversion, resampling, aggregation, and computational processing.
+- Data orchestration: The data orchestration layer of the user interface manages the flow of data from sources to the visualization framework, handling API integration (such as connecting to STAC catalogs to discover available datasets) and coordination with backend services (like tiling servers that process and serve datacube slices). For example, when a user selects a specific time range and geographic region, the data orchestration layer translates this selection into the appropriate API calls and ensures the resulting data reaches the framework in the correct format.
+- User interaction layer: The user interaction layer of the user interface handles direct user interactions and visual feedback. It provides interface controls (such as time sliders, layer toggles, and zoom controls), processes user input events (mouse clicks, touches, keyboard shortcuts), and updates the visualization state accordingly. The interaction layer also manages visual feedback like hover effects, selection highlighting, and loading indicators to keep users informed about the system's response to their actions.
+
+
+## What makes datacube visualization different?
+
+Dynamic datacube visualizations require more complex considerations than visualizing 1- or 2-D data sources:
+
+- Multi-dimensional structure: The user interaction layer and data orchestration components need to provide the user a way to specify the dimensionality of the visualization (typically choosing to display 1, 2, or 3 dimensions at a time) relative to the dimensionality of the data source (which can commonly be 3-, 4-, or 5-D).
+- Complex visualization requests: The range of visualization experiences increases with the dimensionality of the dataset. For example, users will often request animations, time-series, or pseudo-3-D visualizations
+- Large scale data sources: Datacubes can exceed many TBs and consist of data spanning thousands of files, which requires further performance optimizations, backend complexity, and sophisticated caching strategies (tile caches, query result caches, etc.).
+- Complexity in data sources: Datacubes may be stored in many different file formats (e.g., GeoTIFF, GRIB, COG, NetCDF, Zarr, etc.) which adds complexity to the backend services. The sources can also span cloud providers (e.g., GCS, AWS) and involve protocols like OPeNDAP.
+- Coordinate reference systems (CRS): Datacubes often involve complex coordinate reference system transformations between data coordinates, geographic projections, and display coordinates.
+- Temporal considerations: Animation frameworks, temporal interpolation, and playback controls are more complex for datacubes, especially when integrating multiple data sources with different temporal resolutions or misaligned time coordinates.

mkdocs.yml

@@ -25,7 +25,9 @@ nav:
       - Default FSSpec caching arguments: "fsspec-caching-defaults.md"
       - Default GDAL config: "gdal-defaults.md"
       - Using old libraries: "old-libraries.md"
-
+  - Datacube Visualization:
+    - "explanation/visualization.md"
+    - "explanation/titiler-ecosystem.md"
 
 
   - Reference: