erikmannerfelt / glacier_lengths Goto Github PK

At one glacier, I had the issue that the cut buffered centerlines are so short relative to the original centerline that it automatically gets filtered away. Here's the problematic line:

The result is this:

The cut lines (red) west of the main centerline are filtered away because they are shorter than 80% of the original centerline. With a manually changed threshold of 0.4 instead of 0.2, it looks much better:

The filtering is still required as larger glaciers' buffered centerlines should never be 40% shorter than the main, but for small glaciers, it may very well be necessary.

The proposed change is to simply make it an optional argument.

In glacier_lengths.plotting.plot_centerlines, the glacier outline styling is erroneously controlled by centerline_kwargs, and vice versa outline_kwargs

In many cases, a glacier centerline may not end at rock (i.e. the edge of a polygon):

• On ice caps
• On ice sheets
• If a reliable glacier outline does not exist and the user only wants the length compared to the start of the centerline

An outline is currently required for buffering centerlines, but that is not the only way that one can trim the buffers correctly.

Instead of cutting the buffers with a glacier outline, a perpendicular cut-line to the centerline can be drawn instead. A good example using shapely is shown here:

https://stackoverflow.com/questions/57065080/draw-perpendicular-line-of-fixed-length-at-a-point-of-another-line

Then, the buffer_centerlines function should not require an outline; either making it optional or removing it altogether.

In some cases, a glacier terminus position may be split up in multiple parts. For example, this might be to avoid areas of snow cover that would mess with the outline delineation. Currently, providing a MultiLineString simply fails, so each part has to be evaluated separately. It would be simpler to just allow MultiLineStrings and include functionality for it.

Currently, if one or more (buffered) centerlines are not cut by the cutting geometry, a warning is triggered by default. This is nice, as the user is alerted of the problem, but this is not a fix per se. A better way is to add a flag (that could be on by default) that will remove all lines that do not intersect the cut geometry. I wrote some code that easily does this:

lines_cut = []
for i, centerline_buf in enumerate(centerlines_buffered.geoms):                                          
    if not centerline_buf.intersects(outline):                          
        continue                                                        
                                                                                        
    line_cut = glacier_lengths.cut_centerlines(centerline_buf, outline)
    lines_cut.append(line_cut)

It's basically just the intersection check that is an addition to the current functionality, but it opens a few doors:

• The returned lines will always be representative.
• A large buffer radius can be specified, and the cutting step automatically helps narrow down the lines to a sensible width.

To measure length differences, the mean length of one year can be subtracted to another. When measuring the spread, however, it is better to do an element-wise subtraction (each element being a buffered centerline's length) and deriving the spread of that. This requires some way of keeping track of the index of each centerline. As far as I'm aware, the order of LineStrings in the MultiLineString from buffer_centerlines() is kept when cutting, but this is not a guarantee unless there's a check for it, and #12 would mess with the order.

One potential solution would be to allow a dictionary as the centerlines in cut_centerlines(). For example:

>>> centerlines = {0: LineString(...), 1: LineString(...)}
>>> glacier_lengths.cut_centerlines(centerlines, cut_geometry)
{1: LineString(...)}

Here, I assume that #12 is implemented, and that centerline "0" was deemed invalid in some way, such as that it didn't intersect the cut-geometry.

If a glacier outline only cuts a few centerlines, it will register a length that is too high. A warning should be issued in that case.

This may happen if for example a glacier outline is very short, and doesn't cover the buffer around the centerline.

In shapely 1.8, some terminology was introduced and old terminology was deprecated, and will stop working completely in shapely 2.0. More specifically, multi-part geometries should now be iterated over with the .geoms property.

The result of the deprecation is now that lots of warnings show up, mostly originating from the glacier_lengths.core.iter_geom() convenience function. The solution is probably just fixing that function to use the new terminology, and adding a test to show that no warnings are present.