Data Usage in Possible Applications ​

EOxCloudless products are shipped in either TileDirectory format or one of the two single file cache formats (GeoPackage or Mapcache SQLite). Single file subsets can be generated for smaller AOIs upon request.

GeoTIFF TileDirectories ​

The "Tile Directory" format, often referred to as a tile pyramid structure, is a highly efficient and widely adopted method for organizing and serving large geospatial raster (image) or vector (feature) datasets. Its fundamental reasoning stems from the need to manage vast amounts of geographic information in a way that is both performant for access and scalable for storage, especially in web-based mapping applications.

Reasoning Behind the Format ​

The primary motivation for the tile directory structure is to overcome the limitations of handling massive, monolithic geospatial files, particularly when dealing with global-scale data or high-resolution imagery. A single, high-resolution image of a large area would be too large to load entirely into memory or transmit efficiently over a network. The tile pyramid addresses this by:

  1. Divide and Conquer: Breaking down a vast geographic area into numerous smaller, manageable, and discrete tiles. Each tile represents a small, rectangular portion of the map at a specific zoom level.
  2. Multi-Resolution Access (Pyramiding): Providing data at multiple levels of detail (zoom levels). At lower zoom levels, fewer, larger tiles represent a broader area with less detail. As you zoom in, more, smaller tiles provide progressively finer detail. This ensures that only the necessary level of detail is loaded or rendered, optimizing performance and reducing data transfer.
  3. Efficient Spatial Indexing: The hierarchical directory structure acts as a natural spatial index. When a user or application requests data for a specific geographic bounding box and zoom level, the corresponding tile(s) can be directly computed and accessed without having to scan or process the entire dataset.
  4. Web Optimization: Web browsers and mapping libraries are inherently good at requesting many small files in parallel. This structure allows web maps to fetch only the visible tiles, leading to fast loading times and a smooth user experience as users pan and zoom.

Key Features of the Tile Directory Format ​

  • Hierarchical Structure:
    • Organization into a folder hierarchy is typically: /{zoom}/{x}/{y}.{extension} or sometimes /{zoom}/{row}/{col}.{extension}
    • zoom: Represents the level of detail, with 0 being the coarsest (entire world in one tile) and increasing numbers indicating finer detail.
    • x (or col): The column index of the tile within that zoom level.
    • y (or row): The row index of the tile within that zoom level.
    • extension: The file format of the individual tile (e.g., .tif for GeoTIFF, .png or .jpg for image tiles, .pbf for vector tiles).
  • Grid System:
    • Tiles are arranged on a regular grid, usually a square grid, based on a defined tiling scheme (e.g., Web Mercator, Geographic Lat/Lon). Each standard tile has a fixed size in pixels (e.g., 256x256 or 512x512 pixels) for display.
  • Standardization (e.g., WMTS, XYZ):
    • The concept is highly standardized, with common implementations like the XYZ tiling scheme (which follows the /{z}/{x}/{y} convention) and the OGC's Web Map Tile Service (WMTS) specification. This standardization ensures interoperability between different mapping clients and servers.
  • Scalability:
    • Storage: Large datasets can be distributed across many small files, making them easier to manage, backup, and store on distributed file systems.
    • Processing: Individual tiles can be generated, updated, or reprocessed independently and in parallel. If data for a specific region changes, only the affected tiles need to be regenerated, rather than the entire dataset.
  • Cacheability:
    • Because tiles are static files, they are highly cacheable at various levels (browser cache, CDN, proxy servers). This significantly reduces server load and improves delivery speed for frequently accessed areas.
  • Format Flexibility:
    • While often associated with image formats like PNG or JPEG for web maps, the individual tiles can store various geospatial data types, including GeoTIFF (for raw raster data), PNG (for transparent imagery), or Protocol Buffer Vector Tiles (for vector features).
  • Metatiling (Reducing File Count):
    • In contexts where generating or storing millions or billions of small individual tiles can become cumbersome due to file system overhead or the sheer volume of files, metatiling is employed as an optimization strategy. Instead of generating and storing each standard 256x256 pixel tile as a separate file, a larger "metatile" is produced which is composed of multiple standard tiles (e.g., a 2x2, 4x4, or 8x8 block of standard tiles combined into a single file). This larger file then covers a broader geographic area. While client-side mapping applications still request standard 256x256 tiles, the server (or data access layer) reads the containing metatile and extracts the requested portion. This approach significantly reduces the total number of files on disk, lowering I/O overhead, speeding up directory listings, and making data management more efficient, particularly for dense tile sets at high zoom levels.

