date:20211115

[gdal-dev] gdal issue with libcurl

2021-11-15 Thread Frank Chuang

I just installed version 3.4.0 of gdal using standard conda install, but
having error message stating libcurl version is incompatible with libgdal:

dyld: Library not loaded: @rpath/libcurl.4.dylib
  Referenced from:
/Users/chuang/opt/anaconda3/envs/gdal/lib/libgdal.30.dylib
  Reason: Incompatible library version: libgdal.30.dylib requires version
12.0.0 or later, but libcurl.4.dylib provides version 8.0.0
Abort trap: 6

Can anyone provide suggestions on how to remedy this? Can this be solved
by turning curl off when executing gdal? Thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Polar stereographic projection invalid definition ?

2021-11-15 Thread Even Rouault


Louis-Philippe,


If this looks like a bug to you, let me know, I will open an issue on 
the gdal repo.


You already did in https://github.com/OSGeo/gdal/issues/4144 :-). And 
this was fixed in 3.3.2


Even

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

[gdal-dev] Polar stereographic projection invalid definition ?

2021-11-15 Thread Rousseau Lambert,Louis-Philippe (ECCC)


Hi all,

I have an issue with a polar stereographic projection definition.

Context: I tried to open a NetCDF files in QGIS and with GDAL and it 
failed with:


 * Gdal:/ERROR 1: PROJ: proj_as_proj_string: Unsupported conversion
   method: Polar_Stereographic/
 * Qgis:/WARNING Could not reproject layer extent: Could not transform
   bounding box to taret CRS
   /

The projection fails with the previous error for both gdal and proj 
versions:


 * GDAL 3.1.3, 3.3.0
 * PROJ 7.2.0, 8.01

Test files (really any files in the folder will have the same behavior):

 * 
https://dd.weather.gc.ca/model_giops/netcdf/polar_stereographic/2d/00/003/CMC_giops_votemper_depth_0.5_ps5km60N_3h-mean_*{MMDDHH}*_P003.nc

I tried opening the files with an older gdal/proj version and it worked 
fine:


 * GDAL: |2.4.4, released 2020/01/08|
 * PROJ: Rel. 4.8.0, 6 March 2012

Here is the projection definition I got: /+proj=stere +lat_0=90 
+lat_ts=59.3768695209 +lon_0=-100 +k=0.93301243 +x_0=4245000 
+y_0=5295000 +a=6371229 +b=6371229 +units=m +no_defs/


When I tried adding the projection manually in Qgis (3.20), I got the 
following error message:


/This proj projection definition is not valid://
//proj_create: lat_ts != lat_0 and k != 1 not supported for Polar 
Stereographic./


Should the projection definition be updated in the NetCDF files if this 
really is not a supported projection definition anymore, or is this a 
bug in gdal?


If this looks like a bug to you, let me know, I will open an issue on 
the gdal repo.


Thanks!

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

Re: [gdal-dev] gdal2tiles and EPSG:27700

2021-11-15 Thread Javier Jimenez Shaw

Thanks!
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 15 Nov 2021 at 13:54, Even Rouault 
wrote:

> Javier,
>
> However using "-ct", swaps the output:
> $ gdalwarp -ct '+proj=pipeline +step +proj=axisswap +order=2,1 +step +inv
> +proj=tmerc +lat_0=44 +lon_0=144.25 +k=0. +x_0=0 +y_0=0 +ellps=GRS80
> +step +proj=webmerc +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84' input.tif
> pipeline.tif
>
> You should add -t_srs EPSG:3857 in the above so that gdalwarp knows that
> the output SRS is != input SRS, and in particular so that it knows it axis
> order. The pipeline specified by -ct will be used even if -s_srs and/or
> -t_srs are specify.  And then you can remove the below gdal_edit
>
> $ gdal_edit.py -a_srs EPSG:3857 pipeline.tif
>
> Even
>
> -- 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] Intermittent memory-corruption crashes in GRIB2 import

2021-11-15 Thread Even Rouault


Simon,

unfortunately there are a number of places in the degrib library which 
aren't thread-safe, and you just spotted that the errSprintf() routine 
was one of them. I've queued a fix for that in 
https://github.com/OSGeo/gdal/pull/4830. Could you try it ?


Regarding gdal_translate performance, this is related to something I 
mentioned recently (not sure to whom), but you'll get much better 
performance if you add -co INTERLEAVE=BAND, so that the output GeoTIFF 
is written band after band, to match the most performant access pattern 
for reading GRIB files.


Even

Le 15/11/2021 à 01:32, Simon Eves a écrit :
We have recently implemented a geo raster importer, and all seems 
fine, except that we hit an issue with a particular GRIB2 file from 
the NOAA website, where we get an inconsistent crash inside GDAL after 
a few hundred scanlines.


We have seen two different crashes inside GDAL, and a third in one of 
our code paths, but given that there is a memory corruption, the 
latter is perhaps unsurprising.


All crashes report "double free or corruption (fasttop)".

We are multi-threading the reading, but using a OGRDataSource per 
thread. The child threads are only calling GetRasterBand(), 
GetRasterDataType() and RasterIO() and only one one band at a time.


The GRIB2 file is 103MB with 73 Float64 bands, but only 2345x1597 
"pixels".


We tried converting the file to GeoTIFF with gdal_translate (no 
options, just in and out) and it took 28 minutes (on a ~2017 i7 quad 
4.2), which is surprising, as we have other GRIB2 files (between 2 and 
12MB) which convert "instantly". The resulting GeoTIFF is much bigger 
(21x) but seems to import reliably, has basically the same schema (as 
reported by gdalinfo) and results in the same data when imported into 
our system.


We only get the crash occasionally, and have only been able to trap it 
in the Debugger a couple of times, with nothing obviously wrong.


Here is a link to the GRIB2 file in question:

https://drive.google.com/file/d/12Fo6jnIhxzCvnSsup9n0kHVKy9lrHD2l/view?usp=sharing 



Attached is the most common stack trace.

With a DEBUG build of GDAL, looks like it's crashing trying to do a 
realloc() on "buffer" which is NULL, although that is supposedly a 
copy of "" at the frame above which seems fine.


Gonna try robustifying that code and see what happens...

This is all with GDAL 3.2.2 on Ubuntu 20.04 LTS with GCC 9.

--


Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA



Email: simon.e...@omnisci.com  | Cell: 
+1 (415) 902-1996





___
gdal-dev mailing list
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] gdal2tiles and EPSG:27700

2021-11-15 Thread Even Rouault


Javier,

However using "-ct", swaps the output:
$ gdalwarp -ct '+proj=pipeline +step +proj=axisswap +order=2,1 +step 
+inv +proj=tmerc +lat_0=44 +lon_0=144.25 +k=0. +x_0=0 +y_0=0 
+ellps=GRS80 +step +proj=webmerc +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 
+ellps=WGS84' input.tif pipeline.tif
You should add -t_srs EPSG:3857 in the above so that gdalwarp knows that 
the output SRS is != input SRS, and in particular so that it knows it 
axis order. The pipeline specified by -ct will be used even if -s_srs 
and/or -t_srs are specify.  And then you can remove the below gdal_edit

$ gdal_edit.py -a_srs EPSG:3857 pipeline.tif


Even


--
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] gdal2tiles and EPSG:27700

2021-11-15 Thread Javier Jimenez Shaw

Hi Even,

Using "gdalwarp -ct" was a good solution. It worked fine. Thanks!
However, when I tested it with another GeoTIFF, this case is from Japan,
gdalwarp is producing something strange.

The image is in EPSG:2455 "JGD2000 / Japan Plane Rectangular CS XIII" ,
that in EPSG is defined as northing-easting.
It is located here:
$ gdalinfo input.tif | grep Center
Center  (  -88109.342, -129144.325) (143d10'20.17"E, 42d49'56.66"N)

I generate the pipeline this way
$ projinfo -s EPSG:2455 -t EPSG:3857 -o PROJ --single-line -q
+proj=pipeline +step +proj=axisswap +order=2,1 +step +inv +proj=tmerc
+lat_0=44 +lon_0=144.25 +k=0. +x_0=0 +y_0=0 +ellps=GRS80 +step
+proj=webmerc +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84

But gdalwarp is producing strange outputs with that pipeline.
Letting gdalwarp read the CRS, it works fine:
$ gdalwarp -t_srs EPSG:3857 input.tif to3857.tif
$ gdalinfo to3857.tif | grep Center
Center  (15937864.003, 5286496.999) (143d10'20.17"E, 42d49'56.66"N)

Setting both CRSs works fine as well:
$ gdalwarp -s_srs EPSG:2455 -t_srs EPSG:3857 input.tif from2455to3857.tif
$ gdalinfo from2455to3857.tif | grep Center
Center  (15937864.003, 5286496.999) (143d10'20.17"E, 42d49'56.66"N)

However using "-ct", swaps the output:
$ gdalwarp -ct '+proj=pipeline +step +proj=axisswap +order=2,1 +step +inv
+proj=tmerc +lat_0=44 +lon_0=144.25 +k=0. +x_0=0 +y_0=0 +ellps=GRS80
+step +proj=webmerc +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84' input.tif
pipeline.tif
$ gdal_edit.py -a_srs EPSG:3857 pipeline.tif
$ gdalinfo pipeline.tif | grep Center
Center  ( 5286496.998,15937864.005) ( 47d29'21.88"E, 80d36'13.79"N)

Am I doing something wrong, or is there any problem in "gdalwarp"?

Thanks.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Wed, 3 Nov 2021 at 15:03, Even Rouault 
wrote:

>
> Le 03/11/2021 à 14:49, Javier Jimenez Shaw a écrit :
> > Hi
> >
> > I have a GeoTIFF in EPSG:27700, "OSGB36 / British National Grid"
> > For consistency reasons, I want to run gdal2tiles with an equivalent
> > transformation than the one I will use later to transform points using
> > a PROJ pipeline. For consistency reasons I will use that pipeline
> > along the time to transform the points, so an update in EPSG/PROJ does
> > not change the results (I generate the gdal2tiles at project creation
> > time, but run the transformation on the marker points along the time).
> >
> > Getting the PROJ pipeline is easy with something like
> > projinfo -s EPSG:27700 -t EPSG:3857 --spatial-test intersects -o PROJ
> > --single-line -q
> > (the option --spatial-test intersects is very important. Otherwise you
> > get a ballpark. I am not using grids. I can use the area of use of the
> > GeoTIFF as well) It produces
> > +proj=pipeline +step +inv +proj=tmerc +lat_0=49 +lon_0=-2
> > +k=0.9996012717 +x_0=40 +y_0=-10 +ellps=airy +step +proj=push
> > +v_3 +step +proj=cart +ellps=airy +step +proj=helmert +x=446.448
> > +y=-125.157 +z=542.06 +rx=0.15 +ry=0.247 +rz=0.842 +s=-20.489
> > +convention=position_vector +step +inv +proj=cart +ellps=WGS84 +step
> > +proj=pop +v_3 +step +proj=webmerc +lat_0=0 +lon_0=0 +x_0=0 +y_0=0
> > +ellps=WGS84
> >
> > However this pipeline does not work in gdal2tiles with the "-s"
> > option, complaining with these errors, and placing the data in the
> > wrong place (not very far from Null Island)
> > ERROR 1: PROJ: proj_crs_get_coordinate_system: Object is not a SingleCRS
> > ERROR 1: PROJ: proj_as_wkt: PROJBasedOperation can only be exported to
> > WKT2
> > ERROR 1: PROJ: proj_crs_get_coordinate_system: Object is not a SingleCRS
> > ERROR 1: PROJ: proj_as_wkt: PROJBasedOperation can only be exported to
> > WKT2
> This is expected. A coordinate operation is not a source CRS.
> >
> > Running projinfo on EPSG:27700 gives me the ballpark one
> > projinfo EPSG:27700 -o PROJ --single-line
> > PROJ.4 string:
> > +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40
> > +y_0=-10 +ellps=airy +units=m +no_defs +type=crs
> >
> > The difference using this pipeline (without Helmert parameters) is
> > about 100 m near London. Perfectly noticeable ;)
> >
> > (I think it does not include the Helmert transformation, because the
> > area of use of that transformation is a bit smaller than the
> > geographic crs, EPSG:4277)
> >
> > Of course I could create the command manually, but I would like to
> > have a generic solution for multiple projects.
> >
> > What can I do?
>
> Enhance gdal2tiles to be able to specify coordinate transformations:
> https://github.com/OSGeo/gdal/issues/3998
>
> You could also possibly use gdalwarp -ct to directly generate the input
> dataset in EPSG:3857 with the pipeline of your choice
>
> Or in that instance just use -s "+proj=tmerc +lat_0=49 +lon_0=-2
> +k=0.9996012717 +x_0=40 +y_0=-10 +ellps=airy +units=m +no_defs
>

Re: [gdal-dev] Process Sentinel-5p netCDF to tiff files but overlapping appears clearly between 2 files?

2021-11-15 Thread Bang Pham Huu

Could anyone comment for this problem?

Thanks,

On 11/8/21 1:09 PM, Bang Pham Huu wrote:
> Hello,
>
> I've used 2 Sentinel-5p scenes in hdf5 / netCDF to geoTiff by gdal
> version 2.2.4 like example below:
>
> First, I extract the lat and lon coordinates from one HDF5 file
>
>  gdal_translate -of VRT
> HDF5:"S5P_OFFL_L2__AER_AI_20210501T110005_20210501T124135_18388_01_010400_20210503T005051.nc"://PRODUCT/latitude
> lat.vrt
>  gdal_translate -of VRT
> HDF5:"S5P_OFFL_L2__AER_AI_20210501T110005_20210501T124135_18388_01_010400_20210503T005051.nc"://PRODUCT/longitude
> lon.vrt
>
> Then, I create the product.vrt like below
>
>     
>   
>     0
>     1
>     0
>     1
>     1
>      key="X_DATASET">/home/PROJECTS/Sentinel-5P/test_L2_AER_AI/lon.vrt
>     1
>      key="Y_DATASET">/home/PROJECTS/Sentinel-5P/test_L2_AER_AI/lat.vrt
>   
>   
>     
>   9.9692099683869e+36
>   7.78603750784e+35
>   -7.209698677063
>   2.6750402750247e+36
>     
>     
>    relativeToVRT="1">HDF5:S5P_OFFL_L2__AER_AI_20210501T110005_20210501T124135_18388_01_010400_20210503T005051.nc://PRODUCT/aerosol_index_340_380
>   1
>    DataType="Float32" BlockXSize="225" BlockYSize="1868" />
>   
>   
>     
>   
>     
>
> And finally, I extract the data inside the HDF5 to geoTiff and project
> it to EPSG:4326 CRS.
>
>     gdalwarp -geoloc -t_srs EPSG:4326 -srcnodata 9.96921e+36f
> product.vrt aerosol_index_340_380.tiff -tr 0.069 0.069 -tap -of GTiff
>
> I did that for 2 files which are neighbor to extract the wanted
> sub_dataset to tiff files and then opened them on QGIS.
>
> ** The image looks like below https://imgur.com/uu6pS5n
>
> ** The two extracted tiff files can be found from
> https://drive.google.com/drive/folders/1lOXyJXhhzmfs5e_WTsKPOj96CHEEIyhP?usp=sharing
>
> I wonder, why there are clear borders (the line in the middle) between
> the 2 overlapping files?
>
> Thanks,
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal2tiles EPSG:3857 Out of Memory

2021-11-15 Thread Rahkonen Jukka (MML)

Hi,

GDAL version 2.4.0 is not supported any more. I had a try with 3857.pdf with 
GDAL 3.1.7 and Python 3.7 by running
gdal2tiles -r average -z 12-18 3857.pdf

Process took 15 seconds with my Windows laptop. I guessed you meant -r average 
because -t antialias does not exist to my knowledge.

-Jukka Rahkonen-


Lähettäjä: gdal-dev  Puolesta 
pepijn.sze...@tractebel.engie.com
Lähetetty: maanantai 15. marraskuuta 2021 10.44
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] gdal2tiles EPSG:3857 Out of Memory

Dear all,

I assume this belongs to this mailing list instead of the GitHub Issues.
Find attached 2 pdf (plots from QGIS) of the same area, but plotted in 
EPSG:3857 and EPSG: 31370. (if attachments are not allowed: there is nothing 
special about what is on the pdf: it's simply 1 styled vector line and 1 
labelled vector point).
The pdf were checked with gdalinfo. Except for the CRS, I don't notice anything 
peculiar.

Notice this is still gdal 2.4.0. Due to company restrictions gdal 3 tiling runs 
awfully slow. Maybe the problem is however known to any of you.

Windows 10, python 2.7

Task:

  *   Running gdal2tiles on the pdf, with parameters:
 *   -r antialias
 *   -z 12-18
 *   -processes=30

Problem:

  *   EPSG 31370 runs fine, but due to reprojection labels are slightly rotated
  *   EPSG 3857 plot would fix the above, but for some reason gdal2tiles will 
not run on this. It barely starts. After waiting long enough error codes start 
showing in the CMD. The errors contain easily hundreds of line.
See below a small excerpt:

Out of memory
Out of memory
0Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
ERROR 2: Cannot allocate result buffer
ERROR 2: memdataset.cpp, 1541: cannot allocate 1x1048576 bytes
Out of memory
Out of memory
Out of memory
ERROR 1: Bitmap decoded size (1x1) doesn't match raster size (1024x1024)
ERROR 1: 
C:\Users\MyUser\AppData\Local\Temp\tmpj7_ghurm\e4a8f99b-98d8-4425-b6d1-6540ff951385.vrt,
 band 2: IReadBlock failed at X offset 5, Y offset 2: Bitmap decoded size (1x1) 
doesn't match raster size (1024x1024)
.Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
ERROR 1: 
C:\Users\MyUser\AppData\Local\Temp\tmpj7_ghurm\e4a8f99b-98d8-4425-b6d1-6540ff951385.vrt,
 band 1: IReadBlock failed at X offset 1, Y offset 4
10Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory



Any pointers?
Met vriendelijke groeten,
Pepijn SZEKÉR
Engineer - Transport Infrastructure
pepijn.sze...@tractebel.engie.com
M +32 499 61 25 58

[cid:image001.png@01D7DA16.53955430]



tractebel-engie.com

TRACTEBEL ENGINEERING S.A.
Ilgatlaan 23
3500 Hasselt - BELGIUM

VAT BE 0412 639 681 RPR/RPM Brussels
Please consider the environment before printing this document.

[cid:image003.png@01D7DA16.53955430]
  [cid:image004.png@01D7DA16.53955430]    
[cid:image005.png@01D7DA16.53955430] 
   
[cid:image006.png@01D7DA16.53955430] 



TRACTEBEL Privacy Statement: https://tractebel-engie.com/en/data-privacy

ENGIE Mail Disclaimer: http://www.engie.com/disclaimer/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdal2tiles EPSG:3857 Out of Memory

2021-11-15 Thread pepijn.szeker

Dear all,

I assume this belongs to this mailing list instead of the GitHub Issues.
Find attached 2 pdf (plots from QGIS) of the same area, but plotted in 
EPSG:3857 and EPSG: 31370. (if attachments are not allowed: there is nothing 
special about what is on the pdf: it's simply 1 styled vector line and 1 
labelled vector point).
The pdf were checked with gdalinfo. Except for the CRS, I don't notice anything 
peculiar.

Notice this is still gdal 2.4.0. Due to company restrictions gdal 3 tiling runs 
awfully slow. Maybe the problem is however known to any of you.

Windows 10, python 2.7

Task:

  *   Running gdal2tiles on the pdf, with parameters:
 *   -r antialias
 *   -z 12-18
 *   -processes=30

Problem:

  *   EPSG 31370 runs fine, but due to reprojection labels are slightly rotated
  *   EPSG 3857 plot would fix the above, but for some reason gdal2tiles will 
not run on this. It barely starts. After waiting long enough error codes start 
showing in the CMD. The errors contain easily hundreds of line.
See below a small excerpt:

Out of memory
Out of memory
0Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
ERROR 2: Cannot allocate result buffer
ERROR 2: memdataset.cpp, 1541: cannot allocate 1x1048576 bytes
Out of memory
Out of memory
Out of memory
ERROR 1: Bitmap decoded size (1x1) doesn't match raster size (1024x1024)
ERROR 1: 
C:\Users\MyUser\AppData\Local\Temp\tmpj7_ghurm\e4a8f99b-98d8-4425-b6d1-6540ff951385.vrt,
 band 2: IReadBlock failed at X offset 5, Y offset 2: Bitmap decoded size (1x1) 
doesn't match raster size (1024x1024)
.Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
ERROR 1: 
C:\Users\MyUser\AppData\Local\Temp\tmpj7_ghurm\e4a8f99b-98d8-4425-b6d1-6540ff951385.vrt,
 band 1: IReadBlock failed at X offset 1, Y offset 4
10Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory



Any pointers?
Met vriendelijke groeten,
Pepijn SZEKÉR
Engineer - Transport Infrastructure
pepijn.sze...@tractebel.engie.com
M +32 499 61 25 58

[cid:image001.png@01D7DA05.398D4450]



tractebel-engie.com

TRACTEBEL ENGINEERING S.A.
Ilgatlaan 23
3500 Hasselt - BELGIUM

VAT BE 0412 639 681 RPR/RPM Brussels
Please consider the environment before printing this document.

[cid:image004.png@01D7DA05.398D4450]
  [cid:image006.png@01D7DA05.398D4450]    
[cid:image008.png@01D7DA05.398D4450] 
   
[cid:image010.png@01D7DA05.398D4450] 



TRACTEBEL Privacy Statement: https://tractebel-engie.com/en/data-privacy

ENGIE Mail Disclaimer: http://www.engie.com/disclaimer/


3857.pdf
Description: 3857.pdf


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

[gdal-dev] gdal issue with libcurl

Re: [gdal-dev] Polar stereographic projection invalid definition ?

[gdal-dev] Polar stereographic projection invalid definition ?

Re: [gdal-dev] gdal2tiles and EPSG:27700

Re: [gdal-dev] Intermittent memory-corruption crashes in GRIB2 import

Re: [gdal-dev] gdal2tiles and EPSG:27700

Re: [gdal-dev] gdal2tiles and EPSG:27700

Re: [gdal-dev] Process Sentinel-5p netCDF to tiff files but overlapping appears clearly between 2 files?

Re: [gdal-dev] gdal2tiles EPSG:3857 Out of Memory

[gdal-dev] gdal2tiles EPSG:3857 Out of Memory

10 matches

Site Navigation

Mail list logo

Footer information