Re: [gdal-dev] Introducing the cogger and godal projects

[Sean Gillies via gdal-dev]

Hi Thomas,

Congratulations! These look like great projects.

On Fri, Jun 4, 2021 at 4:07 AM thomas bonfort 
wrote:

> Hello gdal,
>
> We're releasing two projects on github under an Apache-2.0 licence
> which may be of interest to the GDAL community.
>
> The first one, https://github.com/airbusgeo/cogger is a lightweight
> geotiff to COG converter that reshuffles the bytes of a tiled geotiff
> to make it cloud compatible. Whereas it does not replace the standard
> gdal tools for initially creating a geotiff, it is much faster than
> the last "-co COPY_SRC_OVERVIEWS=YES" classical gdal_translate method
> for outputting a cog, and also allows more flexibility when varying
> compression methods or tile sizes need to applied on overviews. Cogger
> can be used as a standalone command line tool, or as a go library
> function for interacting with remote storage without the need for
> local files.
>
> The second one, https://github.com/airbusgeo/godal is a golang wrapper
> for GDAL's raster api. While there is an already established golang
> wrapper for gdal that exists (https://github.com/lukeroth/gdal), godal
> differs by offering:
> - robust error handling and reporting
> - a stable compatible api promise (to the extent of what is possible
> to achieve given gdal's own api)
> - a vsi abstraction that hands off i/o to native golang code
> - a more user-friendly API that is not an exact mirror of the gdal
> api, making lesser used functionality optional. (For example, instead
> of the GDALOpen, GDALOpenEx and GDALOpenShared methods, godal exposes
> a single Open() method with optional arguments validated at compile
> time to pass in open options, shared mode, sibling files, etc...)
> Although the raster handling side of godal is mostly feature complete
> with gdal, the vector and spatial-referencing part is not.
>
> Outside contributions to both these projects are welcome through github.
>
> Best regards,
> Thomas
>

I'm very interested in "a vsi abstraction that hands off i/o to native
golang code".

-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Renaming of GDAL Advisory Board

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> We just had a meeting with NumFOCUS staff, and they suggested we should 
> rename the GDAL Advisory Board to something else. The issue is with the 
> Board term which is a legal term and may implicate that it is a deciding 
> body, which it is not. They suggested Council, Committee, as potential 
> alternatives. As committee is already used for the PSC, I think "GDAL 
> Advisory Council" could be a good fit.
> 
> If there's no opposition to this, I'll change all references to it on 
> the GDAL website (RFC 80, sponsorship prospectus), and ask for the 
> related mailing list to be renamed/recreated.
> 
> Other news: the Fiscal Sponsorship Agreement document, which will make 
> us officialy a NumFOCUS sponsored project, is now in the signing loop.
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Renaming of GDAL Advisory Board

[Kurt Schwehr]

+1 KurtS

On Fri, Jun 4, 2021 at 9:46 AM Frank Warmerdam  wrote:

> +1 Frank
>
> On Fri, Jun 4, 2021 at 12:36 PM Daniel Morissette <
> dmorisse...@mapgears.com> wrote:
>
>> +1
>>
>> Daniel
>>
>>
>> On 2021-06-04 12:24, Even Rouault wrote:
>> > Hi,
>> >
>> > We just had a meeting with NumFOCUS staff, and they suggested we should
>> > rename the GDAL Advisory Board to something else. The issue is with the
>> > Board term which is a legal term and may implicate that it is a
>> deciding
>> > body, which it is not. They suggested Council, Committee, as potential
>> > alternatives. As committee is already used for the PSC, I think "GDAL
>> > Advisory Council" could be a good fit.
>> >
>> > If there's no opposition to this, I'll change all references to it on
>> > the GDAL website (RFC 80, sponsorship prospectus), and ask for the
>> > related mailing list to be renamed/recreated.
>> >
>> > Other news: the Fiscal Sponsorship Agreement document, which will make
>> > us officialy a NumFOCUS sponsored project, is now in the signing loop.
>> >
>> > Even
>> >
>>
>>
>> --
>> Daniel Morissette
>> Mapgears Inc
>> T: +1 418-696-5056 #201
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | +1 650-701-7823
> and watch the world go round - Rush| Geospatial Software Developer
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Renaming of GDAL Advisory Board

[Frank Warmerdam]

+1 Frank

On Fri, Jun 4, 2021 at 12:36 PM Daniel Morissette 
wrote:

> +1
>
> Daniel
>
>
> On 2021-06-04 12:24, Even Rouault wrote:
> > Hi,
> >
> > We just had a meeting with NumFOCUS staff, and they suggested we should
> > rename the GDAL Advisory Board to something else. The issue is with the
> > Board term which is a legal term and may implicate that it is a deciding
> > body, which it is not. They suggested Council, Committee, as potential
> > alternatives. As committee is already used for the PSC, I think "GDAL
> > Advisory Council" could be a good fit.
> >
> > If there's no opposition to this, I'll change all references to it on
> > the GDAL website (RFC 80, sponsorship prospectus), and ask for the
> > related mailing list to be renamed/recreated.
> >
> > Other news: the Fiscal Sponsorship Agreement document, which will make
> > us officialy a NumFOCUS sponsored project, is now in the signing loop.
> >
> > Even
> >
>
>
> --
> Daniel Morissette
> Mapgears Inc
> T: +1 418-696-5056 #201
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Renaming of GDAL Advisory Board

[Daniel Morissette]

+1

Daniel


On 2021-06-04 12:24, Even Rouault wrote:

Hi,

We just had a meeting with NumFOCUS staff, and they suggested we should 
rename the GDAL Advisory Board to something else. The issue is with the 
Board term which is a legal term and may implicate that it is a deciding 
body, which it is not. They suggested Council, Committee, as potential 
alternatives. As committee is already used for the PSC, I think "GDAL 
Advisory Council" could be a good fit.


If there's no opposition to this, I'll change all references to it on 
the GDAL website (RFC 80, sponsorship prospectus), and ask for the 
related mailing list to be renamed/recreated.


Other news: the Fiscal Sponsorship Agreement document, which will make 
us officialy a NumFOCUS sponsored project, is now in the signing loop.


Even




--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Introducing the cogger and godal projects

[Even Rouault]

I haven't benchmarked cogger but I'd expect it to be much faster than 
gdal_translate -of COG (if your input is GeoTIFF and always properly 
tiled and compressed of course!). gdal_translate -of COG uses generic 
GDAL API to acquire input data, which implies decompression / 
recompression. And in particular, if using input GeoTIFF with lossy 
compressed methods such as JPEG or WebP, cogger will avoid adding any 
new loss.


Le 04/06/2021 à 18:28, thomas bonfort a écrit :
I haven't extensively used -of COG (the cogger code actually predates 
the cog driver) but iirc there are at least some cases where it uses 
an intermediate file, which would imply that cogger does offer some 
speedups. I'll let Even confirm...

Regards,
Thomas

Le ven. 4 juin 2021 à 18:14, > a écrit :


Is cogger specifically for the scenario where your converting a
large imagery library that already exists, but isn't cloud
optimized? i.e. Does it offer any advantages over the one step
`gdal_translate -of cog ...` when starting fresh?

Cheers,

Matt
Geomatics Analyst | Environment | T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Introducing the cogger and godal projects

[thomas bonfort]

I haven't extensively used -of COG (the cogger code actually predates the
cog driver) but iirc there are at least some cases where it uses an
intermediate file, which would imply that cogger does offer some speedups.
I'll let Even confirm...
Regards,
Thomas

