Hello all
The question of maintaining the old drivers raises a whole bunch of
questions: how to finance the technical debt, how to involve more
developers in this project, how to promote it, ... GDAL is an OSGeo
project. Shouldn't these questions be addressed by OSGeo which should help
in the dist
Thank you Howard, Daniel, Jukka, and others.
When I google for qgis I get its page and six sub pages in the way
Google does it. One of those is "Donations". When I do the same for
GDAL, there's no such page. I guess the first and practical thing to do
would be to make regular donations possibl
David Strip writes:
> License monkey business isn't viable in any way with
> GDAL. It would just create confusion and erode trust, which we
> can't get back if broken.
Strongly agreed.
> gdal wouldn't be the first project to change it's license, though I
> really
Paul Harwood writes:
> I don't know the solution. The usual solution is an existing large,
> US-based foundation that has existing dealings with the FAANGS that could
> act as a conduit (perfectly legally).
I'd like to thank Howard for speaking so clearly.
One of the really broken things is th
On 1/13/2021 3:58 PM, Howard Butler
wrote:
License monkey business isn't viable in any way with
GDAL. It would just create confusion and erode trust, which we
can't get back if broken.
gdal wouldn't be the first project to change it'
How does linux development get funded?
Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d
From: gdal-dev on behalf of Paul Harwood
Date: Wednesday, January 13, 2021 at 4:47 PM
To: Carl Godkin
Cc: "gdal-dev@list
+1 and more to Carl and Howard
That said, having been inside a FAANG I can understand that the contortions
that you have to go through just to get a "charity" payment approved in
terms of proving probity especially post SOX are enormous. I tried to get a
G-normous company to provide network suppor
Hi Howard and all,
On Wed, Jan 13, 2021 at 3:58 PM Howard Butler wrote:
>
>
> On Jan 13, 2021, at 4:28 PM, Nyall Dawson wrote:
>
> On Thu, 14 Jan 2021 at 06:24, David Strip wrote:
>
> What is the path forward? One path Howard suggests is establishing a
> foundation similar to that behind Qgis
Hi everyone,
Regarding funding, I thought the barn raising that Howard mentioned from a
few years ago was a good thing. My little company made a donation and I
think we'd do it again were another "barn" proposed. Tools like GDAL &
PROJ and related projects are worth supporting and periodic donat
> On Jan 13, 2021, at 4:28 PM, Nyall Dawson wrote:
>
> On Thu, 14 Jan 2021 at 06:24, David Strip wrote:
>> What is the path forward? One path Howard suggests is establishing a
>> foundation similar to that behind Qgis. Another alternative, probably far
>> more controversial, is a license ch
On Thu, 14 Jan 2021 at 06:24, David Strip wrote:
> What is the path forward? One path Howard suggests is establishing a
> foundation similar to that behind Qgis. Another alternative, probably far
> more controversial, is a license change.
I'm pretty clueless regarding licenses -- but this is a
Need help to get support OPENJPEG 2.1.1 in GDAL 3.1.4 on CentOS 7.
Here are my configurations:
openjpeg-configure:
cmake -DBUILD_THIRDPARTY:BOOL=ON \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX:PATH=$(prefix)/deps \
-DBUILD_SHARED_LIBS:bool=off)
gdal4-configure
On Thu, 14 Jan 2021 at 07:26, Javier Jimenez Shaw wrote:
> - How to finance the development of GDAL? Well, do not forget that Even is
> also working a lot in PROJ, a library by the way used by GDAL... (should GDAL
> contribute to PROJ, as QGIS should contribute to GDAL and PROJ?)
For reference
Kudos++
Even's question about deprecating drivers triggered several discussions:
- Should we deprecate unused drivers? or how to find out that many drivers
are really not used? I liked the idea of reducing the weight in gdal with
unused code. Breaking the execution is the only way that most of the
I mostly wanted to say that I'm here listening to the discussion and
thinking about all these issues.
On the technical side, I tried to publicly think about long term
maintainability / reliability of GDAL over the years. It's always a moving
target, but here are a few of my old thoughts:
https:/
Hi,
An image of my multiline can be seen in this post
(https://gis.stackexchange.com/questions/384213/ogr-buildpolygonfromedges-fails-on-my-multiline).
I am trying to extract the largest polygon contained by the lines. As you can
see in the figure, one of the linestrings has only 2 points. One
Kudos to Howard for his succinct summary of the situation and the
call to action. While I have nowhere near his experience with open
source, my experience with other volunteer organizations reveals a
similar pattern. One person, or maybe a small number of people,
carry t
Thank you Howard for a great analysis and for pointing out the key problems.
Personally I think the top two problems are:
1- Bus number: we need to find a way to increase the number of active
maintainers to ensure the viability and velocity of the project
2- Sustainable revenue stream for mai
> Is there something fundamentally wrong with the current GDAL?
The project's history is one person doing most of the work. This person
eventually burns out.
Here's a table of the top five lifetime commits to the repository as of
December 2020.
Even Rouault – 19,838
Frank Warmerdam – 11,503
Hi,
The thread "Considering drivers removal ?" made me think about what is the real
issue. Is there something fundamentally wrong with the current GDAL? If having
>100 and >100 drivers prevent developers from doing modernization in GDAL
internals I do not believe that having 90 and 90 really ma
Our TAP7 application (www.softwright.com) has been using GDAL since we rewrote
it in C# from VB 6. I just grabbed the binaries from Tamas's build site
(https://www.gisinternals.com/release.php).
Most of my CPU cycles are involved in reading millions of samples from raster
data files.
I have tr
21 matches
Mail list logo