+1
On Tue, Jun 8, 2021 at 4:50 AM Even Rouault
wrote:
> Hi,
>
> Motion:
>
> adopt RFC 83: guidelines for the use of GDAL project sponsorship (
> https://github.com/OSGeo/gdal/pull/3855 )
>
> Starting with my +1
>
> Even
>
--
Sean Gillies
___
+1 KurtS
On Tue, Jun 8, 2021 at 9:19 AM Frank Warmerdam wrote:
> +1 FrankW
>
> I do think we need to give ourselves (the PSC) some latitude on how
> proposals are solicited and evaluated.
>
> I am quite pleased with the characterization of the maintenance tasks.
>
> Best regards,
>
>
> On Tue,
+1 FrankW
On Tue, Jun 8, 2021 at 5:59 PM Kurt Schwehr wrote:
> +1 KurtS
>
> On Tue, Jun 8, 2021 at 1:10 PM Even Rouault
> wrote:
>
>> PSC,
>>
>> We've had a request from NumFOCUS to align the titles of the GDAL
>> sponsorship tiers with the ones of NumFOCUS, to limit the risk of
>> confusion,
+1 KurtS
On Tue, Jun 8, 2021 at 1:10 PM Even Rouault
wrote:
> PSC,
>
> We've had a request from NumFOCUS to align the titles of the GDAL
> sponsorship tiers with the ones of NumFOCUS, to limit the risk of
> confusion, which was one topic discussed during last meeting.
>
> For reference, the
PSC,
We've had a request from NumFOCUS to align the titles of the GDAL
sponsorship tiers with the ones of NumFOCUS, to limit the risk of
confusion, which was one topic discussed during last meeting.
For reference, the ones of NumFOCUS are at
https://numfocus.org/sponsors/become-a-sponsor,
Yes, it must be internal
Le mar. 8 juin 2021 à 21:21, a écrit :
> Thanks Thomas.
>
>
>
> Does cogger need a mask band to be internal as well, and not a sidecar
> file?
>
>
>
> -Mat
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Thanks Thomas.
Does cogger need a mask band to be internal as well, and not a sidecar file?
-Mat
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Matt,
In the general case, cogger supports a tiff with internal overviews, i.e.
without a .tif.ovr sidecar file. The advanced usecase which takes multiple
files is a remnant of the time when gdaladdo was much slower than
successive runs of "gdal_translate -outsize 50% 50%", or for when you need
Hi,
`import gdal` was deprecated. It got removed in 3.3.
Please use `from osgeo import gdal`
Idan.
On Tue, 8 Jun 2021, 21:11 Bill Eggers, wrote:
> Somewhere between installing BlenderGIS, OSGEO4W testing version, and
> ArcGISPro, the QGIS plugins that relied on GDAL quit working. I’ve tried
>
I forgot to add: I tried adding the .ovr file in a manner similar to the Cogger
readme example but got an error:
~~~
$ cogger -output test.tif SPOT6_321_BeaverRiver_08Sep2018_NAD83_YAlbers.tif
SPOT6_321_BeaverRiver_08Sep2018_NAD83_YAlbers.tif.ovr
mucog write: load: cannot load multiple tifs if
Hi,
I took cogger for a first test drive and I'm confused. I'm relatively new to
the world of Cloud Optimized Geotiffs, so I don't know if my confusion is about
the COG format itself or cogger:
I fed a jpeg-in-geotiff file with external overviews (tif.ovr) and mask
(tif.msk) to cogger. The
Somewhere between installing BlenderGIS, OSGEO4W testing version, and
ArcGISPro, the QGIS plugins that relied on GDAL quit working. I’ve tried
uninstalling and re-installing OSGEO4W and the standalone QGIS 3.18..3-2
and a few other tips like specifying the Python path, but nothing worked. I
+1 FrankW
I do think we need to give ourselves (the PSC) some latitude on how
proposals are solicited and evaluated.
I am quite pleased with the characterization of the maintenance tasks.
Best regards,
On Tue, Jun 8, 2021 at 9:37 AM Howard Butler wrote:
> +1 Howard
>
> > On Jun 8, 2021, at
Thanks Even
Doing that (multiband with minisblack and alpha), and interleave=band, when
computing overviews there is a problem. I opened an issue that explains it.
https://github.com/OSGeo/gdal/issues/3939
I tried a solution, but I think it is not the proper one.
Cheers.
Javier
.___ ._ ..._ .. .
That sounds reasonable.
.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.
On Tue, 8 Jun 2021 at 10:59, thomas bonfort
wrote:
> There is no c++ version, although there are no specific go constructs
> that
+1 Howard
> On Jun 8, 2021, at 7:31 AM, Mateusz Loskot wrote:
>
> +1 Mateusz
>
> On Tue, 8 Jun 2021 at 12:50, Even Rouault wrote:
>>
>> Hi,
>>
>> Motion:
>>
>> adopt RFC 83: guidelines for the use of GDAL project sponsorship (
>> https://github.com/OSGeo/gdal/pull/3855 )
>>
>> Starting
+1 Mateusz
On Tue, 8 Jun 2021 at 12:50, Even Rouault wrote:
>
> Hi,
>
> Motion:
>
> adopt RFC 83: guidelines for the use of GDAL project sponsorship (
> https://github.com/OSGeo/gdal/pull/3855 )
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my
Hi,
Motion:
adopt RFC 83: guidelines for the use of GDAL project sponsorship (
https://github.com/OSGeo/gdal/pull/3855 )
Starting with my +1
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing
There is no c++ version, although there are no specific go constructs
that would prevent a port to c++ if you really wanted to.
It could also be possible to export a C function from the go code,
exposed as a shared library, that would only work on local files
and who's signature would be something
Thanks Thomas!
I see this is in Go. Is there a C++ version of it? Or how easy is to use it
from C++ code?
Thanks.
.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.
On Fri, 4 Jun 2021 at 18:48, Even Rouault
20 matches
Mail list logo