Le ven. 4 juin 2021 à 18:14,  a écrit :

> Is cogger specifically for the scenario where your converting a large
> imagery library that already exists, but isn't cloud optimized? i.e. Does
> it offer any advantages over the one step `gdal_translate -of cog ...` when
> starting fresh?
>
> Cheers,
>
> Matt
> Geomatics Analyst | Environment | T 867-667-8133 | Yukon.ca
> Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Renaming of GDAL Advisory Board

[Even Rouault]

Hi,

We just had a meeting with NumFOCUS staff, and they suggested we should 
rename the GDAL Advisory Board to something else. The issue is with the 
Board term which is a legal term and may implicate that it is a deciding 
body, which it is not. They suggested Council, Committee, as potential 
alternatives. As committee is already used for the PSC, I think "GDAL 
Advisory Council" could be a good fit.


If there's no opposition to this, I'll change all references to it on 
the GDAL website (RFC 80, sponsorship prospectus), and ask for the 
related mailing list to be renamed/recreated.


Other news: the Fiscal Sponsorship Agreement document, which will make 
us officialy a NumFOCUS sponsored project, is now in the signing loop.


Even

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Introducing the cogger and godal projects

[Matt.Wilkie]

Is cogger specifically for the scenario where your converting a large imagery 
library that already exists, but isn't cloud optimized? i.e. Does it offer any 
advantages over the one step `gdal_translate -of cog ...` when starting fresh?

