Home › FAQ
The wrapper sits between your client and the Copernicus Data Space Ecosystem (CDSE) Sentinel Hub OGC services. It handles the simplified W,S,E,N bbox format, computes WMS image dimensions from the bbox aspect ratio, converts the acquisition catalogue (WFS) to GeoJSON-LD and RDF, proxies CORS, and adds Memento temporal negotiation over the Sentinel-2 time dimension.
Bounding boxes use the format W,S,E,N in decimal degrees (EPSG:4326, WGS 84): W and E are longitude, S and N are latitude. WMS 1.3.0 and WFS 2.0.0 require lat/lon axis order for EPSG:4326; the wrapper translates from the intuitive lon/lat form automatically.
A WMS image has no zoom level — only a bbox and a pixel size, and each
pixel covers bbox width ÷ image width
of ground. Sentinel-2's visible bands are 10 m per pixel at source, so:
So to “zoom in”, shrink the bbox (keeping the width), until one pixel covers 10 m of ground.
/wms or /wfs URI is the original
resource (latest acquisition) and acts as its own TimeGate:
send an Accept-Datetime: Thu, 05 Jun 2025 12:00:00 GMT header
and the wrapper replies 302 to the corresponding
memento — the same URI with a time= component
identifying a 30-day window ending at the requested date, so the sparse
acquisition series (revisit time, cloud gaps) still yields data.
time= is memento URI syntax minted by the TimeGate and
TimeMap, not a query knob: pick a datetime via Accept-Datetime
or from the TimeMap and follow the links. Memento responses carry
Memento-Datetime and Link
(rel="original timegate", rel="timemap") headers.wms/timemap?layer=…&bbox=…
lists the memento URIs for the bbox (from the instance's
acquisition-catalogue WFS) in application/link-format;
wms/timemap.json adds per-date cloud cover and drives the map
page's time slider. Default window is the last 365 days; pass
time={interval} for other windows. &maxcc=20
drops acquisitions with more than 20 % cloud cover, and the listed
memento URIs keep it, so each renders from the scenes listed.Sentinel-2's visual bands are 10 metres per pixel at the sensor. That is the ceiling: no finer image exists, only that one shown at various scales. You do not have to guess pixel counts — the acquisition catalogue tells you the native grid exactly. There are three levels of access.
1. A convenient render (resampled).
Any tile, the viewer, or a plain
/wms?bbox=&width=&height= is rendered on demand and
resampled to the pixels and projection you ask for. The server caps this at
native resolution, so you can never accidentally upscale, but a slippy-map
zoom pyramid never lands exactly on 10 m (its steps near 48°N are
…12.8, 6.4, 3.2… m/px), so tiles always scale a little.
2. A pixel-true render (no resampling).
Each acquisition in the WFS carries its native projection and raster
extent: crs (the UTM zone the data lives in, e.g.
EPSG:32632) and mbr (its bounds in that CRS). In
RDF these appear as a dcat:bbox in the native CRS. Render in that
CRS at 10 m and there is no reprojection at all — the source grid,
one output pixel per sample:
/wms?layer=TRUE_COLOR&crs=EPSG:32632&bbox={minE},{minN},{maxE},{maxN}&width={(maxE-minE)/10}&height={(maxN-minN)/10}
The numbers come straight off the feature; a full granule is ~10980 px a side, so request a sub-window under the single-image limit.
3. The raw product.
For the literal JPEG2000 band files as stored, follow the acquisition's
rdfs:seeAlso to the
CDSE
catalogue record (also reachable from the id / path
properties). Downloading the bytes needs Copernicus Data Space credentials;
this wrapper links the source but does not proxy it.
/tile/{layer}/{z}/{x}/{y} is one tile of the standard Web
Mercator pyramid — the same z/x/y scheme OpenStreetMap and
Leaflet use. It is not an identifier this wrapper invented: Copernicus
serves the same tiles over WMTS
(PopularWebMercator256, EPSG:3857), and this path renames
TILEMATRIX/TILECOL/TILEROW.
Because a z/x/y denotes one fixed patch of ground, the URI is
stable enough to cite and to cache — unlike
/wms?bbox=…&width=…&height=…, where any of the six numbers
may differ and every request is new work upstream. Ask for it with
Accept: text/turtle (or the .ttl suffix) and you get a
description instead of an image: the tile's footprint, its ground resolution
in metres per pixel, and links to the acquisitions it was rendered from.
Zoom and resolution are tied: a tile at zoom z covers 156543 ÷ 2z metres per pixel at the equator, less away from it. Sentinel-2 is delivered at 10 m/px, so around zoom 13–14 in Europe you are already asking for more detail than the source has; the description says so when that happens.
Every /wms, /wfs and /tile request
spends Sentinel Hub processing units, a metered account resource, so there
is no anonymous access: a request without a valid key gets HTTP status 401.
Get a key, and register your own Sentinel Hub instance for it, at the
account service; your
requests then run on your instance and spend your units. Without an
instance that has the requested layer, the answer is 403.
Send the key as Authorization: Bearer <your-api-key>.
In a browser, enter it once in the viewer's key
field: it is kept in a cookie for this site, so the viewer's images and the
example links on the home page work without a header. The cookie is
SameSite=Strict, so other sites cannot use it.
This is also why the wrapper endpoints take no service parameter and why
no response names the upstream instance URL: that URL's id is all anyone
would need to spend the quota directly, with the rate limit bypassed
entirely. Provenance points at the service
(https://sh.dataspace.copernicus.eu/ogc/wfs), never at the
instance.
Whether the wrapped WMS, WFS and WMTS endpoints are currently reachable — and what layers/feature types they carry — is on the status page, redacted the same way.