Great discussion about improving the raster processing. As opposed to the
ideas above, of incorporating new machinery into GDAL, it might also
interesting to consider changing the API (a bit) so GDAL integrates better
with existing tools.
Within the Python ecosystem for example, there have
Hi Ari,
I began some work to clarify my ideas here: www.github.com/JamesRamm/GeoAlg
perhaps there is potential for merging with your project? For
neighbourhoods I provide 2 iterators - one simple block based and one
'buffered'. The block can be the natural block or user defined. I also
planned to
Hi,
Sorry for missing this last month due to holidays.
In fact in my approach I do not want to limit to single pixel operations
but support neighborhood operations too. That is necessary for watershed
analysis for example. Making sure that the neighborhood is readily
available for
I can see where some similarities with other new and existing GDAL work could
be a blocker on this, but I also think this adds a a degree more flexibility
allowing potentially any kind of complex processing to be carried out
without worrying/bothering about boilerplate.
It would be good to find
Peter,
I think 'Grid Algebra' would be what Ari Jolma is proposing here:
https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra
As Even pointed out, there is some overlap, though my proposal is
technically very different.
The key differences I see are:
- Users can submit functions which operate
Le mardi 12 juillet 2016 16:39:34, James Ramm a écrit :
> Hi Even,
>
> The difference I see with pixel functions is that, as far as I understand,
> the pixel function is applied per pixel, so there is no possibility of e.g.
> the pixel buffer when have the function apply to 'blocks'.
> I may be
James,
in reality, are you not requesting an implementation of Tomlin's
'Grid Algebra' in GDAL? That defines the whole range of functions from
whole raster to pixel and has the distinct advantage of being both
published and extremely well known because of other implementations ...
which
Hi Even,
The difference I see with pixel functions is that, as far as I understand,
the pixel function is applied per pixel, so there is no possibility of e.g.
the pixel buffer when have the function apply to 'blocks'.
I may be way off, but many of the algorithms we deal with require some kind
of
James,
There's some intersection with Ari's proposal :
https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra . At least regarding the
overall purposes, since technically this is quite different.
Actually what you propose is very close to the existing VRT pixel functions of
derived bands. See