In essence, the tile directory format is a robust and fundamental pattern in modern geospatial data management, enabling efficient access, display, and processing of large geographic datasets. Metatiling serves as a critical backend optimization for tile generation and storage, primarily by reducing the total number of files, thereby enhancing overall system performance and manageability.

STAC Tiled Assets - STACTA ​

While the tile directory format is excellent for organizing and serving data, explicitly listing millions of individual tiles in a catalog becomes impractical. The SpatioTemporal Asset Catalog (STAC) specification, in conjunction with its Tiled Assets Extension, and GDAL's capabilities offer a standardized and efficient way to describe and access such large tiled datasets programmatically.

The STAC Tiled Assets Extension addresses the challenge of cataloging extremely large datasets that are inherently split into numerous tiles (like global mosaics or high-resolution imagery). Instead of enumerating every single tile file, this extension allows data providers to describe tiled assets using templates and rules for constructing the actual tile URLs.

Here are some Key Aspects: of the STACTA format:

  • Templated URLs: The core of the extension is the asset_templates property within a STAC Item (or Collection/Catalog). This property holds URL patterns where components like {z}, {x}, {y}, or {TileMatrixSet} can be substituted to generate the precise URL for any given tile. This drastically reduces the metadata size by abstracting away individual file paths.
  • Tile Matrix Sets (TMS): It leverages the concept of Tile Matrix Sets (often based on OGC Two-Dimensional Tile Matrix Set standards), which define the grid system, zoom levels, tile dimensions, and coordinate reference systems for the tiled data. The STAC extension can reference or embed these TMS definitions.
  • Reduced Metadata Overhead: For data providers, this means they don't need to generate and list individual STAC assets for every single tile, which would result in enormous catalog files. Instead, a concise template can represent an entire tile pyramid.
  • Discovery and Access: For data users, a STAC catalog with the Tiled Assets Extension makes it easy to discover vast tiled datasets. Once discovered, clients or tools can programmatically construct URLs for specific tiles or regions of interest based on the provided templates and TMS definitions.

Example (Conceptual STAC Item: my_tiled_asset_item.json):

This simplified example shows a STAC Item where the href in the main asset can point to a representative file, while tiles:asset_templates defines the relative path pattern for individual tiles within the same package.

json
{
  "type": "Feature",
  "stac_version": "1.0.0",
  "id": "my-tiled-dataset-item",
  "properties": {
    "datetime": "2023-01-01T00:00:00Z"
  },
  "geometry": { /* ... bounding box geometry ... */ },
  "links": [],
  "assets": {
    "data": {
      "href": "./tiles/meta_0_0.tif",
      "type": "image/tiff; application=geotiff; profile=cloud-optimized",
      "roles": ["data"],
      "tiles:asset_templates": {
        "default": {
          "href": "./tiles/{z}/{x}/{y}.tif",
          "type": "image/tiff; application=geotiff; profile=cloud-optimized"
        }
      },
      "tiles:tile_matrix_set_links": [
        {
          "href": "https://www.opengis.net/def/tilematrixsets/..." 
        }
      ]
    }
  },
  "bbox": [ /* ... bounding box coordinates ... */ ],
  "stac_extensions": [
    "https://stac-extensions.github.io/tiled-assets/v1.0.0/schema.json"
  ],
  "collection": "my-tiled-collection"
}

Accessing Tiled Directories with GDAL via STAC ​

GDAL (Geospatial Data Abstraction Library) is a powerful open-source library for reading and writing raster and vector geospatial data formats. When a STAC Item JSON file describes a tiled asset using the Tiled Assets Extension, GDAL can directly interpret this metadata to access the underlying tiled directory. This allows GDAL to treat a collection of physically distributed tiles as a single, virtual raster dataset. It is a GDAL driver since GDAL version 3.3: https://gdal.org/en/stable/drivers/raster/stacta.html.

  • Direct STAC Item Interpretation:
    • GDAL can open a STAC Item JSON file directly. Upon reading the JSON, it identifies the tiles:asset_templates and tiles:tile_matrix_set_links properties within the assets. This allows GDAL to understand the structure of the tiled data without needing to be explicitly told it's a "tiled assets" source.
  • Virtual Mosaic Creation:
    • GDAL creates a virtual mosaic from the described tiled data. This means you can use standard GDAL tools (like gdalinfo, gdalwarp, gdal_translate) as if you were working with one large file, even though the data is physically distributed across many tiles within the tile directory.
  • On-the-Fly Access:
    • When you request a specific area or resolution, GDAL intelligently parses the STAC metadata, uses the tile templates, and fetches only the necessary tiles (or portions of metatiles) to fulfill the request. This avoids downloading or processing the entire dataset.
  • Projection and Resampling Handling:
    • GDAL can handle tiles with different projections and perform on-the-fly re-projection and resampling to present a consistent view to the user.
  • Use Cases:
    • Simplified Data Access: Open large tiled datasets described by a STAC Item JSON file directly, without needing to manually construct tile paths.
    • Processing Subsets: Efficiently extract or process specific areas of interest from a vast tiled dataset.
    • Seamless Tool Integration: Integrate STAC-described tiled data into existing geospatial workflows that rely on GDAL.

Example Usage (Command Line - Referring to a STAC Item JSON file):

Assuming you have a STAC Item JSON file (e.g., my_tiled_asset_item.json) that describes your tiled data, and this STAC Item contains only one asset describing the tiled data, you can use GDAL as follows:

bash
gdalwarp "STACTA:my_tiled_asset_item.json" output_subset.tif -te 10 45 11 46

VRT (Virtual Raster Dataset) ​

GDAL's Virtual Raster Dataset (VRT) format provides a powerful way to organize and access multiple raster datasets (including individual tiles from a tile directory) as if they were a single, cohesive raster file. A VRT is an XML file that describes the spatial relationship and properties of its constituent source datasets without duplicating the actual pixel data.

A VRT file (.vrt extension) is essentially a virtual mosaic. It's an XML document that defines how one or more source raster datasets (like GeoTIFFs, PNGs, or even other VRTs) are combined to form a single virtual dataset. When a GDAL tool or application opens a VRT, it reads this XML definition and accesses the underlying source files only as needed, on-the-fly.

  • Non-Destructive Mosaic:
    • VRTs allow you to mosaic numerous individual raster files into one logical dataset without creating a new, massive physical file. This saves disk space and avoids data duplication.
  • On-the-Fly Processing:
    • Mosaicking: Seamlessly stitching together adjacent tiles.
    • Reprojection: Presenting data in a different coordinate reference system than the source tiles.
    • Resampling: Changing pixel resolutions.
    • Band Merging/Selection: Defining which bands from the sources are included.
  • Flexible Source Types:
    • VRTs can integrate source datasets of different file formats, projections, resolutions, and even local or remote paths.
  • Simplifies Workflows:
    • Tools that can open a single raster file can then operate on the entire virtual mosaic described by the VRT, greatly simplifying processing scripts.

For a tile directory, a VRT would typically list every individual tile file (/{z}/{x}/{y}.tif) as a separate source dataset within its XML structure. When you open this VRT, GDAL understands the spatial extent of each tile and how they fit together to form the complete mosaic. When you request a specific area, GDAL figures out which underlying tiles are needed, reads only those, and combines them on the fly.

Example VRT Usage (Command Line):

  1. Building the VRT from a Tile Directory: You can use gdalbuildvrt to automatically generate a VRT file from all the GeoTIFFs (or other raster files) within a tile directory.

    bash
    # Assuming your tile directory is named 'my_tiled_data'
# and contains subdirectories like 10/100/150.tif

gdalbuildvrt my_tiled_data.vrt my_tiled_data/*/*/*.tif

    This command recursively finds all .tif files within my_tiled_data and its subdirectories and adds them as sources to my_tiled_data.vrt.

  2. Accessing Data via the VRT: Once the VRT file is created, you can use any GDAL tool to interact with it as if it were a single raster file.

    bash
    gdalinfo my_tiled_data.vrt
# Example: Warp a subset of the data
gdalwarp my_tiled_data.vrt output_subset.tif -te 10 45 11 46

WARNING: Scalability Limitations with VRT for Large Tile Directories, while VRTs are incredibly useful for combining a moderate number of files, they have significant scalability limitations when dealing with very large tile directories (e.g., millions or billions of individual tiles, as found in global datasets or high-resolution imagery over vast areas).

The primary reasons for this limitation is: XML File Size and Parsing, the VRT file itself is an XML document. For every single tile it references, it needs an entry. A directory containing millions of references and exceed an efficient reading rate of the referenced objects, due to lack of indexing.

Single File Caches ​

The Viewing Ready products are also prepared as single files around 1 TB large for each of the global datasets. Each of these has a distinct primary purpose depicted in following chapters. The formats are:

  • Mapcache SQLite - .sqlite
  • GeoPackage - .gpkg

GeoPackage ​

The EOxCloudless GeoPackage from cloudless.eox.at provides seamless, cloud-free global satellite imagery optimized for direct use in GIS applications. Packaged in the versatile GeoPackage format (an OGC standard), it can be opened directly in software like QGIS or ArcGIS without requiring an internet connection or any additional setup.

The imagery is a Sentinel-2 mosaic—namely the EOxCloudless dataset from s2maps.eu—visually balanced and cloud-free. It is organized as an internally tiled raster layer, enabling fast rendering even at large scales.

Typical use cases include using it as a high-quality, neutral basemap for spatial analysis, cartographic design, and thematic overlays. Its consistent, cloud-free nature makes it especially suitable for digitization, inspection, or context layers in land monitoring, planning, or environmental studies.

Unlike web map services, the local GeoPackage format ensures stable performance offline and in offline environments. Spatial indexing allows efficient zooming and panning over large regions. Users can load the dataset as a base layer, and can overlay it with vector data like roads, boundaries, or sensor footprints. It is a portable, high-resolution, and GIS-ready background layer for professional workflows.

Mapcache SQLite Cache ​

The MapCache SQLite cache format is a compact, efficient tile storage solution used in self-hosted web map services powered by MapCache - https://mapserver.org/mapcache/, a fast tile caching server from the MapServer project. It stores pre-rendered map tiles in a SQLite database, making it ideal for deploying responsive WMS or WMTS endpoints without relying on cloud-based services or external storage.

When configured with a tile-generating backend (like MapServer or mod_tile), MapCache serves map tiles directly from the SQLite cache, significantly reducing rendering time and server load. The SQLite backend supports both read-only prefilled tiles (e.g. for basemaps like EOxCloudless) and on-demand tile generation with automatic caching.

The SQLite format is particularly well-suited for deployment scenarios that require:

  • Offline or on-premises operation
  • Low-resource servers or embedded systems
  • Self-contained deployments (e.g. Docker, field laptops)

It enables smooth serving of large datasets via standard OGC protocols, with support for tile pyramids, projections, and layer definitions. Administrators can preload the cache or populate it on-the-fly.

In essence, MapCache with SQLite provides a robust, scalable, and portable option for hosting your own web map services with minimal infrastructure and full control over your data.

EOxMaps Tile Services ​

EOX offers high-quality, publicly accessible tile-based map services using standard protocols: WMTS (Web Map Tile Service) and WMS (Web Map Service). These services provide access to global, cloudless Sentinel‑2 mosaics and base layers widely used in satellite mapping applications, such as s2maps.eu.

Tile Service Endpoints ​

Supported Tile Matrix Sets ​

  • EPSG:3857 – GoogleMapsCompatible (Web Mercator Quad)
  • EPSG:4326 – WGS 84 Geographic

These coordinate systems ensure compatibility with most web mapping frameworks and GIS tools.

Commonly Available Layers ​

Layer NameDescription
overlayOverlay with borders and various points of interest
overlay_brightBright overlay with borders and various points of interest
s2cloudlessSentinel‑2 cloudless mosaic for various years
terrain-lightLight-themed terrain basemap
terrainNatural-like-themed terrain basemap

These layers provide global, cloud-free, natural-color mosaics suitable for background imagery, basemaps, or some basic overlays.

Customizable Data Conversion and Consultation ​

While EOx Cloudless provides standardized, global Sentinel-2 mosaics ready for immediate use, we also offer custom processing services tailored to specific project or institutional needs. These optional services are available at an additional fee and are designed to enhance flexibility, integration, and visual consistency across various platforms and applications.

Custom Color Correction ​

For users requiring consistent aesthetics across multiple regions or time periods, EOX offers bespoke color correction and tuning of the Sentinel-2 mosaics. Our team can adjust the tone, contrast, and color balance of the mosaics to match branding guidelines, integrate seamlessly with existing basemaps, or meet specific visual interpretation standards (e.g., different contrast, cooler tones, or enhanced feature representation).

Corrections are performed using calibrated workflows designed for large-scale satellite imagery, ensuring that resulting datasets retain the geospatial accuracy and radiometric consistency of the original product.

Example of Custom Color Correction EOxCloudless 2020

Data Format Conversion Supporting GDAL Raster Formats ​

EOX provides custom data format conversion services to deliver Sentinel-2 mosaics in a variety of raster formats fully compatible with the GDAL ecosystem. These formats include GeoTIFF (including Cloud-Optimized GeoTIFF), MBTiles, and other widely used geospatial raster standards.

This enables seamless integration into GIS and remote sensing workflows, facilitating analysis, visualization, and processing with popular open-source tools and libraries. Conversions can also include customized tiling schemes or optimized compression tailored to your specific use case, ensuring efficient storage and fast access.

Requesting a Custom Order ​

To inquire about custom color correction, data formatting, or bulk delivery options, please contact us via email at cloudless@eox.at. We are happy to consult on the most suitable configuration and provide a tailored quote based on your requirements and region of interest.

We use optional cookies to improve your experience and for marketing. Read our privacy policy or manage cookies.