Cheers,

Matt
Geomatics Analyst | Environment | T 867-667-8133 | Yukon.ca
Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Introducing the cogger and godal projects

[Even Rouault]

Hi Thomas,

cogger is really cool, and certainly a useful complement to the GDAL COG 
driver (we could probably do something similar in it directly, if the 
input file is a TIFF, but that doesn't fit in a very natural way in the 
GDAL machinery). Feel free to submit a PR to the COG driver doc pointing 
to cogger.


Same against https://gdal.org/api/index.html#gdal-ogr-in-other-languages 
regarding your golang wrapper.


Even

Le 04/06/2021 à 12:07, thomas bonfort a écrit :

Hello gdal,

We're releasing two projects on github under an Apache-2.0 licence
which may be of interest to the GDAL community.

The first one, https://github.com/airbusgeo/cogger is a lightweight
geotiff to COG converter that reshuffles the bytes of a tiled geotiff
to make it cloud compatible. Whereas it does not replace the standard
gdal tools for initially creating a geotiff, it is much faster than
the last "-co COPY_SRC_OVERVIEWS=YES" classical gdal_translate method
for outputting a cog, and also allows more flexibility when varying
compression methods or tile sizes need to applied on overviews. Cogger
can be used as a standalone command line tool, or as a go library
function for interacting with remote storage without the need for
local files.

The second one, https://github.com/airbusgeo/godal is a golang wrapper
for GDAL's raster api. While there is an already established golang
wrapper for gdal that exists (https://github.com/lukeroth/gdal), godal
differs by offering:
- robust error handling and reporting
- a stable compatible api promise (to the extent of what is possible
to achieve given gdal's own api)
- a vsi abstraction that hands off i/o to native golang code
- a more user-friendly API that is not an exact mirror of the gdal
api, making lesser used functionality optional. (For example, instead
of the GDALOpen, GDALOpenEx and GDALOpenShared methods, godal exposes
a single Open() method with optional arguments validated at compile
time to pass in open options, shared mode, sibling files, etc...)
Although the raster handling side of godal is mostly feature complete
with gdal, the vector and spatial-referencing part is not.

Outside contributions to both these projects are welcome through github.

Best regards,
Thomas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Introducing the cogger and godal projects

[thomas bonfort]

Hello gdal,

We're releasing two projects on github under an Apache-2.0 licence
which may be of interest to the GDAL community.

The first one, https://github.com/airbusgeo/cogger is a lightweight
geotiff to COG converter that reshuffles the bytes of a tiled geotiff
to make it cloud compatible. Whereas it does not replace the standard
gdal tools for initially creating a geotiff, it is much faster than
the last "-co COPY_SRC_OVERVIEWS=YES" classical gdal_translate method
for outputting a cog, and also allows more flexibility when varying
compression methods or tile sizes need to applied on overviews. Cogger
can be used as a standalone command line tool, or as a go library
function for interacting with remote storage without the need for
local files.

The second one, https://github.com/airbusgeo/godal is a golang wrapper
for GDAL's raster api. While there is an already established golang
wrapper for gdal that exists (https://github.com/lukeroth/gdal), godal
differs by offering:
- robust error handling and reporting
- a stable compatible api promise (to the extent of what is possible
to achieve given gdal's own api)
- a vsi abstraction that hands off i/o to native golang code
- a more user-friendly API that is not an exact mirror of the gdal
api, making lesser used functionality optional. (For example, instead
of the GDALOpen, GDALOpenEx and GDALOpenShared methods, godal exposes
a single Open() method with optional arguments validated at compile
time to pass in open options, shared mode, sibling files, etc...)
Although the raster handling side of godal is mostly feature complete
with gdal, the vector and spatial-referencing part is not.

Outside contributions to both these projects are welcome through github.

Best regards,
Thomas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev