Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Andrew C Aitchison
On Mon, 11 Jan 2021, Even Rouault wrote: 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 g

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Even Rouault
Hi, trying to answer the different points raised up to now: - SVG: let's keep it as it is used. This is exactly the feedback I'm seeking for. I had developed this as a toy, crazy me, I won't do it anymore. No idea anyone was using it actually. - making those driver plugins. This would require

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Greg Troxel
Even Rouault writes: > - Where are the costs in keeping these drivers ? >* monetary: there is one, but I'm unable to quantify it >* environmental: burn CPU cycles each time someone does a GDAL build >* psychological: prevent developers from doing modernization in GDAL > internals. W

[gdal-dev] gdal_cachemax configuration

2021-01-11 Thread Stephane Poissant
Good day to all, I am fairly new to goal / mapserver and I have to upgrade the servers to latest Linux available on Amazon. (CentOS 2 kinda) I managed to get mapserver compiled and going properly. I’d like to configure the goal_cachemax to 512 but I cannot find Where and how to apply this system

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread David Strip
Bearing in mind that I use none of the drivers on Even's list, I find his suggestion and reasoning compelling. I especially agree with his comment that the only way to get anyone's attention is to break their workflow, if only temporarily. The main risk here is that a pro

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Greg Troxel
Sorry, I didn't read the first message in it entirety before digging in to the thread. Reading over the proposed list of removals, nothing jumps out at me as problematic. signature.asc Description: PGP signature ___ gdal-dev mailing list gdal-dev@li

[gdal-dev] Unable to install GDAL on macOS with pip

2021-01-11 Thread Marius Kreß via gdal-dev
Dear GDAL developers and users, I am unable to install GDAL on my Mac. I have set up Python with pyenv. When I enter pip install gdal I get a lot of exceptions that always end with FileNotFoundError: [Errno 2] No such file or directory: '../../apps/gdal-config‘ or FileNotFoundError: [Errno 2]

Re: [gdal-dev] Unable to install GDAL on macOS with pip

2021-01-11 Thread Chris Marsh
Hi, You need to have the gdal binaries installed before pip install gdal will work. Specifically, pip install gdal installs the python bindings for gdal. In my opinion on mac, the easiest way is to install gdal via homebrew. Then the configuration utility gdal-info should be on the path and pip in

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread jratike80
Hi, The joy of being a Windows user is that it is so easy to use old GDAL versions if the binaries still happen to be on some dusty backup disk. Even the FWTools including GDAL 1.7.0 from 2010 seemed to work fine and include quite a many later removed drivers. A few comments about the driver list

Re: [gdal-dev] Unable to install GDAL on macOS with pip

2021-01-11 Thread Marius Kreß via gdal-dev
Thank you, this worked! Maybe this should be mentioned on the Download page? I think it is a bit incomplete in general: Nothing on macOS and the Windows section just mentions Conda and no alternatives (like gisinternals.com and OSGeo4W). Maybe it could be expanded? Marius > Am 11.01.2021 um 19

Re: [gdal-dev] Unable to install GDAL on macOS with pip

2021-01-11 Thread Chris Marsh
Glad to hear it. I'm not sure what Even et al's stance on using homebrew as an official recommendation is. I am just a user who has gone down this route myself On Mon, Jan 11, 2021 at 1:37 PM Marius Kreß wrote: > CAUTION: External to USask. Verify sender and use caution with links and > attachme

[gdal-dev] Gdalwarp fails with Stereographic_North_Pole

2021-01-11 Thread Rahkonen Jukka (MML)
Hi, Have a look at this question https://gis.stackexchange.com/questions/383825/difference-between-qgis-export-and-gdalwarp? The original poster managed to get good output with gdalwarp by warping first into EPSG:9040 and then into EPSG:4326 but that feels like a workaround and not a solution.

Re: [gdal-dev] [Non-DoD Source] Re: Considering drivers removal ?

2021-01-11 Thread TUELLER, SHAYNE R CIV USAF AFMC 519 SWES/MXDEC via gdal-dev
I love FWTools. Still use it quite often. I wish it was still actively maintained. Shayne From: gdal-dev on behalf of jratike80 Sent: Monday, January 11, 2021 11:55 AM To: gdal-dev@lists.osgeo.org Subject: [Non-DoD Source] Re: [gdal-dev] Considering drivers re

[gdal-dev] vector layer with Z coordinate - report extent in 3D

2021-01-11 Thread Ricardo Filipe Soares Garcia da
Hi list Is there some brief way to get the Z extent of a vector layer? I mean something analogous to the Layer.GetExtent() method, but which would retrieve the extent of the Z coordinate? OTherwise, it seems like I need to iterate over all features of the layer and keep the min/max Z values. Shal

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Sean Gillies via gdal-dev
Hi Even, On Mon, Jan 11, 2021 at 7:44 AM Even Rouault wrote: > Hi, > > trying to answer the different points raised up to now: > > - SVG: let's keep it as it is used. This is exactly the feedback I'm > seeking > for. I had developed this as a toy, crazy me, I won't do it anymore. No > idea > any

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Frank Warmerdam
Even, My opinion is that old drivers which do not depend on external libraries/services and that we have tests for should be retained until they cause painful problems. I would be supportive of dropping drivers for which there is no apparent interest, and that are not buildable and testable due t

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Joaquim Manuel Freire Luís
> - GMT is an active project and some GMT developers appear on this list as > well. Maybe some of them happend to read this and say if GMT ASCII vectors > are still important for GMT. Or otherwise I can ask from the GMT forum. Right. The GMT raster driver is from the times GNT used a 1-d array

[gdal-dev] netCDF chunk fetch failed

2021-01-11 Thread Kurt Schwehr
Hi all, In a build of gdal 3.2.0, I'm seeing this error: "netCDF chunk fetch failed" for 2 out of 5 subdatasets. Is there an easy way to handle this so the bad data is returned as the nodata value? And also, any idea what is actually wrong with the netcdf files? I am in contact with the NOAA fo

Re: [gdal-dev] [EXTERNAL] Re: Considering drivers removal ?

2021-01-11 Thread Hare, Trent M via gdal-dev
Speaking on behave of folks who support archives, I highly recommend keeping old drivers, unless as Frank stated, they cause an issue (code or license). We are often faced with dealing with code rot, but in the same vein, we will also find ourselves dealing with more and more outdated file forma

Re: [gdal-dev] Considering drivers removal ?

2021-01-11 Thread Jed O. Kaplan
I for one am using the GMT vector driver for GDAL on a regular basis, e.g., for integration between GRASS GIS and GMT for cartography. I am grateful to the developers for their continued support for this driver. Thanks, Jed ___ gdal-dev mailing list g