Data Collection Usage Details
This is the detailed companion to the main usage page. It covers how Data Collection usage is computed: streaming and analysis across the Catalog, Processing, Statistical, and OGC APIs, plus bringing your own data (BYOC), with worked examples.
Once your data is delivered to a data collection, you can stream it and run analysis against it directly on the Planet Insights Platform, using the Catalog, Processing, Statistical, and OGC APIs. This page explains how Monitoring Credits are consumed for these requests. The exact numbers vary with the specific API payload, data collection, and optional factors. Bringing your own data with the BYOC or Zarr API is covered in its own section below.
How Usage Is Computed
How a request is metered depends on what it does:
- Data processing (Processing, Statistical, and OGC APIs) scales with the pixels processed.
- Data querying (Catalog API and OGC WFS) scales with the area and time period searched.
- Bringing your own data (BYOC and Zarr APIs) is metered per management request.
Data Processing
Applies to the Processing, Statistical, and OGC (WMS/WCS) APIs.
This equation is documented for transparency and to help you estimate usage. It will evolve as the platform adds capabilities, so treat it as approximate. For exact per-request usage, read the X-Planet-MonitoringCredits response header, especially for complex analyses like SuperRes or long time-series, where many factors combine.
As a rough guide, 1 credit lets you stream about:
- ~11 true-color tiles (512 × 512 px, 3 bands), or
- ~26 sq km of true-color PlanetScope at 3 m resolution.
These figures are approximate. Usage scales with the amount of data a request processes, measured against a baseline of 512 × 512 px of input, three bands, one date, and a standard format. Every other term scales that baseline:
The formula has two parts: a data-preparation term (everything before the +) and a logic-execution term (the execution time, scaled by advanced processing hardware). For most requests the second term is zero.
The result is then floored at a small per-request minimum (see Per-request minimums).
Monitoring Credits are consumed only when a request completes successfully (returns a 2XX response).
Core Equation Factors
| Term | Meaning |
|---|---|
| area ÷ 512×512 px | Requested input area (BBOX) divided by the 512 × 512 px baseline. Larger area, more credits. Minimum multiplier 0.01. |
| bands ÷ 3 | Number of input bands requested, relative to a 3-band request. dataMask is not counted unless it is the only band. |
| dates | Number of dates (data samples / time slices) per pixel. Multi-temporal requests scale directly with this. |
Two more terms adjust the total: optional factors (output format, data fusion, Sentinel-1 preprocessing) and logic execution factors (evalscript execution time on advanced processing hardware). Each is detailed below.
Optional Factors
These multipliers apply on top of the core factors above. Each is 1 (no effect) unless the request triggers it:
| Factor | Rule |
|---|---|
| Output format | - Standard 8-bit or 16-bit format (TIFF, JPG, PNG) is ×1 - 32-bit float TIFF is ×2 - application/octet-stream is ×1.4 |
| Data fusion | Applied only when fusing collections. The factor is the count of local collections plus twice the count of remote collections: count(local) + 2 × count(remote). |
| Sentinel-1 preprocessing | Speckle filtering (×2) multiplied by a terrain factor: radiometric terrain correction ×2.5, or orthorectification alone ×2 (RTC already includes orthorectification). For example, speckle filtering with RTC is ×5. |
Logic Execution Factors
The logic-execution term is added after the data-preparation term. The evalscript execution time is scaled by an advanced processing hardware multiplier:
| Factor | Rule |
|---|---|
| Evalscript execution time | The base request charge covers the first 100 ms of execution. Each subsequent 100 ms interval adds a 0.05 credit surcharge. |
| Advanced processing hardware | Multiplies the execution time by the number of cores the request runs on. SuperRes runs on 8 cores (×8). |
Per-Request Minimums
Each request is floored at a small minimum:
| API | Minimum per request |
|---|---|
| Processing API & OGC API | 0.0005 credits |
| Statistical API | 0.001 credits |
Async and Batch
The same per-pixel method applies whether you run a request synchronously or hand it off for asynchronous or batch processing. The variants differ in their per-request minimum and in an efficiency factor that lets larger jobs process more data per credit: Asynchronous Processing applies a ×2/3 factor, so you can process up to 1.5× more data for the same credits, and Batch Processing applies a ×1/3 factor, so you can process up to 3× more data.
| Variant | Efficiency factor | Minimum per request |
|---|---|---|
| Processing / OGC (sync) | none | 0.0005 credits |
| Asynchronous Processing | ×2/3 for areas ≥ 10,000 px | 1 credit |
| Batch Processing | ×1/3 for tiles > 10,000 px | 10 credits |
| Batch Statistical | same rate as the Statistical API | 10 credits |
Cross-Region and Cross-Cloud Delivery
Delivering output across regions or clouds adds a small per-volume amount:
- 2.8 credits/GB for cross-region within the same cloud provider
- 9.4 credits/GB for cross-cloud delivery.
Example Calculations
Three representative requests, one per processing path. The first two are computed against the equation above so they stay internally consistent; the SuperRes breakdown is anchored to a measured total, since its model-inference time cannot be predicted from the equation.
Streaming 100 RGB Tiles (Process API)
This example streams 100 standard tiles to review an area. Each tile is a 512 × 512 px output, true-color RGB, single date, so every tile matches the baseline and uses the base amount.
| Parameter | Quantity | Factor |
|---|---|---|
| Requests | 100 (one tile each) | 100 |
| Area | 512 × 512 px (baseline) | 1 |
| Bands | 3 (RGB) ÷ 3 | 1 |
| Dates | 1 per tile | 1 |
| Total | 0.0917 × 100 × 1 × 1 × 1 | ≈ 9 credits |
Monthly NDVI Statistic (Statistical API)
This example computes a monthly NDVI statistic over a 1 sq km PlanetScope field at 3 m resolution. NDVI uses two bands (Red and NIR); a month of daily PlanetScope acquisitions gives roughly 30 dates; statistical output defaults to a float format.
| Parameter | Quantity | Factor |
|---|---|---|
| Area | 1 sq km at 3 m ≈ 0.424 | 0.424 |
| Bands | 2 (Red, NIR) ÷ 3 | 2/3 |
| Dates | ~30 in the month | 30 |
| Format | float | 2 |
| Total | 0.0917 × 0.424 × 2/3 × 30 × 2 | ≈ 1.6 credits |
SuperRes Over a 1 Sq Km Area (Processing API)
SuperRes runs a deep-learning model on advanced processing hardware, so its usage is dominated by the logic-execution term rather than data preparation. A measured 1 sq km request (PlanetScope RGB input, 2 m super-resolved output) used about 12 credits. The total is measured; the breakdown below is illustrative, since model inference time is hard to predict.
| Parameter | Quantity | Factor |
|---|---|---|
| Area | 1 sq km at 3 m ≈ 0.424 | 0.424 |
| Bands | 3 (RGB) ÷ 3 | 1 |
| Dates | 1 | 1 |
| Execution time | ~3100 ms → 30 × 100 ms after the first 100 ms | 30 × 0.05 |
| Hardware | runs on 8 cores | 8 |
| Total | 0.0917 × 0.424 + (30 × 0.05 × 8) | ≈ 12 credits |
Data Querying
Applies to the Catalog API and OGC WFS. Instead of output pixels, usage scales with the queried area (against a 1000 km × 1000 km reference) and the time period (rounded up to whole months).
A reference request is defined as a search over an area of 1000 km × 1000 km for a time period of one month, and is 0.1 credits. Each request is floored at a minimum of 0.001 credits and capped at 0.1 credits.
Bring Your Own COG and Zarr
- Each non-GET request to the BYOC or Zarr API uses 0.1 credits.
- Using your BYOC and Zarr collections consumes credits the same way as data processing above.