On 2015-04-08 10:05 AM, Even Rouault wrote:
Daniel,
No comment on the actual change which sounds fine to me.
However, could we add a "Version: ..." field to the header of RFCs to
make it easier to track down the version to which a RFC applies? I saw
that you indicate the version in the status
Daniel,
> No comment on the actual change which sounds fine to me.
>
> However, could we add a "Version: ..." field to the header of RFCs to
> make it easier to track down the version to which a RFC applies? I saw
> that you indicate the version in the status field after a RFC has been
> implemen
Hi Even,
No comment on the actual change which sounds fine to me.
However, could we add a "Version: ..." field to the header of RFCs to
make it easier to track down the version to which a RFC applies? I saw
that you indicate the version in the status field after a RFC has been
implemented, bu
> A similar problem exists with GDALRasterBand::GetRasterSampleOverview():
> it takes a 31-bit integer value for its 'nDesiredSamples' parameter. I've
> run into some 100,000×100,000-pixel images for which the first two levels
> of overviews would contain more than 2-billion samples.
Hi Craig,
On 2015-04-07 16:33, Even Rouault
wrote:
This RFC modifies the GDALRasterBand GetHistogram(), GetDefaultHistogram() and
SetDefaultHistogram() methods to accept arrays of 64-bit integer instead of
the current arrays of 32-bit integer for bucket counts. This will fi
Hi,
This is a call for discussion on "64-bit bucket counts for histograms" (last
one for today ;-) and hopefully a no-brainer)
https://trac.osgeo.org/gdal/wiki/rfc57_histogram_64bit_count
Summary :
This RFC modifies the GDALRasterBand GetHistogram(), GetDefaultHistogram() and
SetDefaultHistog
