CoastSat: extracting 40 years of shoreline position from satellite imagery

Shorelines from Landsat and Sentinel-2 through Google Earth Engine

The scope is a very long time series from freely available imagery. CoastSat is described as an open-source software toolkit written in Python that enables users to obtain time-series of shoreline position at any coastline worldwide from 40 years and growing of publicly available satellite imagery, naming Landsat and Sentinel-2 as the sources. The motivation is stated plainly in the project description: satellite remote sensing can provide low-cost long-term shoreline data capable of resolving the temporal scales of interest to coastal scientists and engineers at sites where no in-situ field measurements are available. That sentence defines both the value and the limit of the toolkit, because a satellite observation is a low-cost proxy for a measurement that would otherwise need a person with a tape measure on a beach. The imagery is retrieved from Google Earth Engine, which is where the pre-processing happens as well, including re-projecting the different bands, pansharpening and advanced cloud masking. The retrieval covers the region of interest and time period that the user defines, so the tool is a pipeline over a chosen window rather than a global product.

Sub-pixel segmentation plus a classifier that refuses to guess at rock

The detection algorithm is where the engineering went, and the documentation is precise about its shape. The algorithm is optimised for sandy beach coastlines, and it combines a sub-pixel border segmentation with an image classification component which refines the segmentation into four distinct categories, such that the shoreline detection is specific to the sand and water interface. That second half matters as much as the first. A purely spectral boundary detector will happily return an edge anywhere in the image, including the edge of a rock or a shadow, and the classification stage is what keeps the result on the sand and water boundary rather than on some other contrast in the scene. The output is a set of shorelines extracted from all selected images, with a sub-pixel resolution technique and options for quality control, and the quality control step is what makes the later time series usable. The four categories themselves are not enumerated in the documentation, so a user cannot rely on the class labels without reading the classification module. The optimised-for-sandy-beaches caveat is stated in the project description, and it is the single most important constraint for anyone considering a rocky, mangrove or engineered shoreline.

Transects turn shorelines into a change time series

A shoreline on its own is a curve, and the useful output is a rate of movement along a direction. The third listed capability is the intersection of the two dimensional shorelines with user-defined shore-normal transects to create time series of shoreline change. This is the step that makes the tool answer the question a coastal engineer actually asks, which is how far did the beach move between 2015 and 2020, and the transects are supplied by the user, which means the choice of where to measure is a scientific decision rather than an automatic one. The example outputs in the repository show the shape of the working data, with a transects file in GeoJSON format alongside a saved pickle of the run, a tide file and a tidally corrected time series in CSV, and a polygon in KML format for the region of interest. The GeoJSON and KML formats also mean the transect and region definitions can be drawn in a standard GIS tool and handed to the notebook, which is the workflow the example Jupyter notebook follows. The primary language of the repository is Jupyter Notebook, so the intended entry point is a notebook where you edit parameters and run cells.

Tidal correction is what makes satellite shorelines comparable

A satellite image is taken at a random moment in the tidal cycle, and the waterline moves with the tide, so an uncorrected shoreline record is mostly a record of when the images happened. The fourth capability is tidal correction of the shoreline time series and extraction of tidal levels at the time of image acquisition from a global tide model, FES2022. This is the most technically demanding part of the pipeline and the one the project has invested in most recently, with v3.0 in 2024/10/02 adding the integration of the FES2022 global tide model to perform tidal correction and beach slope estimation within CoastSat. The sixth capability, beach slope estimation using satellite-derived shorelines and predicted tides, is a direct consequence of the same machinery, since knowing the vertical offset of the waterline lets you infer the slope of the beach face. There is a real operational wrinkle in the latest release: v3.3, dated 2026/05/29, added a script to split the FES2022 tidal files into latitude bands and allow loading with limited RAM, with the script in the examples directory under tide_model_clipping. In other words, a global tide model is a large download and a memory problem, and the fix was to slice the model rather than to shrink it.

