I am definitely for removing unused things that talk to servers or use
binary drivers.
I can see wanting to keep drivers that don't interact with servers for
posterity, but I think that cost is starting to get high. A system like
you describe with a good lead time sounds good.
In the Google setu
Hey guys, I was just typing pretty much the same thing.
So these drivers could be removed gracefully with a trace allowing
gis-archeologists/archivists to use them.
I can just see the papers in my imagination.
Jan
On Mon, Jan 11, 2021 at 1:03 AM Stephen Woodbridge <
stephenwoodbridg...@gmail.com>
Even,
This makes a lot of sense to me. How would you handle this in Python?
Would it make sense to create a GDAL-removed repository and move stuff
into it just so it is available if someone wants it. This would not be
supported or updated by GDAL just making it available if someone
wants/needs
Could you simply make them all plugins and announce that they will be
unmaintained? After a release cycle, we place such things into their own
repo. Don't know if that would work for GDAL.
On Sun, Jan 10, 2021, 6:02 PM Even Rouault
wrote:
> Hi,
>
> It's not spring yet, but I'm in a mood lately o
On Mon, 11 Jan 2021 at 09:50, Jan Heckman wrote:
>
> A bit of googling sometimes gives an indication. I was a little confused
> about SVG, not using it myself but getting quite a few references.
> E.g. this one in stackexchange, with a mention how often it was looked up:
> https://gis.stackexchan
A bit of googling sometimes gives an indication. I was a little confused
about SVG, not using it myself but getting quite a few references.
E.g. this one in stackexchange, with a mention how often it was looked up:
https://gis.stackexchange.com/questions/11476/importing-svg-into-gis
Just an idea. O
Hi,
It's not spring yet, but I'm in a mood lately of axing useless things, and we
probably have tons of candidate for that in GDAL, especially in drivers.
I was going to just axe the DB2 driver
(https://github.com/OSGeo/gdal/pull/3366) but the issue is more general.
Any idea how we can know what
Alex,
> I am using the /vsimem/ driver to create a virtual netCDF from a bytes
> string in Python3. The process works fine when run from my host system but
> when I package it up in a Docker container I'm getting errors when trying
> to open the in memory file. The error stems from a call to
> `g
