Why do you need transects to extract the shorelines?

[FlorisCalkoen]

ping #openjournals/joss-reviews#6683

While trying to map some shorelines for Terschelling in the Netherlands I had to upload transects. Why not seperate shoreline mapping from computing series of shoreline positions over a set of transects? IMHO you only need transects if time series of shoreline change, but strictly speaking for the SDS you don't need transects.

[2320sharon]

Hi Floris,

Great question, in the early versions of CoastSeg we did separate the steps of extracting the 2D shorelines from the imagery and computing the shoreline change along the transects. However, we decided to move away from this design for two reason. The first being that our targeted user base needs transects to explain shoreline change and while 2D shorelines are useful they are generally not accurate for accessing change at a single point. The second reason is that most of our beta users wanted to find the shoreline change along transects so having the button separated was confusing for them and made the process take longer.

[FlorisCalkoen]

Hi @2320sharon, thank you for your prompt response!

I see that most users are probably interested in satellite-derived shoreline series, but I'm also very interested in the shorelines, and probably there are others like me. I know that Mao et al 2021 actually computes shoreline change from shorelines without any transects --- so change analysis can also be performed at that level.

If you (still) decide to provide your users with one method I think it would be better to explictely call the method extract shoreline series or even extract shoreline series at transects. IMHO, I think it's a general misconception (in the coastal monitoring field) to refer to SDS time-series as SDS -; to me it should be SDS for the shorelines (linestring geometries) and SDS series for the transect series (point geometries or translated position wrt to a reference point on a transect).

Do you save the shoreline geometries while extracting the series? Sorry I didn't check the data output yet.

[2320sharon]

@FlorisCalkoen

Thanks for bringing up the Mao et al 2021 research paper. I can make an issue to allow CoastSeg to run without transects meaning it will output the 2D shorelines but none of the files related to shoreline change along the transects. This leaves this feature open to development.

We do save the shoreline geometries while extracting the series as both LineStrings [extracted_shorelines_lines.geojson], MultiPoints [extracted_shorelines_points.geojson] and as a dictionary [extracted_shorelines_dict.json] in the same format CoastSat does. One of the reasons we save them in these different formats is because we found from months of testing with our users that the multipoint format made it easier to see outliers (cloud detected as shorelines, ponds etc.). We also store the shorelines as LineStrings as well because it makes it easy to see the shoreline vector, but if clouds are detected as shoreline off shore this can results in strangely connected shorelines as seen CoastSat. The dictionary [extracted_shorelines_dict.json] contains all the data for the extracted shorelines in the same format CoastSat stored it except its no longer in a pickle format making it much more portable.

[dbuscombe-usgs]

In addition to the files you request already being available (i.e. the feature you request is already available), I will note that the Mao algorithm retrieves annual shoreline at high tide with image compositing methods, and is therefore not really a good analog for coastseg, which, as stated in numerous places, implements the CoastSat-style, transect-based, instantaneous shorelines mapped onto transects. The key advantage in the latter is data density, and high-frequency data are easily compared using a transect system. Transects can be as close together as you wish.

During extensive beta testing, our many users requested the 2d shorelines, so they are also outputted as standard, according to the graphic that Sharon shared above, as a convenience. But CoastSeg does not generally provide post-processing workflows - those tasks will be offloaded to another compatible toolbox to avoid software and dependency bloat.

We use the term SDS to mean Satellite Derived Shoreline, regardless of how it is computed. We also define this in the paper. This is the standard terminology adopted in the literature. We use waterline for uncorrected measurements, which is also standard - see this recent paper https://doi.org/10.1016/j.coastaleng.2024.104536

As for your terminology, namely SDS for the shorelines (linestring geometries) and SDS-series for the transect series, feel free to propose such a change in a research paper. This is just a software package adopting current standard terminology.

[fmemuir]

Just jumping on this thread (let me know if I should open a separate issue), to ask if available transects exist as a feature somewhere? It might be helpful to have locations with available transects (or even a super simple shoreline boundary) available to toggle on/off within the Leaflet map, so that beginner users can see where transects currently exist (without having to scroll around creating trial+error ROIs to look for locations with transects).

[2320sharon]

Hi @fmemuir

Good question, if a beginner use wants to see all the transects that are available in CoastSeg they either download the transects from the official zenodo release we have linked in the readme or they can load from the geojson files located in CoastSeg/src/coastseg/transects into a free open source mapping software such as QGIS.

The main reason we don't render the transects on the map is because rendering thousands of vectors on ipyleaflet is very resource intensive. We've explored rendering the regions where transects are available with basic shoreline vectors, but given the large spread of transects we have this option isn't much better because it still would consume a lot of memory. We explored the idea of showing all the transects we presently have available as a static web map in our documentation, but since we are planning to add more transects to CoastSeg in the near future and continuously we decided against it because it would require frequent updating. The transects that CoastSeg provides by default are not required for the program to work. We designed CoastSeg so that users can upload their own transects, shorelines, rois, and bounding boxes if they find that CoastSeg either doesn't have or generate the features they want. The default shorelines and transects available are a 'fallback' for the user.

We provide a guide for users for how they can generate and upload their own transects and shorelines as well available on the CoastSeg website

The current workflow to view the transects available only a takes a few seconds:

1. Draw a Bounding Box
2. Click 'load transects' Button
3. If none were available: Click 'Remove All' then repeat step 1 at a new location

This approach saves on a lot of memory since only a limited number of transects can be loaded at a given time. Unfortunately, rendering all the available transects on the map is non-trivial issue and would add significant overhead to the CoastSeg's performance. Additionally this simplistic design frees the team behind CoastSeg to work on improvements to the shoreline mapping functionality and more.

[dbuscombe-usgs]

I believe this issue has been addressed and can be closed. Is that ok, @fmemuir?