from:"Gerald Nelson"

Re: [gdal-dev] NetCDF projection help

2022-07-12 Thread Gerald Nelson

Have you tried using the R package terra? It imports netCDF pretty much 
painlessly. It has the latest version of GDAL in the background doing the heavy 
lifting.

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 "DeTracey, 
Brendan" 
Date: Tuesday, July 12, 2022 at 5:53 AM
To: "gdal-dev@lists.osgeo.org" 
Subject: [gdal-dev] NetCDF projection help

Hi,

I have been "gifted" a netcdf raster that I must vectorize. When I load the 
raster into QGIS the coordinates are not correct. I believe that QGIS uses GDAL 
drivers. I have included a download link to the file, a ncdump -h,  and 
gdalinfo output, all at the bottom of this message. The raster is on the CORDEX 
arctic grid [https://cordex.org/domains/region-11-arctic/], a rotated pole 
projection with the pole at 0.0E, 6.55N and a Top Left Corner of 337.12E, 
33.88N. My raster is double the resolution described in the specification. The 
raster covers the arctic and is a binary mask for Baffin Bay. The raster 
includes the lat and lon, but not the rotated projection lat and lon.

What do I need to do to get QGIS to properly load the coordinates for this 
raster? (The raster is too coarse for my needs. My plan is to use QGIS to 
manually draw a shapefile of the raster boundaries.) Why is the GDAL netcdf 
driver not properly creating an affine? Is it because the raster spans the pole?

Thanks so much,
Brendan

https://file.io/3ITCNwX0fg3s : CORDEX_subarea_O3.nc : 1MB

$ ncdump -h CORDEX_subarea_O3.nc
netcdf CORDEX_subarea_O3 {
dimensions:
x = 232 ;
y = 266 ;
variables:
double lon(y, x) ;
lon:standard_name = "longitude" ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:_CoordinateAxisType = "Lon" ;
double lat(y, x) ;
lat:standard_name = "latitude" ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:_CoordinateAxisType = "Lat" ;
double mmask(y, x) ;
mmask:coordinates = "lon lat" ;
mmask:_FillValue = -9.e+33 ;
mmask:missing_value = -9.e+33 ;

// global attributes:
:CDI = "Climate Data Interface version 1.6.8 
(http://mpimet.mpg.de/cdi)" ;
:Conventions = "CF-1.4" ;
:history = "Mon Apr 20 17:37:28 2020: cdo eqc,3 
All_subareas_CORDEX_final.nc CORDEX_subarea_O3.nc\n",
"Sat Apr 11 22:10:21 2020: cdo add jonn.nc jlnn.nc 
jann.nc\n",
"Sat Apr 11 21:55:59 2020: cdo sub latest_5.nc jln.nc 
jon.nc\n",
"Sat Apr 11 17:29:06 2020: cdo add jos.nc 
Land_subareas_new.nc All_subareas_CORDEX_reedited.nc\n",
"Sat Apr 11 17:22:45 2020: cdo sub 
All_subareas_CORDEX_edited.nc j.nc jos.nc\n",
"Tue Apr 07 15:58:18 2020: cdo add jon.nc 
EPA_Arctic_bioregions_CORDEX_land_masked_edited.nc 
All_subareas_CORDEX_edited.nc\n",
"Tue Apr 07 15:19:29 2020: cdo sub 
All_subareas_CORDEX_best.nc jl.nc jo.nc_\n",
"Tue Apr 07 00:58:57 2020: cdo 
remapnn,ARC-22_sample_grid.nc All_subareas_.25deg.nc j.nc\n",
"Tue Apr 07 00:48:41 2020: cdo add 
NAA_subareas_.25deg.nc EPA_Arctic_bioregions_.25degx-1.nc 
All_subareas_.25deg.nc\n",
"Tue Apr 07 00:48:01 2020: cdo mulc,-1 
EPA_Arctic_bioregions_.25deg.nc EPA_Arctic_bioregions_.25degx-1.nc\n",
"Mon Apr 06 17:20:07 2020: cdo add 
4xAlaskan_Tundra_mask_l2_.25deg.nc jNSCff.nc jNSCA.nc\n",
"Mon Apr  6 17:18:06 2020: 
/HOME/opt/package/nco/linux64/bin/ncap2 -s mask_array=int(mask_array) jNSCf.nc 
jNSCff.nc\n",
"Mon Apr  6 17:17:29 2020: 
/HOME/opt/package/nco/linux64/bin/ncap2 -s where(mask_array > 3.) mask_array = 
3. jNSCfl.nc jNSCf.nc\n",
"Mon Apr  6 17:17:06 2020: 
/HOME/opt/package/nco/linux64/bin/ncap2 -s mask_array=float(mask_array) jNSC.nc 
jNSCfl.nc\n",
"Mon Apr 06 16:38:46 2020: cdo add 
3xArctic_Cordillera_mask_l2_.25deg.nc jNS.nc jNSC.nc\n",
"Mon Apr 06 16:36:11 2020: cdo add 
Southern_Arctic_mask_l2_.25deg.nc 2xNorthern_Arctic_mask_l2_.25deg.nc jNS.nc\n",
"Mon Apr 06 16:35:10 2020: cdo mulc,2 
Northern_Arctic_mask_l2_.25deg.nc 2xNorthern_Arctic_mask_l2_.25deg.nc" ;
:DOMAIN_number_total = 1 ;
:DOMAIN_number = 0 ;
:DOMAIN_dimensions_ids = 1, 2 ;
:DOMAIN_size_global = 568, 400 ;
:DOMAIN_size_local = 568, 400 ;
:DOMAIN_position_first = 1, 1 ;
:DOMAIN_position_last = 568, 400 ;
:DOMAIN_halo_size_start = 0, 0 ;
:DOMAIN_halo_size_end = 0, 0

Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

2022-02-17 Thread Gerald Nelson

Evan, thanks for the update. You guys are great!

Since I can’t really contribute to the development I’ll stand on the sidelines 
and periodically cheer you on! 😊

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Even Rouault 
Date: Thursday, February 17, 2022 at 1:21 PM
To: Gerald Nelson , Daniel Baston 
, GEOS Development List 
Cc: gdal dev 
Subject: Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

Gerald,

Part of my funded maintenance activities on GDAL also benefit to some of its 
dependencies with which I'm familiar/a committer, and PROJ is the first one 
among those (15% of my time to date if my stats are right).

Even
Le 17/02/2022 à 18:53, Gerald Nelson a écrit :
I’m mainly a lurker on these exchanges. But from afar it seems like there are 
three key underlying efforts in the whole spatial data and analysis world – 
gdal, geos, and proj. It’s really good to see cooperation (and funding!) for 
the gdal and geos part of the triumvirate. Would it make sense to see about 
adding proj to it?

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 
<mailto:gdal-dev-boun...@lists.osgeo.org> on 
behalf of Daniel Baston <mailto:dbas...@gmail.com>
Date: Thursday, February 17, 2022 at 10:47 AM
To: GEOS Development List 
<mailto:geos-de...@lists.osgeo.org>
Cc: gdal dev <mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

Thank you, all. I'm honored by your support.

Please don't hesitate to open issues on the GEOS GitHub page to share any ideas 
you have about how GEOS can better support GDAL and friends.

Dan

On Thu, Feb 17, 2022 at 11:13 AM Howard Butler 
mailto:how...@hobu.co>> wrote:
Declaring this motion passed with +1's from

DanielM, EvenR, NormanB, TamasS, HowardB, MateuszL, FrankW, KurtS, and SeanG

The GDAL PSC is fully delegating these resources to the GEOS PSC to use as it 
sees fit. Paul Ramsey has agreed to be the administrative contact for the GEOS 
PSC, and will coordinate the effort in regards to payment sign-off, work task 
development, rate negotiation, and reporting to the GDAL PSC.

Howard

PS: As a member of both PSCs, I will abstain from any funding or resource 
direction votes in the GEOS PSC to avoid any potential conflict.

> On Feb 15, 2022, at 9:37 AM, Howard Butler 
> mailto:how...@hobu.co>> wrote:
>
> GDAL PSC,
>
> When we wrote the GDAL RFCs on sponsorship, we provided an escape clause to 
> allow us to direct resources to other projects upon which GDAL depends. Our 
> sponsorship numbers are still increasing, which provides us an opportunity to 
> directly support some of those projects, and one of them is obviously GEOS. 
> GEOS provides all of the geometry algebra support for GDAL/OGR and many other 
> open source geospatial softwares including Shapely, PostGIS, GeoPandas, 
> MapServer, and more.
>
> Dan Baston of the GEOS PSC has been identified as the developer with capacity 
> and interest in the next year to take on GEOS development on APIs and 
> performance, which he has a long history of doing for the project. This 
> support should allow him to work longer, multi-release upgrades that will 
> provide strong performance and convenience benefits for the project.
>
> I motion to provide the GEOS PSC with a $50,000 USD grant to address 
> performance, API, and other work that does not attract directed funding in 
> GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, 
> and development timelines. Howard Butler or Even Rouault of the GDAL NumFocus 
> liaison team will coordinate dispersement as directed by the GEOS PSC and 
> NumFocus rules.
>
> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html who 
> have made this kind of grant possible. A better GEOS makes for a better GDAL.
>
> Howard
>

___
geos-devel mailing list
geos-de...@lists.osgeo.org<mailto:geos-de...@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/geos-devel

___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto: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] [geos-devel] GEOS Maintenance Grant

2022-02-17 Thread Gerald Nelson

I’m mainly a lurker on these exchanges. But from afar it seems like there are 
three key underlying efforts in the whole spatial data and analysis world – 
gdal, geos, and proj. It’s really good to see cooperation (and funding!) for 
the gdal and geos part of the triumvirate. Would it make sense to see about 
adding proj to it?

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 Daniel Baston 

Date: Thursday, February 17, 2022 at 10:47 AM
To: GEOS Development List 
Cc: gdal dev 
Subject: Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

Thank you, all. I'm honored by your support.

Please don't hesitate to open issues on the GEOS GitHub page to share any ideas 
you have about how GEOS can better support GDAL and friends.

Dan

On Thu, Feb 17, 2022 at 11:13 AM Howard Butler 
mailto:how...@hobu.co>> wrote:
Declaring this motion passed with +1's from

DanielM, EvenR, NormanB, TamasS, HowardB, MateuszL, FrankW, KurtS, and SeanG

The GDAL PSC is fully delegating these resources to the GEOS PSC to use as it 
sees fit. Paul Ramsey has agreed to be the administrative contact for the GEOS 
PSC, and will coordinate the effort in regards to payment sign-off, work task 
development, rate negotiation, and reporting to the GDAL PSC.

Howard

PS: As a member of both PSCs, I will abstain from any funding or resource 
direction votes in the GEOS PSC to avoid any potential conflict.

> On Feb 15, 2022, at 9:37 AM, Howard Butler 
> mailto:how...@hobu.co>> wrote:
>
> GDAL PSC,
>
> When we wrote the GDAL RFCs on sponsorship, we provided an escape clause to 
> allow us to direct resources to other projects upon which GDAL depends. Our 
> sponsorship numbers are still increasing, which provides us an opportunity to 
> directly support some of those projects, and one of them is obviously GEOS. 
> GEOS provides all of the geometry algebra support for GDAL/OGR and many other 
> open source geospatial softwares including Shapely, PostGIS, GeoPandas, 
> MapServer, and more.
>
> Dan Baston of the GEOS PSC has been identified as the developer with capacity 
> and interest in the next year to take on GEOS development on APIs and 
> performance, which he has a long history of doing for the project. This 
> support should allow him to work longer, multi-release upgrades that will 
> provide strong performance and convenience benefits for the project.
>
> I motion to provide the GEOS PSC with a $50,000 USD grant to address 
> performance, API, and other work that does not attract directed funding in 
> GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, 
> and development timelines. Howard Butler or Even Rouault of the GDAL NumFocus 
> liaison team will coordinate dispersement as directed by the GEOS PSC and 
> NumFocus rules.
>
> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html who 
> have made this kind of grant possible. A better GEOS makes for a better GDAL.
>
> Howard
>

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

Re: [gdal-dev] does GDAL require proj@7?

2022-02-10 Thread Gerald Nelson

Not malice, just an “it’s not our problem” response. That was from one person; 
others have been more helpful. It turns out that it is complicated because of 
the gdal dependency tree. Here’s an explanation from 
https://github.com/Homebrew/homebrew-core/pull/94807

We're in a bit of bind here. I was able to migrate all dependents of proj@7 to 
proj except 3:

  *   liblwgeom - deprecated, appears to be superseded by librttopo
  *   osm2pgsql - this project appears to be active (the last release was 16 
days ago). We should open an upstream issue to inquire about PROJ 8 support
  *   spatialite-gui - this is where our remaining dependency conflict comes 
from, and it's not pretty. The last stable version doesn't support PROJ 8, but 
the 2.1 beta does. I tried to build the 2.1 beta just to see if would work, and 
it fails because it needs librasterlite2, which we don't package. Our 
librasterlite formula is for an older library which is no longer developed 
because it has been superseded by librasterlite2. Potentially we could just 
update the librasterlite formula because it has no dependents. But that doesn't 
help with version 2.1 of spatialite-gui still being in beta.
Any thoughts on the best solution here?

This is way outside my level of expertise. But it seems someone with some 
serious homebrew expertise is looking into it seriously.


Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Robert Coup 
Date: Thursday, February 10, 2022 at 7:27 AM
To: Gerald Nelson 
Cc: Paul Harwood , gdal-dev 
Subject: Re: [gdal-dev] does GDAL require proj@7?

Hi,

On Wed, 9 Feb 2022 at 16:30, Gerald Nelson 
mailto:nelson.geral...@gmail.com>> wrote:
The homebrew folks just blew me off. Said it was not their problem. So I more 
or less politely responded that it would be helpful if they could provide me 
with contact info for the entity that was responsible for the formula. This 
seems like a minimal information request.


Seems it was changed to depend on proj@7 (from proj) in May 2021: 
https://github.com/Homebrew/homebrew-core/commit/2bc75f848e33cfbc39b17ad4f60bb1ab6274dd65

That was just before the proj formula updated from 7.2.1 to 8.0.1: 
https://github.com/Homebrew/homebrew-core/commits/488f635d6b77620abed9278e2c9031676c4b9b42/Formula/proj.rb

At that point the gdal formula was using 3.3.0. I don't know off the top of my 
head whether 3.3.0 was compatible with Proj 8.0.1 or not.

I don't think there's any malice involved, maybe just being conservative by the 
packager, or working around a test failure.

Updating the GDAL Homebrew formula back to depending on proj (or proj@8) 
instead of proj@7 is a case of making a PR/issue to propose reverting the 
changes from 2bc75f84.

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

Re: [gdal-dev] does GDAL require proj@7?

2022-02-09 Thread Gerald Nelson

The homebrew folks just blew me off. Said it was not their problem. So I more 
or less politely responded that it would be helpful if they could provide me 
with contact info for the entity that was responsible for the formula. This 
seems like a minimal information request.

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Gerald Nelson 
Date: Wednesday, February 9, 2022 at 8:43 AM
To: Paul Harwood 
Cc: gdal-dev 
Subject: Re: [gdal-dev] does GDAL require proj@7?

I posted a note in Homebrew/discussions. The problem seems to be in the json 
api link -  
/api/formula/gdal.json<https://formulae.brew.sh/api/formula/gdal.json>
Which includes proj@7 rather than just proj.

Hopefully whoever can change formulas will see this and fix it.

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Paul Harwood 
Date: Wednesday, February 9, 2022 at 3:35 AM
To: Gerald Nelson 
Cc: gdal-dev 
Subject: Re: [gdal-dev] does GDAL require proj@7?

Well - the Homebrew formula for GDAL 3.4.1 seems to mandate Proj 7 
https://formulae.brew.sh/formula/gdal

That is strange - since the Conda package works on Proj 8! I don't know who 
supports the Brew packaging - I don't think it is core team since Homebrew is 
not listed on the installation page.  https://gdal.org/download.html

I must admit that is why I use Conda on all platforms - it is "generally" more 
up to date and being an environment manager and not just a package manager it 
manages cases like this a lot more robust.

On Tue, 8 Feb 2022 at 16:32, Gerald Nelson 
mailto:nelson.geral...@gmail.com>> wrote:
Follow up on the issue below. I did the following gdal is now available. But 
I’d still like to kill proj@7 so any suggestions still greatly appreciated!

gcn@MacBook-Pro-M1X homebrew-core % git restore Formula/p...@7.rb
gcn@MacBook-Pro-M1X homebrew-core % brew install gdal
Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
Updated 2 formulae.

Warning: proj@7 has been deprecated because it is not supported upstream!
==> Downloading https://ghcr.io/v2/homebrew/core/proj/7/manifests/7.2.1
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/ea2e810b55db50e5431b28bbb758bbaaf088f1be1671b09889af262cae8f3a29--proj@7-7.2.1.bottle_manifest.json
==> Downloading 
https://ghcr.io/v2/homebrew/core/proj/7/blobs/sha256:29f65a3b916e6b967c157713b7a00daf1b91c01
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/1a72b0f45e8fcbf863d3c52697cee4139ce94d16ce87cd6107413eb3be91afdd--proj@7--7.2.1.arm64_monterey.bottle.tar.gz
==> Downloading https://ghcr.io/v2/homebrew/core/gdal/manifests/3.4.1_1
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/d34f5de12d8fd177fa8682a6311e5a4431f01cca9d2e8431842fa52794192486--gdal-3.4.1_1.bottle_manifest.json
==> Downloading 
https://ghcr.io/v2/homebrew/core/gdal/blobs/sha256:3e0605bfd13304fca41e3d2218abe035985194f1a
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/2318978fe3df634d8fe1682e41380687245f21099fd5c5e03bb84ae58d46cbf6--gdal--3.4.1_1.arm64_monterey.bottle.tar.gz
==> Installing dependencies for gdal: proj@7
==> Installing gdal dependency: proj@7
==> Pouring proj@7--7.2.1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/proj@7/7.2.1: 59 files, 19.2MB
==> Installing gdal
==> Pouring gdal--3.4.1_1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/gdal/3.4.1_1: 356 files, 61.2MB
==> Running `brew cleanup gdal`...


Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Gerald Nelson 
mailto:nelson.geral...@gmail.com>>
Date: Tuesday, February 8, 2022 at 9:09 AM
To: gdal-dev mailto:gdal-dev@lists.osgeo.org>>
Subject: does GDAL require proj@7?

I indirectly make a lot of use of GDAL which makes a lot of use of proj. I do 
all this on a new Macbook pro with Apple Silicon. I manage these things with 
homebrew. It was a tiny bit complicated to get homebrew running to take 
advantage of the new silicon but I’ve been doing that successfully for a month 
or so.

At some point in the past I installed proj@7 from homebrew. That’s now 
deprecated but I can’t seem to kill it on my system. Lots of brew uninstall and 
install/upgrade commands. I used locate in a terminal and attempted to delete 
all the files with proj@7 in their names. I’m currently have this set of 
exchanges


gcn@MacBook-Pro-M1X Cellar % brew install gdal

Warning: No available formula with the name "proj@7" (dependency of gdal). Did 
you mean proj?

==> Searching for similarly named formulae...

This similarly named formula was found:

proj ✔

To install it, run:

  brew install proj ✔
gcn@MacBook-Pro-M1X Cell

Re: [gdal-dev] does GDAL require proj@7?

2022-02-09 Thread Gerald Nelson

I posted a note in Homebrew/discussions. The problem seems to be in the json 
api link -  
/api/formula/gdal.json<https://formulae.brew.sh/api/formula/gdal.json>
Which includes proj@7 rather than just proj.

Hopefully whoever can change formulas will see this and fix it.

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Paul Harwood 
Date: Wednesday, February 9, 2022 at 3:35 AM
To: Gerald Nelson 
Cc: gdal-dev 
Subject: Re: [gdal-dev] does GDAL require proj@7?

Well - the Homebrew formula for GDAL 3.4.1 seems to mandate Proj 7 
https://formulae.brew.sh/formula/gdal

That is strange - since the Conda package works on Proj 8! I don't know who 
supports the Brew packaging - I don't think it is core team since Homebrew is 
not listed on the installation page.  https://gdal.org/download.html

I must admit that is why I use Conda on all platforms - it is "generally" more 
up to date and being an environment manager and not just a package manager it 
manages cases like this a lot more robust.

On Tue, 8 Feb 2022 at 16:32, Gerald Nelson 
mailto:nelson.geral...@gmail.com>> wrote:
Follow up on the issue below. I did the following gdal is now available. But 
I’d still like to kill proj@7 so any suggestions still greatly appreciated!

gcn@MacBook-Pro-M1X homebrew-core % git restore Formula/p...@7.rb
gcn@MacBook-Pro-M1X homebrew-core % brew install gdal
Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
Updated 2 formulae.

Warning: proj@7 has been deprecated because it is not supported upstream!
==> Downloading https://ghcr.io/v2/homebrew/core/proj/7/manifests/7.2.1
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/ea2e810b55db50e5431b28bbb758bbaaf088f1be1671b09889af262cae8f3a29--proj@7-7.2.1.bottle_manifest.json
==> Downloading 
https://ghcr.io/v2/homebrew/core/proj/7/blobs/sha256:29f65a3b916e6b967c157713b7a00daf1b91c01
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/1a72b0f45e8fcbf863d3c52697cee4139ce94d16ce87cd6107413eb3be91afdd--proj@7--7.2.1.arm64_monterey.bottle.tar.gz
==> Downloading https://ghcr.io/v2/homebrew/core/gdal/manifests/3.4.1_1
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/d34f5de12d8fd177fa8682a6311e5a4431f01cca9d2e8431842fa52794192486--gdal-3.4.1_1.bottle_manifest.json
==> Downloading 
https://ghcr.io/v2/homebrew/core/gdal/blobs/sha256:3e0605bfd13304fca41e3d2218abe035985194f1a
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/2318978fe3df634d8fe1682e41380687245f21099fd5c5e03bb84ae58d46cbf6--gdal--3.4.1_1.arm64_monterey.bottle.tar.gz
==> Installing dependencies for gdal: proj@7
==> Installing gdal dependency: proj@7
==> Pouring proj@7--7.2.1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/proj@7/7.2.1: 59 files, 19.2MB
==> Installing gdal
==> Pouring gdal--3.4.1_1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/gdal/3.4.1_1: 356 files, 61.2MB
==> Running `brew cleanup gdal`...


Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Gerald Nelson 
mailto:nelson.geral...@gmail.com>>
Date: Tuesday, February 8, 2022 at 9:09 AM
To: gdal-dev mailto:gdal-dev@lists.osgeo.org>>
Subject: does GDAL require proj@7?

I indirectly make a lot of use of GDAL which makes a lot of use of proj. I do 
all this on a new Macbook pro with Apple Silicon. I manage these things with 
homebrew. It was a tiny bit complicated to get homebrew running to take 
advantage of the new silicon but I’ve been doing that successfully for a month 
or so.

At some point in the past I installed proj@7 from homebrew. That’s now 
deprecated but I can’t seem to kill it on my system. Lots of brew uninstall and 
install/upgrade commands. I used locate in a terminal and attempted to delete 
all the files with proj@7 in their names. I’m currently have this set of 
exchanges


gcn@MacBook-Pro-M1X Cellar % brew install gdal

Warning: No available formula with the name "proj@7" (dependency of gdal). Did 
you mean proj?

==> Searching for similarly named formulae...

This similarly named formula was found:

proj ✔

To install it, run:

  brew install proj ✔
gcn@MacBook-Pro-M1X Cellar % brew install proj
To restore the stashed changes to 
/opt/homebrew/Library/Taps/homebrew/homebrew-core, run:
  cd /opt/homebrew/Library/Taps/homebrew/homebrew-core && git stash pop
Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core and homebrew/cask).
==> Updated Formulae
Updated 1 formula.
==> Updated Casks
Updated 4 casks.

Warning: proj 8.2.1 is already installed and up-to-date.
To reinstall 8.2.1, run:
  brew reinstall proj
gcn@MacBook-Pro-M1X Cellar %   cd 
/opt/homebrew/Library/Taps/hom

Re: [gdal-dev] does GDAL require proj@7?

2022-02-08 Thread Gerald Nelson

Follow up on the issue below. I did the following gdal is now available. But 
I’d still like to kill proj@7 so any suggestions still greatly appreciated!

gcn@MacBook-Pro-M1X homebrew-core % git restore Formula/p...@7.rb
gcn@MacBook-Pro-M1X homebrew-core % brew install gdal
Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
Updated 2 formulae.

Warning: proj@7 has been deprecated because it is not supported upstream!
==> Downloading https://ghcr.io/v2/homebrew/core/proj/7/manifests/7.2.1
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/ea2e810b55db50e5431b28bbb758bbaaf088f1be1671b09889af262cae8f3a29--proj@7-7.2.1.bottle_manifest.json
==> Downloading 
https://ghcr.io/v2/homebrew/core/proj/7/blobs/sha256:29f65a3b916e6b967c157713b7a00daf1b91c01
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/1a72b0f45e8fcbf863d3c52697cee4139ce94d16ce87cd6107413eb3be91afdd--proj@7--7.2.1.arm64_monterey.bottle.tar.gz
==> Downloading https://ghcr.io/v2/homebrew/core/gdal/manifests/3.4.1_1
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/d34f5de12d8fd177fa8682a6311e5a4431f01cca9d2e8431842fa52794192486--gdal-3.4.1_1.bottle_manifest.json
==> Downloading 
https://ghcr.io/v2/homebrew/core/gdal/blobs/sha256:3e0605bfd13304fca41e3d2218abe035985194f1a
Already downloaded: 
/Users/gcn/Library/Caches/Homebrew/downloads/2318978fe3df634d8fe1682e41380687245f21099fd5c5e03bb84ae58d46cbf6--gdal--3.4.1_1.arm64_monterey.bottle.tar.gz
==> Installing dependencies for gdal: proj@7
==> Installing gdal dependency: proj@7
==> Pouring proj@7--7.2.1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/proj@7/7.2.1: 59 files, 19.2MB
==> Installing gdal
==> Pouring gdal--3.4.1_1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/gdal/3.4.1_1: 356 files, 61.2MB
==> Running `brew cleanup gdal`...


Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

From: Gerald Nelson 
Date: Tuesday, February 8, 2022 at 9:09 AM
To: gdal-dev 
Subject: does GDAL require proj@7?

I indirectly make a lot of use of GDAL which makes a lot of use of proj. I do 
all this on a new Macbook pro with Apple Silicon. I manage these things with 
homebrew. It was a tiny bit complicated to get homebrew running to take 
advantage of the new silicon but I’ve been doing that successfully for a month 
or so.

At some point in the past I installed proj@7 from homebrew. That’s now 
deprecated but I can’t seem to kill it on my system. Lots of brew uninstall and 
install/upgrade commands. I used locate in a terminal and attempted to delete 
all the files with proj@7 in their names. I’m currently have this set of 
exchanges


gcn@MacBook-Pro-M1X Cellar % brew install gdal

Warning: No available formula with the name "proj@7" (dependency of gdal). Did 
you mean proj?

==> Searching for similarly named formulae...

This similarly named formula was found:

proj ✔

To install it, run:

  brew install proj ✔
gcn@MacBook-Pro-M1X Cellar % brew install proj
To restore the stashed changes to 
/opt/homebrew/Library/Taps/homebrew/homebrew-core, run:
  cd /opt/homebrew/Library/Taps/homebrew/homebrew-core && git stash pop
Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core and homebrew/cask).
==> Updated Formulae
Updated 1 formula.
==> Updated Casks
Updated 4 casks.

Warning: proj 8.2.1 is already installed and up-to-date.
To reinstall 8.2.1, run:
  brew reinstall proj
gcn@MacBook-Pro-M1X Cellar %   cd 
/opt/homebrew/Library/Taps/homebrew/homebrew-core && git stash pop
Removing Formula/p...@7.rb
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
   deleted:Formula/p...@7.rb

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (cf00995d0160fc9ed0889b664973b1c75a4a5925)

At this point I’m stuck on next steps. I suspect this is not a gdal problem per 
se but something in homebrew I’m not understanding.

Any advice greatly appreciated!
Jerry

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

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

[gdal-dev] does GDAL require proj@7?

2022-02-08 Thread Gerald Nelson

I indirectly make a lot of use of GDAL which makes a lot of use of proj. I do 
all this on a new Macbook pro with Apple Silicon. I manage these things with 
homebrew. It was a tiny bit complicated to get homebrew running to take 
advantage of the new silicon but I’ve been doing that successfully for a month 
or so.

At some point in the past I installed proj@7 from homebrew. That’s now 
deprecated but I can’t seem to kill it on my system. Lots of brew uninstall and 
install/upgrade commands. I used locate in a terminal and attempted to delete 
all the files with proj@7 in their names. I’m currently have this set of 
exchanges


gcn@MacBook-Pro-M1X Cellar % brew install gdal

Warning: No available formula with the name "proj@7" (dependency of gdal). Did 
you mean proj?

==> Searching for similarly named formulae...

This similarly named formula was found:

proj ✔

To install it, run:

  brew install proj ✔
gcn@MacBook-Pro-M1X Cellar % brew install proj
To restore the stashed changes to 
/opt/homebrew/Library/Taps/homebrew/homebrew-core, run:
  cd /opt/homebrew/Library/Taps/homebrew/homebrew-core && git stash pop
Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core and homebrew/cask).
==> Updated Formulae
Updated 1 formula.
==> Updated Casks
Updated 4 casks.

Warning: proj 8.2.1 is already installed and up-to-date.
To reinstall 8.2.1, run:
  brew reinstall proj
gcn@MacBook-Pro-M1X Cellar %   cd 
/opt/homebrew/Library/Taps/homebrew/homebrew-core && git stash pop
Removing Formula/p...@7.rb
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
   deleted:Formula/p...@7.rb

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (cf00995d0160fc9ed0889b664973b1c75a4a5925)

At this point I’m stuck on next steps. I suspect this is not a gdal problem per 
se but something in homebrew I’m not understanding.

Any advice greatly appreciated!
Jerry

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d

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

Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer

2021-08-17 Thread Gerald Nelson

I’m not a member of the core group, or even a direct gdal user, so I can’t 
officially vote, but I am really impressed with how the core group has managed 
this process. And from a far distance, Even seems like a great choice.

Keep up the good work!
Jerry

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 Sean Gillies 

Date: Tuesday, August 17, 2021 at 9:58 AM
To: gdal dev 
Subject: Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL 
maintainer

+1 from me. What a great milestone for the project!

On Tue, Aug 17, 2021 at 9:34 AM Howard Butler 
mailto:how...@hobu.co>> wrote:
Dear PSC,

As a result of our fundraising activity and development of NumFOCUS as a 
financial conduit, it is my pleasure to put forward a motion to approve Even 
Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on 
August 1st, 2021 and ending July 31st, 2022.

Details of the maintenance tasking and duties can be found at the previously 
approved RFC 83 
https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html

The terms of the contract are for 833 hours at $120/hr USD.

Howard

PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS 
contracting liaison, with Frank Warmerdam acting as the secondary. Please 
contact us directly with any comments or concerns.

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

Re: [gdal-dev] Info about technical details of loading massive data

2021-02-11 Thread Gerald Nelson

I’m an end user, of software for which gdal is a critical input, in particular 
the R package terra, the successor to the raster package. I’m using it with 
very large climate data files. Terra (and raster) are built to deal with memory 
space available and the read and write from disk to temporary files. So in 
principle you can work with very large data sets on a machine with relatively 
little ram. Depending on your disk speed this can be tolerable or extremely 
slow.

But my ad hoc experimentation with a mac book pro with 32 gb of ram and an 
intel processor and a linux box with 64 gb has shown some remarkable 
differences. The bottom line is that the mac’s memory management is incredible. 
I can look at the system monitor on the amount ram an rsession is using and see 
50 gb, with no memory pressure indicated and no temporary files being written 
by terra. On the linux box, the same R code crashes the machine. And code that 
takes x time on the mac takes 2-3 x time on the linux box.

And this is before the new Apple silicon, which by all accounts speeds up 
things dramatically. I’m saving my pennies.

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 Andrew C 
Aitchison 
Date: Thursday, February 11, 2021 at 4:06 AM
To: Richard Duivenvoorde 
Cc: "gdal-dev@lists.osgeo.org" 
Subject: Re: [gdal-dev] Info about technical details of loading massive data

On Thu, 11 Feb 2021, Richard Duivenvoorde wrote:

Hi Dev's,

I had a discussion with a friend about the sometimes hard times a
GIS-person has when handling/loading/viewing (using QGIS/GDAL)
massive (vector/raster) datasets, versus the R/Data-mangling
community.

Ending with a conclusion that it seemed (to us) that data-scientists
try to load as much (clean objects/multi dimensional arrays) data in
memory as possible, while GIS peeps always use the 'let's make it
some kind of feature object from first, and do lazy loading' way
use.

BUT I'm not sure about this, so: is there maybe somebody who held a
presentation or wrote a paper on how, for example gdal, handles a
huge point file vs R (memory/disk/io wise)?

While historically the 'Simple Features'-paradigm has be VERY
valuable for us, I'm questioning myself if there could be some 'more
efficient' way of handling the every time growing datasets we have
to handle... I envision a super fast memory-data viewer or so, so I
can quickly view my 16 Million points in my Postgis DB easily (mmm
probably have to fork QGIS 0.1 for this... QGIS started of as a
'simple' postgis viewer :-) )

My experience is limited to file-based data and machines
have grown to the point where the files will fit in memory.

I have written a couple of device drivers (not yet released)
for raster file formats which seem designed for memory-mapped
read access. Although functions like VSIFReadL support
reading from memory-based files, I have not found a way to
use memory-mapping in a driver.
This makes me wonder whether I end up with three copies of the map in
memory in addition to whatever is needed for the screen display;
one in the Linux file-system cache, one in the driver
and one (or perhaps two) in the gdal library and QGIS ?

I haven't looked, and perhaps should, to see whether QGIS
reads a map once into whatever format it finds best (possibly compressed),
keeps each map open and reads areas as needs, or repeatedly opens, reads
and closes each map.
Without knowing that, it isn't clear which map decompressions and
memory to memory copies are necessary.

--
Andrew C. Aitchison 
   Kendal, UK

and...@aitchison.me.uk
___
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] Driver maintenance - long-term solution ?

2021-01-13 Thread Gerald Nelson

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@lists.osgeo.org" 
Subject: Re: [gdal-dev] Driver maintenance - long-term solution ?

+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 support after the earthquake in Nepal. It took a 5 
minute call to VP to get a 6-figure budget and 6 months to find a route to get 
the money or goods delivered! I was told at the time that the lead time for 
getting a new not-for-profit organisation approved was 2 - 5 years! And don't 
even think of trying to get a payment for services without a service 
description, PO and invoice from an approved supplier. It is just physically 
impossible. They have huge resources in developer time that they throw around 
at a moment's notices but exporting cash is impossible.

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).

On Wed, 13 Jan 2021 at 23:08, Carl Godkin 
mailto:cgod...@gmail.com>> wrote:
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 donations seem to be an easy way to 
pay our part.

Thanks,
carl

On Wed, Jan 13, 2021 at 2:58 PM Howard Butler 
mailto:how...@hobu.co>> wrote:



On Jan 13, 2021, at 4:28 PM, Nyall Dawson 
mailto:nyall.daw...@gmail.com>> wrote:

On Thu, 14 Jan 2021 at 06:24, David Strip 
mailto:g...@stripfamily.net>> 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 an interesting
thought. I wonder if any new drivers added to GDAL could be done with
a dual-licensing under both GPL + some other license which requires
ongoing sponsorship of the GDAL project?

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.

The big organizations running 100,000,000s of CPU hours extracting information 
from imagery they're reading in COGs with GDAL need to be donating substantial 
resources into an organization that provides coordination. The last time I did 
a fund raise with gdalbarn.com I was called out for naming 
some of these organizations and expressing my disappointment they couldn't find 
a way to participate or simply ignored the request.  Maybe they will step 
forward this time around.

Whether it is in a new foundation or an existing one like NumFocus, substantial 
resources need to be dumped in a pot that are earmarked for supporting work 
that generates value for the project. Chasing new feature work to subsidize 
project maintenance activities is not sustainable in two directions – burn out 
for the maintainer and creeping feature-itis for the project.

It's clear what's happened in the past is a combination of luck and 
graciousness by both Frank and Even.

Howard
___
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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] how to completely remove gdal from Ubuntu 20.04 and install from scratch

2020-08-07 Thread Gerald Nelson



I have both a mac and a linux box with Ubuntu 20.04. gdal on the mac is 
installed through home brew. gdal on the linux box has been installed both from 
source with the usual configure, make, make install and with sudo apt-get 
install gdal-bin. Both completed successfully and sudo apt-get install gdal-bin 
returned GDAL 3.1.2, released 2020/07/07.

When I attempt to install or upgrade sf, rgdal, or terra I get similar error 
messages. They come after

** testing if installed package can be loaded from temporary location

The messages are

free(): invalid size

Aborted (core dumped).

Another thread suggested that there should not be multiple versions of gdal on 
a machine. I didn’t intend for there to be but I had GDAL 3.0.7 originally on 
the linux box before installing GDAL3.1.2 so it is possible that there may be 
bits of the older version around.

I can’t find any good directions for how to do a deep clean, or for that matter 
to install gdal on Ubuntu 20.04 so I was hoping to get some directions here.

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] make failing with gdal-3.1.0 on Mac Catalina (10.15.4)

2020-05-26 Thread Gerald Nelson

I get through the ./configure process successfully (at least with no error 
messages). When I run make I get a lot of messages but obvious error messages 
until I get towards the end when I get the following


 -rpath /usr/local/lib \

-no-undefined \

-version-info 27:0:0

Undefined symbols for architecture x86_64:

  "_FreeMapObject", referenced from:

  GIFDataset::CreateCopy(char const*, GDALDataset*, int, char**, int 
(*)(double, char const*, void*), void*) in gifdataset.o

  "_MakeMapObject", referenced from:

  GIFDataset::CreateCopy(char const*, GDALDataset*, int, char**, int 
(*)(double, char const*, void*), void*) in gifdataset.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[1]: *** [GNUmakefile:68: libgdal.la] Error 1

make[1]: Leaving directory '/Users/gcn/Downloads/gdal-3.1.0'

make: *** [GNUmakefile:79: check-lib] Error 2

The error seems to be associated with libgdal.1a. When I run


locate libgdal.la

It returns

/Applications/GRASS-7.4.1.app/Contents/Resources/lib/libgdal.la

This is a file with a June 2018 date which I suspect is both out of date and in 
the wrong place.

Suggestions for fixes greatly appreciated!

Gerald C. Nelson
Professor Emeritus, UIUC
+1 217-390-7888 (cell)
+1 970-639-2079 (land line)
Skype: jerrynelson
http://bit.ly/1arho7d
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] NetCDF projection help

Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

Re: [gdal-dev] does GDAL require proj@7?

Re: [gdal-dev] does GDAL require proj@7?

Re: [gdal-dev] does GDAL require proj@7?

Re: [gdal-dev] does GDAL require proj@7?

[gdal-dev] does GDAL require proj@7?

Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer

Re: [gdal-dev] Info about technical details of loading massive data

Re: [gdal-dev] Driver maintenance - long-term solution ?

[gdal-dev] how to completely remove gdal from Ubuntu 20.04 and install from scratch

[gdal-dev] make failing with gdal-3.1.0 on Mac Catalina (10.15.4)

13 matches

Site Navigation

Mail list logo

Footer information