> On Mar 27, 2019, at 5:56 AM, Jeff McKenna
> wrote:
>
> On 2019-03-26 8:58 AM, Even Rouault wrote:
>> The possible scenarios I see:
>> 1) status quo with Trac wiki
>> 2) migrate all or almost all content from Trac wiki to GitHub wiki, and kill
>> Trac wiki
>> 3) migrate part of Trac wiki to t
Hi,
I did not get an answer for my question bellow so I did some testing. I write
to help others that will find this post. (I am making a point to raster query
tool.) It’s much faster to load a cloud of point to a function and to loop a
query to each band than to load a single band to a funct
Actually there IS a problem: the downloaded raster is off by 50 meters!
I think, I have to report an issue on github.
—
Von einem iPhone gesendet und wird daher Fehler enthalten.
> Am 26.03.2019 um 21:50 schrieb Tobias Wendorff
> :
>
> Oh great... A second after this message got released on t
Hi,
I've recently corrected a number of issues raised by Coverity Scan (memory
leaks, etc.) in the GeoRaster driver in master. I can only compile-test it, so
there is some risk that regressions might pop up at runtime. Feedback from
folks who have a test setup would be appreciated.
Even
--
S
On 2019-03-26 8:58 AM, Even Rouault wrote:
The possible scenarios I see:
1) status quo with Trac wiki
2) migrate all or almost all content from Trac wiki to GitHub wiki, and kill
Trac wiki
3) migrate part of Trac wiki to the future official RST doc, abandon&kill
remaining non relevant info, and
with 2.4.1 the segfault comes from gvBurnPoint, so that may need similar
fix than gvBurnScanline
Ari
Even Rouault kirjoitti 26.3.2019 klo 20.39:
On mardi 26 mars 2019 17:50:19 CET Ari Jolma wrote:
We're seeing transient segfaults in gvBurnScanline with a huge in-memory
raster created by rast
