Support for LineStrings

[jdalrym2]

What sort of work would need to be done to support LineString geometry types? Theoretically this should be possible: instead of area overlap of a cell, you'd instead by looking at the length of the line in the cell and computing stats based on that.

Currently to work with LineString geometries I run a tiny buffer operation to get Polygon geometries as input, but ideally I'd skip this step and be able to use LineString geometries directly.

Thanks!

Jon

[dbaston]

Are you looking for standard stats (min, max, mean, etc) of raster values, weighted by the line length associated with each cell?

It looks like I worked on this about 2 years ago: https://gitlab.com/isciences/exactextract/-/commit/d0193235c79b1719861311478add5b0c794fbd3d

Would need to revisit and see what, if anything, is needed to put it over the finish line.

Related: https://github.com/isciences/exactextractr/issues/84

[jdalrym2]

Yes, that's correct. In my use case I'm mainly interested in mean atm ($C_i$ -> value of cell $i$, $Li$ -> line length in cell $i$): $$\frac{1}{L{tot}} \left( C_1L_1 + C_2L_2 + \cdots + C_nL_n \right)$$ or a weighted sum (same thing as the mean but don't divide by line length, i.e. a line integral).

Looking at the table in the README a lot of stats could be useful (min, max, minority, majority, variety, stddev), but those are little more down the road for me.

Also happy to help out, but would likely need some guidance on implementation.

[dbaston]

If you'd like, you could do some testing on this branch: https://gitlab.com/isciences/exactextract/-/tree/linestring-overlap-length-2 which has LineString support rebased onto the current master branch.

[dbaston]

Completed in d3974b09f507ef9a9bead870e15bb5ce163c5e51