Home

Welcome to the Pronto Raster wiki!

Roadmap

What should be the next steps in developing Pronto Raster?

1. Consolidating.

The current set of functions can already serve a wide range of purposes. Ranging from Cellular Automata modelling to implementing spatial statistical methods. However, the documentation and test suite still leave much uncovered. Most functions and concepts have been documented, but not the classes. We need to expand on this to create more confidence in the library.

2. Improving clarity about concepts

The documentation needs to be clearer about concepts, in describing whether rasters are Mutable, Unmutable or partially Mutable. Likewise, it is not clear which functions produce rasters that are RandomAccessible.

3. Measuring performance using benchmarks

We now have one simple benchmark comparing Blink Raster's performance against straight block-by-block cell-by-cell processing. We cannot expect to outperform this, but closely matching would be ideal.

4. Improving performance

One way to improve performance is to have specialized access to data in gdal_raster_view; we now have read-only and update. Having forward-only would help a lot (allows reference_proxy to use a reference instead of a copy of the associated iterator). Write-only is also an option. The performance of any_blind_raster could be performed if we allow it to hold either an any_raster or a gdal_raster_view, it would avoid type erasure for the common occurance of gdal_raster_view.

5. Make existing functions more versatile and consistent

The patch_raster_transform currently requires RandomAccessible rasters, which can be avoided. The padded_raster_view is not RandomAccessible even though it could be with some effort. But like gdal_raster_view there might be a cost, so it should be customisable. Review the use of the nodata_filter on functions. To really conform to the Range concepts, functions will need to be implemented using std::begin(range) rather than range.begin().

6. Expanding the Raster concept

Or adding adding more demanding Raster concepts, to allow transposing and horizontal and vertical flipping.

7. More functions

Mosaicking is top of my list. Perhaps it is easiest to separately implement putting rasters together horizontally and vertically. Padding with periodic (can be implemented in terms of mosaicking) or mirrored values (can be implemented with mosaicking if we have Raster concepts for horizontal and vertical flipping.

8. Parallel processing

In principle this should not be too complicated to implement, because the use of subrasters makes it straightforward to split and combine operations on rasters. However, not a big priority because for many uses the bottleneck is file access, which is not parallel on most systems.

9. Sparse rasters???

Another can of worms, but useful.