Despiking and seasonal averaging, and the wrong-tool case

The fifth capability is post-processing of the shoreline time series, despiking and seasonal averaging. Despiking removes the outliers that survive the quality control stage, and seasonal averaging turns a noisy monthly series into something that can carry a trend. This is where the tool becomes useful for a real study rather than a demonstration, and it is also where a user has to be careful about what they are smoothing. The published literature linked from the documentation includes a paper on challenges in meso-macrotidal environments, which is a fair warning that in a strongly tidal setting the correction step is doing heavy lifting. The clearest statement of when this is the wrong tool is the optimisation target itself. The algorithm is optimised for sandy beach coastlines, and the additional toolkit list shows the ecosystem that grew around that gap, with separate projects for reef islands, for PlanetScope imagery, for Maxar WorldView imagery and for vegetation line monitoring, plus a benchmark testbed for satellite derived shoreline mapping algorithms. The honest position is that CoastSat is one shoreline detection method in a family, and a site that is not a sandy beach needs either a different method or an extension of this one.

An environment first, a Google Earth Engine account second

Installation is described as a two part job, and the first part is an environment. The documentation asks you to install the required Python packages in an environment, which you can do with Anaconda or with Mamba, and it says it is highly recommended to use Mamba. The route given is to go to the conda-forge Miniforge page and download Miniforge for your operating system, then open the Miniforge Prompt. The environment first, dependencies second ordering is typical of a scientific Python project that depends on geospatial stacks with compiled libraries, and Mamba is recommended over conda for the same reason. The second part is Google Earth Engine, because the imagery retrieval step runs there, and the pre-processing steps described in the project description, re-projecting bands, pansharpening and cloud masking, all happen in the Earth Engine environment rather than on your machine. The website at coastsat.space exists to explore and download existing satellite derived shoreline datasets generated with CoastSat in the Pacific and Atlantic basins, so you can look at real output before committing to running the pipeline yourself. There is also a Zenodo DOI badge in the README, which is the citation path for the project, and the documentation points to publications describing the shoreline detection algorithm and its accuracy assessment.

Licence, versions and what the repository looks like

The project is GPL-3.0 licensed, and for a scientific toolkit published with a DOI and peer-reviewed methods papers, that licence is normal and worth understanding before you build on it. The code is distributed under the GNU General Public License version 3, and if you incorporate parts of it into a closed tool the copyleft terms reach your own work. The last push was on 2026-06-05, and the release history is sparse and meaningful: v3.3 from 2026-05-29 clipped the tide model to reduce RAM usage, v3.2 from 2025-01-06 was minor bugfixes, and v3.1 from 2024-10-08 added beach slope estimation. The gap between v3.2 and v3.3 is more than a year, which tells you the project moves in bursts tied to specific problems rather than on a schedule. The repository layout shows a Python package directory named coastsat, a classification directory for the image classification component, an examples directory with the Narrabeen-Collaroy validation outputs, an example script and an example Jupyter notebook, and a doc directory. The version 2.7 change is worth flagging for anyone with old workflows: it restored reverse compatibility for file downloads from before v2.6 and removed Collection 1, which is deprecated and now throws an error.

Editorial conclusion

CoastSat is a good fit for a coastal researcher or engineer who needs a multi-decade shoreline record at a site with no in-situ monitoring, and who is comfortable working inside Google Earth Engine and a conda environment. It is the wrong tool for a rocky or vegetated coast, since the detection algorithm is optimised for sandy beach shorelines, and it is the wrong tool if you need certified measurement-grade output, because a satellite derived position is not a survey. Before running it, read the project description rather than the example notebook, and note that the retrieval step depends on Google Earth Engine, so you need an account and cloud access to the imagery. The toolkit is GPL-3.0 licensed, the last push was on 2026-06-05, and the most recent release is v3.3 from 2026-05-29.

Frequently asked questions

Official sources

1. kvos/CoastSat on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases