Re: [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

[Markus Neteler]

Hi Even,

(back to your wish)

On Thu, Nov 18, 2021 at 7:12 PM Even Rouault  wrote:
>
> Hi,
>
> (writing to both GDAL and GRASS lists)
>
> Working on the transition to CMake as the GDAL build system, the
> particular status of the GRASS driver in GDAL raised my attention.
>
> (The following is based on my understanding. It has been ages since I
> didn't try this...)
>
> This driver is a bit odd in the sense that there's a cyclic dependency
> to work around, as GRASS links to GDAL , but the GDAL GRASS driver needs
> to be linked against GRASS.
>
> So the usual procedure is:
>
> - build GDAL without the GRASS driver
>
> - build GRASS against GDAL
>
> - build the GDAL GRASS driver from the separate gdal-grass tarball that
> GDAL distributes along its main tarball.
>
> With the current GDAL autoconf build system, there's also the
> possibility to rebuild GDAL with the GRASS driver builtin in libgdal,
> but that's a bit odd, since you need to make sure that this new libgdal
> is the one that GRASS will link against at runtime, otherwise chaos will
> ensure. I'm not sure if that's used. This is typically something I would
> *not* want to support in the new GDAL cmake build.
>
> All in all, given the particular nature of that driver, I believe it
> would be better in a dedicated repository, with its standalone build
> scripts, whose initial version could be just the ones of
> https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg, or evolve to
> CMake or whatever the maintainers of that driver would prefer. I believe
> this would make the situation clearer.
>
> Opinions ? and people interested in setting up that dedicated repository ?

Yes and finally done that:

https://github.com/OSGeo/gdal-grass

Hope I got it right (history is preserved, I used

git filter-repo --path ogr/ogrsf_frmts/grass --path frmts/grass

and then moved the remaining needed files into the toplevel directory.
Hope I got it right.

Markus

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Standardize gdal-utils scripts return code for "no arguments"

[Robert Coup]

Hi Matt,

On Wed, 27 Apr 2022 at 18:27,  wrote:

>
>
> Since return 2 is the default for argparse then it seems to we should do
> the same for all the python utils?
>

In my experience 2 is a common exit code when missing/invalid arguments are
passed to a process in the unix-ey world, but it's not standardised or
universal.

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

[gdal-dev] Why gdal2tiles creates png.aux.xml files

[Rahkonen Jukka (MML)]

Hi,

I noticed this question in gis.stacexchange 
https://gis.stackexchange.com/questions/429896/how-to-not-generate-png-aux-xml-files-when-using-gdal2tiles.
 The current gdal2tiles.py really seems to write the aux.xml files except for 
the base tiles. I wonder if it is necessary and if there is another way to 
prevent it than setting GDAL_PAM_ENABLED=NO as suggested in the answer.

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