You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for storing tiles in Google Cloud Storage buckets, similar to
the existing S3 and Azure blob stores. Tiles are organized using the standard
TMS key structure.
Authentication works through Application Default Credentials (the recommended
approach for GCP), API keys, or anonymously for emulators. All configuration
parameters support environment variable expansion.
Delete operations run asynchronously and use the GCS batch API for efficiency
when removing tile ranges or entire layers. This keeps the main request threads
responsive during bulk operations.
Includes tests using testcontainers with fake-gcs-server, comprehensive
javadocs, and user documentation.
* **bucket**: Mandatory. The name of the GCS bucket where to store tiles.
317
+
* **prefix**: Optional. A prefix path to use as the "root folder" to store tiles at.
318
+
* **projectId**: Optional. The GCP project ID. Can be omitted if using service account credentials that already specify the project.
319
+
* **quotaProjectId**: Optional. Project to bill for quota when using requester-pays buckets.
320
+
* **endpointUrl**: Optional. Custom endpoint URL for use with GCS emulators or compatible services.
321
+
* **useDefaultCredentialsChain**: Optional. Set to ``true`` to use Application Default Credentials. This will look for credentials in the following order: environment variable GOOGLE_APPLICATION_CREDENTIALS pointing to a service account key file, GCE/GKE metadata service, or gcloud CLI credentials.
322
+
* **apiKey**: Optional. API key for authentication. If both apiKey and useDefaultCredentialsChain are provided, apiKey takes precedence.
323
+
324
+
**Note**: Like S3, all configuration properties support environment variable expansion using the ``${VARIABLE_NAME}`` syntax:
325
+
326
+
.. code-block:: xml
327
+
328
+
<bucket>${GCS_BUCKET}</bucket>
329
+
<projectId>${GCS_PROJECT_ID}</projectId>
330
+
331
+
Authentication options:
332
+
333
+
* **Application Default Credentials** (recommended): Set ``useDefaultCredentialsChain`` to ``true``. This works automatically on GCE/GKE and when GOOGLE_APPLICATION_CREDENTIALS points to a service account key.
334
+
* **API Key**: Set the ``apiKey`` property. Less secure, mainly for testing.
335
+
* **No auth**: For use with emulators only. Leave both auth options unset.
336
+
337
+
Implementation notes:
338
+
339
+
Delete operations run asynchronously in a background thread pool. When deleting tile ranges or layers, tiles are removed in batches using the GCS batch API for efficiency. The thread pool is sized based on available processors and shuts down gracefully on blob store destruction.
291
340
292
341
Microsoft Azure Blob Store
293
342
+++++++++++++++++++++++++++++++++++++++++++++
@@ -861,4 +910,4 @@ Additional Information:
861
910
862
911
* The package makes use of the open source multi-cloud toolkit `jclouds <https://jclouds.apache.org/>`_
863
912
* Jclouds documentation for `getting started with Openstack <https://jclouds.apache.org/guides/openstack/>`_
864
-
* Jclouds documentation for `OpenStack Keystone V3 Support <https://jclouds.apache.org/blog/2018/01/16/keystone-v3/>`_ used in config
913
+
* Jclouds documentation for `OpenStack Keystone V3 Support <https://jclouds.apache.org/blog/2018/01/16/keystone-v3/>`_ used in config
BlobStore implementation for Google Cloud Storage.
4
+
5
+
## Overview
6
+
7
+
This module provides a `BlobStore` that stores tiles in a GCS bucket. Tiles are organized using the standard TMS key structure: `<prefix>/<layer>/<gridset>/<format>/<parameters>/<z>/<x>/<y>.<ext>`
8
+
9
+
## Components
10
+
11
+
-`GoogleCloudStorageBlobStore` - Main BlobStore implementation
12
+
-`GoogleCloudStorageClient` - Low-level GCS operations, handles batch deletes via background thread pool
- No auth specified - Anonymous access (useful for emulators)
65
+
66
+
## Notes
67
+
68
+
Delete operations run asynchronously on a background thread pool sized to available processors. The pool shuts down gracefully on blob store destruction with a 60s timeout.
0 commit comments