EOPF-Sample-Service · konstntokas · Jul 20, 2026 · Jul 16, 2026 · Jul 16, 2026 · Jul 16, 2026
diff --git a/CHANGES.md b/CHANGES.md
@@ -1,7 +1,8 @@
-## Changes in 0.2.10 (in development)
+## Changes in 0.3.0 (in development)
 
 - Sentinel-1 GRD analysis mode is now fully lazy, enabling seamless execution on 
   local and distributed Dask clusters.
+- Add support for Sentinel-1 Level-1 SLC analysis mode.
 
 
 ## Changes in 0.2.9 (from 2026-06-03)

diff --git a/docs/examples/introduction.ipynb b/docs/examples/introduction.ipynb
@@ -4,9 +4,7 @@
    "cell_type": "markdown",
    "id": "c04818c2-3b78-4522-8f7d-aedda2a57c5d",
    "metadata": {},
-   "source": [
-    "# Intoduction to the xarray EOPF backend"
-   ]
+   "source": "# Introduction to the xarray EOPF backend"
   },
   {
    "cell_type": "markdown",
@@ -37,7 +35,7 @@
    "source": [
     "## Install the xarray-eopf Backend\n",
     "\n",
-    "The backend is implemented as an **xarray plugin** and can be installed using either `pip` or `conda/mamba` from the conda-forge channel.\n",
+    "The backend is implemented as a **xarray plugin** and can be installed using either `pip` or `conda/mamba` from the conda-forge channel.\n",
     "\n",
     "- 📦 **PyPI:** [xarray-eopf on PyPI](https://pypi.org/project/xarray-eopf/)  `pip install xarray-eopf`\n",
     "- 🐍 **Conda (conda-forge):** [xarray-eopf on Anaconda](https://anaconda.org/conda-forge/xarray-eopf) `conda install -c conda-forge xarray-eopf`\n",
@@ -89,7 +87,7 @@
    "source": [
     "## Main Features of the xarray-eopf Backend\n",
     "\n",
-    "The xarray-eopf backend for EOPF data products can be selecterd by setting `engine=\"eopf-zarr\"` in `xarray.open_dataset(..)` and `xarray.open_datatree(..)` method. All data access is *lazy*, meaning that data is only loaded when required—for example, during plotting or when writing to storage. It supports two modes of operation:\n",
+    "The xarray-eopf backend for EOPF data products can be selected by setting `engine=\"eopf-zarr\"` in `xarray.open_dataset(..)` and `xarray.open_datatree(..)` method. All data access is *lazy*, meaning that data is only loaded when required—for example, during plotting or when writing to storage. It supports two modes of operation:\n",
     "\n",
     "- **Analysis Mode** *(default)*\n",
     "- **Native Mode**\n",

diff --git a/docs/examples/sentinel_1_analysis.ipynb b/docs/examples/sentinel_1_analysis.ipynb
diff --git a/docs/guide.md b/docs/guide.md
@@ -3,8 +3,8 @@ namely _analysis mode_ (the default) and _native mode_, which are described in
 the following.
 
 An introductory example notebook is available at : 
-- [Docs - Intoduction to the xarray EOPF backend](https://eopf-sample-service.github.io/xarray-eopf/examples/introduction/)
-- [Notebook Gallery - Intoduction to the xarray EOPF backend](https://eopf-sample-service.github.io/eopf-sample-notebooks/introduction/)
+- [Docs - Introduction to the xarray EOPF backend](https://eopf-sample-service.github.io/xarray-eopf/examples/introduction/)
+- [Notebook Gallery - Introduction to the xarray EOPF backend](https://eopf-sample-service.github.io/eopf-sample-notebooks/introduction/)
 
 ---
 
@@ -58,12 +58,12 @@ Additional parameters specific to each Sentinel mission are described below.
 Processing workflows differ significantly across Sentinel-1 product types. Therefore, 
 each product family is documented in its own dedicated section.
 
-> **Note:** Support for SLC products is planned for a future release.
-
 ##### Sentinel-1 Level-1 GRD
 
 > Note: Support for Sentinel-1 GRD products in analysis mode is 
-> currently experimental and undergoing validation.
+> currently experimental and undergoing validation. Some conversion parameters 
+> are missing in the new EOPF product, which are currently estimated. Newer EOPF
+> product version will include these parameters. 
 
 Sentinel-1 Level-1 GRD data is provided in radar geometry, defined by the coordinates
 (`azimuth_time`, `ground_range`). To transform this data into an
@@ -120,6 +120,70 @@ Examples:
 
 - [Docs – Sentinel-1 Analysis Mode](https://eopf-sample-service.github.io/xarray-eopf/examples/sentinel_1_analysis/)
 
+##### Sentinel-1 Level-1 SLC
+
+> Note: Support for Sentinel-1 SLC products in analysis mode is
+> currently experimental and undergoing validation.
+
+Sentinel-1 Level-1 SLC data is provided in radar geometry, defined by the coordinates
+(`azimuth_time`, `slant_range_time`) and organized in bursts and swaths. To transform
+this data into an **analysis-ready dataset**, the following processing steps are applied:
+
+1. **Radiometric Calibration:** For each burst complex SLC measurements are 
+   converted into `beta0` backscatter values using the `beta_nought` calibration 
+   lookup table (LUT).
+2. **Burst and Swath Merging:** Valid burst regions are extracted using burst metadata,
+   merged along azimuth time, aligned across swaths, and then merged along slant range
+   to produce one continuous acquisition grid per selected polarization.
+3. **Geometric Terrain Correction (GTC):** Using a Digital Elevation Model (DEM),
+   the processor performs **inverse geocoding** by solving the zero-Doppler equation
+   based on satellite orbit information and terrain elevation. This step maps the
+   data from radar geometry to a georeferenced grid.
+4. **Radiometric Terrain Correction (RTC):** (Optional) RTC compensates for
+   terrain-induced radiometric distortions such as foreshortening, layover,
+   and slope-dependent brightness variations.
+
+📖 [D. Small, *Flattening Gamma: Radiometric Terrain Correction for SAR Imagery*](https://ieeexplore.ieee.org/document/5752845)
+
+**Supported Products:**
+
+- Sentinel-1 Level-1 SLC
+
+**Supported Variables**
+
+- **Polarization bands**:
+  `vv`, `vh`, `hh`, `hv` *(each SLC product contains only a subset of these bands)*
+
+**Specific Sentinel-1 Level-1 SLC parameters `**kwargs`:**
+
+- `crs`: Coordinate reference system of the output dataset. Can be provided as a
+  `str` or a `pyproj.CRS` object. If a string is given, it will be parsed using
+  [`pyproj.crs.CRS.from_string`](https://pyproj4.github.io/pyproj/dev/api/crs/crs.html#pyproj.crs.CRS.from_string).
+  If not specified, [EPSG:4326](https://epsg.io/4326) is used.
+- `resolution`: Target resolution for all spatial variables expressed in the units
+  of the specified `crs`. If not specified, the resolution is derived from the DEM
+  (see `dem` below).
+- `dem`: Digital Elevation Model (DEM) as a CF-compliant `xarray.DataArray` used for
+  terrain correction. If provided, the parameters `crs`, `bbox`, and `resolution` are
+  ignored, and the target grid is derived from the DEM. If not provided, the
+  [CopDEM COG (30 m)](https://browser.stac.dataspace.copernicus.eu/collections/cop-dem-glo-30-dged-cog) in geographic coordinates
+  is retrieved automatically via the CDSE STAC API. This requires
+  [CDSE S3 credentials](https://documentation.dataspace.copernicus.eu/APIs/S3.html#generate-secrets).
+- `apply_rtc`: Enable or disable radiometric terrain correction (RTC). Default is `True`.
+- `interp_methods`: Interpolation method used during GTC and RTC. Supported methods:
+  `nearest`, `bilinear`.
+- `footprint_scale_factor`: Defines how radar pixels contribute to the output grid.
+  Default: `(3.0, 15.0)`, reflecting the different scaling used for azimuth and
+  slant-range processing of SLC data.
+- `cache_uri`: Temporary path used to store intermediate results from the
+  backward geocoding step in the Sentinel-1 processing workflow. The cache is
+  automatically removed when the Python process exits. If `None`, a temporary
+  directory with a unique UUID-based name is created.
+
+Examples:
+
+- [Docs – Sentinel-1 Analysis Mode](https://eopf-sample-service.github.io/xarray-eopf/examples/sentinel_1_analysis/)
+
 ##### Sentinel-1 Level-2 OCN
 
 Sentinel-1 Level-2 OCN products are geolocated datasets provided on their 
@@ -186,7 +250,7 @@ Sentinel-2 provides multi-spectral imagery at different native resolutions:
 The analysis mode enables resampling between these different resolutions, bringing 
 bands from multiple resolutions onto the same grid using [affine transformation via xcube-resampling](https://xcube-dev.github.io/xcube-resampling/guide/#1-affine-transformation).
 
-**Suported Products:**
+**Supported Products:**
 
 - [Sentinel-2 Level-1C](https://stac.browser.user.eopf.eodc.eu/collections/sentinel-2-l1c)
 - [Sentinel-2 Level-2A](https://stac.browser.user.eopf.eodc.eu/collections/sentinel-2-l2a)
@@ -258,7 +322,7 @@ For OLCI products, no additional terrain correction is required, as it is alread
 incorporated in the Level-1 data. See the [OLCI Level-1 product description](https://sentiwiki.copernicus.eu/web/olci-products#OLCIProducts-L1BProducts-ObservationModeS3-OLCI-Products-L1B-OM)
 for details.
 
-**Suported Products:**
+**Supported Products:**
 
 - [Sentinel-3 OLCI Level-1 EFR](https://stac.browser.user.eopf.eodc.eu/collections/sentinel-3-olci-l1-efr)
 - [Sentinel-3 OLCI Level-1 ERR](https://stac.browser.user.eopf.eodc.eu/collections/sentinel-3-olci-l1-err)

diff --git a/docs/index.md b/docs/index.md
@@ -55,7 +55,7 @@ datatree = xr.open_datatree(url_or_path, engine="eopf-zarr", op_mode="native")
 More information on the two modes are given in the [User Guide](guide.md)
 
 Data variables will always be represented as chunked Dask arrays for 
-efficient out-of core computations and visualisations.
+efficient out-of core computations and visualizations.
 
 The package has minimal core dependencies: `xarray`, `zarr`, and `dask`.
 Packages for accessing remote filesystems are optional, e.g., you will need `s3fs`
@@ -64,5 +64,5 @@ if you need to access EOPF data products in S3-compatible remote object storages
 ## License
 
 The package is open source and released under the 
-[Apache 2.0 license](https://www.apache.org/licenses/LICENSE-2.0.html) license. :heart:
+[Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) license. :heart: