date:20211005

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

2021-10-05 Thread Pedro Venâncio

>
> So, the default will be the use of the operation with better accuracy,
> right?
>
> yes, due to the issue with the prime meridian, PROJ was confused and
> didn't find any valid operation with the appropriate area of use, and thus
> it fell back to an operation not using a grid
>
Perfect, thank you very much Even!

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

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

2021-10-05 Thread Even Rouault



Le 06/10/2021 à 01:26, Pedro Venâncio a écrit :

What a supersonic fix Even, thank you very much!!

So, the default will be the use of the operation with better accuracy, 
right?


yes, due to the issue with the prime meridian, PROJ was confused and 
didn't find any valid operation with the appropriate area of use, and 
thus it fell back to an operation not using a grid





Thanks Even!

Pedro



Even Rouault > escreveu no dia quarta, 6/10/2021 
à(s) 00:06:


This is a PROJ >= 7.2 bug, related to CRS with non-Greenwich prime
meridian. Fix in https://github.com/OSGeo/PROJ/pull/2884


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 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] GDAL/OGR coordinate transformations candidate operations priority

2021-10-05 Thread Pedro Venâncio

What a supersonic fix Even, thank you very much!!

So, the default will be the use of the operation with better accuracy,
right?

Thanks Even!

Pedro



Even Rouault  escreveu no dia quarta, 6/10/2021
à(s) 00:06:

> This is a PROJ >= 7.2 bug, related to CRS with non-Greenwich prime
> meridian. Fix in https://github.com/OSGeo/PROJ/pull/2884
>
> 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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

2021-10-05 Thread Even Rouault

This is a PROJ >= 7.2 bug, related to CRS with non-Greenwich prime 
meridian. Fix in https://github.com/OSGeo/PROJ/pull/2884


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] GDAL/OGR coordinate transformations candidate operations priority

2021-10-05 Thread Pedro Venâncio

Hi all,

I'm trying to understand what is the transformation used by default by
GDAL/OGR.

For instance, the transformation from EPSG:20790 to EPSG:3763 has two
candidates on PROJ:

C:\OSGeo4W>projinfo -s EPSG:20790 -t EPSG:3763
Candidate operations found: 2
-
Operation No. 1:

unknown id, Inverse of Portuguese National Grid + Lisbon (Lisbon) to Lisbon
(1) + Lisbon to ETRS89 (4) + Portugual TM06, 0.1 m, Portugal - mainland -
onshore.

PROJ string:
+proj=pipeline
  +step +inv +proj=tmerc +lat_0=39.7 +lon_0=1 +k=1 +x_0=20
+y_0=30 +ellps=intl +pm=lisbon
  +step +proj=hgridshift +grids=pt_dgt_DLx_ETRS89_geo.tif
  +step +proj=tmerc +lat_0=39.668258333 +lon_0=-8.133108 +k=1
+x_0=0
+y_0=0 +ellps=GRS80

WKT2:2019 string:
CONCATENATEDOPERATION["Inverse of Portuguese National Grid + Lisbon
(Lisbon) to Lisbon (1) + Lisbon to ETRS89 (4) + Portugual TM06",
SOURCECRS[
PROJCRS["Lisbon (Lisbon) / Portuguese National Grid",
BASEGEOGCRS["Lisbon (Lisbon)",
DATUM["Lisbon 1937 (Lisbon)",
ELLIPSOID["International 1924",6378388,297,
LENGTHUNIT["metre",1]]],
PRIMEM["Lisbon",-9.131906,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4803]],
CONVERSION["Portuguese National Grid",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",39.7,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",1,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",1,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",20,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",30,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
ID["EPSG",20790]]],
TARGETCRS[
PROJCRS["ETRS89 / Portugal TM06",
BASEGEOGCRS["ETRS89",
ENSEMBLE["European Terrestrial Reference System 1989
ensemble",
MEMBER["European Terrestrial Reference Frame 1989"],
MEMBER["European Terrestrial Reference Frame 1990"],
MEMBER["European Terrestrial Reference Frame 1991"],
MEMBER["European Terrestrial Reference Frame 1992"],
MEMBER["European Terrestrial Reference Frame 1993"],
MEMBER["European Terrestrial Reference Frame 1994"],
MEMBER["European Terrestrial Reference Frame 1996"],
MEMBER["European Terrestrial Reference Frame 1997"],
MEMBER["European Terrestrial Reference Frame 2000"],
MEMBER["European Terrestrial Reference Frame 2005"],
MEMBER["European Terrestrial Reference Frame 2014"],
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]],
ENSEMBLEACCURACY[0.1]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4258]],
CONVERSION["Portugual TM06",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",39.668258333,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",-8.133108,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",1,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",0,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",0,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting (X)",east,
ORDER[1],
LENGTHUNIT["metre",1]],
AXIS["northing (Y)",north,
ORDER[2],
LENGTHUNIT["metre",1]],
ID["EPSG",3763]]],
STEP[
CONVERSION["Inverse of Portuguese

Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create mosaics

2021-10-05 Thread Chastain, Raymond Lee (MU-Student)

Hi Brad,

We edited the VRT to remove the NODATA tags, we also tried "gdal_edit.py 
-unsetnodata", however we are still seeing the colored dot artifacts.

Could you please elaborate on what exactly you did that helped and if the dots 
were completely removed by that process?

Thanks again,
Raymond.

From: gdal-dev  on behalf of Chastain, 
Raymond Lee (MU-Student) 
Sent: Tuesday, October 5, 2021 3:13 PM
To: gdal-dev@lists.osgeo.org ; br...@frogmouth.net 

Subject: Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create 
mosaics

Thanks Brad,

I didn't notice your response as my e-mail system flagged it junk email.

We'll try this and report back with our findings.

Thank you again for the help,
Raymond.

From: Brad Hards 
Sent: Tuesday, September 28, 2021 7:21 PM
To: gdal-dev@lists.osgeo.org 
Cc: Chastain, Raymond Lee (MU-Student) 
Subject: Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create 
mosaics

WARNING: This message has originated from an External Source. This may be a 
phishing expedition that can result in unauthorized access to our IT System. 
Please use proper judgment and caution when opening attachments, clicking 
links, or responding to this email.

On Wednesday, 29 September 2021 9:37:57 AM AEST Chastain, Raymond Lee (MU-
Student) wrote:
> Process is very simple
>
>   1.  Take our tiles and build a virtual raster:
> gdalbuildvrt -r lanczos -resolution HIGHEST output.vrt -input_file_list
> input_file_list.txt 2.  Convert our virtual raster to a GeoTIFF:
>   3.  gdal_translate -of GTIFF ./output.vrt ./output.tif
I manually removed the NODATA part from the vrt, and it looks better. Possibly
the nodata value in the source is bad? Or you need to put something more
meaningful behind the images...

Brad

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

Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create mosaics

2021-10-05 Thread Chastain, Raymond Lee (MU-Student)

Thanks Brad,

I didn't notice your response as my e-mail system flagged it junk email.

We'll try this and report back with our findings.

Thank you again for the help,
Raymond.

From: Brad Hards 
Sent: Tuesday, September 28, 2021 7:21 PM
To: gdal-dev@lists.osgeo.org 
Cc: Chastain, Raymond Lee (MU-Student) 
Subject: Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create 
mosaics

WARNING: This message has originated from an External Source. This may be a 
phishing expedition that can result in unauthorized access to our IT System. 
Please use proper judgment and caution when opening attachments, clicking 
links, or responding to this email.

On Wednesday, 29 September 2021 9:37:57 AM AEST Chastain, Raymond Lee (MU-
Student) wrote:
> Process is very simple
>
>   1.  Take our tiles and build a virtual raster:
> gdalbuildvrt -r lanczos -resolution HIGHEST output.vrt -input_file_list
> input_file_list.txt 2.  Convert our virtual raster to a GeoTIFF:
>   3.  gdal_translate -of GTIFF ./output.vrt ./output.tif
I manually removed the NODATA part from the vrt, and it looks better. Possibly
the nodata value in the source is bad? Or you need to put something more
meaningful behind the images...

Brad

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

Re: [gdal-dev] How to access remote data that requires authentication?

2021-10-05 Thread Joaquim Manuel Freire Luís

Hmm, very tricky situations. Apparently from Julia things remain in memory and 
it remembers previous errors.

From a clean Juia REPL start this works (even with authentication)

julia> set_config_option("GDAL_HTTP_COOKIEFILE", joinpath(tempdir(), 
"cookies.txt"))
julia> set_config_option("GDAL_HTTP_COOKIEJAR", joinpath(tempdir(), 
"cookies.txt"))
julia> set_config_option("GDAL_DISABLE_READDIR_ON_OPEN","YES")
julia> set_config_option("CPL_VSIL_CURL_ALLOWED_EXTENSIONS","TIF")
julia> set_config_option("CPL_VSIL_CURL_USE_HEAD","FALSE")

gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
"Driver: GTiff/GeoTIFF\nFiles: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif\nSize
 is 3660, 3660\nCoordinate System is:\nPROJCRS[\"UTM Zone 10, Northern 
Hemisphere\",\nBASEGEOGCRS[\"Unknown datum based upon the WGS 84 
ellipsoid\",\nDATUM[\"Not_specified_based_on_WGS_84_spheroid\",\n …..

However, if run the gdalinfo(…) first and set the options after, then any 
posterior call to gdalinfo will return that “not supported file format” error.

In fact the errors evolve like this (after another clean start)

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 11: HTTP response code: 206

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'
 does not exist in the file system, and is not recognized as a supported 
dataset name.

From: Even Rouault 
Sent: Tuesday, October 5, 2021 8:11 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to access remote data that requires authentication?


There are a few historically exported VSIInstaller symbols, but 
VSIInstallCurlFileHandler is never exported. None of those symbols need to be 
explicitly called as GDAL will automatically register the builtin-handlers. 
Perhaps your gdal.dll lacks curl support ? I assumed you pass the needed config 
options / env variables for that service. Perhaps you could try with something 
simpler that doesn't require authentication.
Le 05/10/2021 à 21:05, Joaquim Manuel Freire Luís a écrit :
Even, sorry to continue this.

Now is from Julia

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'
 not recognized as a supported file format.

I saw a reference to VSIInstallCurlFileHandler() so I thought “right I need 
this guy too” but when I try to install it

julia> GMT.Gdal.VSIInstallCurlFileHandler()
ERROR: could not load symbol "VSIInstallCurlFileHandler":
The specified procedure could not be found.

And indeed my gdal.dll has a couple of VSIInstaller symbols but not this one 
(nor zip, gzip and others).

Is the “not supported file format” related to this? Shouldn’t that symbol be 
exported to the dll?


From: gdal-dev 
 On 
Behalf Of Joaquim Manuel Freire Luís
Sent: Tuesday, October 5, 2021 5:59 PM
To: Even Rouault 
; 
gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to access remote data that requires authentication?


>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where MS decides 
is my home dir (and all the hidden dirs stuff that it puts there) and always 
have had a home at “HOME=c:\j” and it’s there that libcurl (I presume) seeks 
for the netrc file.

Thanks for all the tips. But I still wonder how GMT manages to read the file 
without anything of this.



For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt

Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",



Regarding authentication issues, this service is quite annoying and requires 
enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html

You need to add things like --config GDAL_HTTP_COOKIEFILE /tmp/cookies.txt 
--config GDAL_HTTP_COOKIEJAR /tmp/cookies.txt
Le 05/10/2021 à 18:20, Joaquim

Re: [gdal-dev] How to access remote data that requires authentication?

2021-10-05 Thread Even Rouault

There are a few historically exported VSIInstaller symbols, but 
VSIInstallCurlFileHandler is never exported. None of those symbols need 
to be explicitly called as GDAL will automatically register the 
builtin-handlers. Perhaps your gdal.dll lacks curl support ? I assumed 
you pass the needed config options / env variables for that service. 
Perhaps you could try with something simpler that doesn't require 
authentication.


Le 05/10/2021 à 21:05, Joaquim Manuel Freire Luís a écrit :


Even, sorry to continue this.

Now is from Julia

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)


ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif' 
not recognized as a supported file format.


I saw a reference to VSIInstallCurlFileHandler() so I thought “right I 
need this guy too” but when I try to install it


julia> GMT.Gdal.VSIInstallCurlFileHandler()

ERROR: could not load symbol "VSIInstallCurlFileHandler":

The specified procedure could not be found.

And indeed my gdal.dll has a couple of VSIInstaller symbols but not 
this one (nor zip, gzip and others).


Is the “not supported file format” related to this? Shouldn’t that 
symbol be exported to the dll?


*From:*gdal-dev  *On Behalf Of 
*Joaquim Manuel Freire Luís

*Sent:* Tuesday, October 5, 2021 5:59 PM
*To:* Even Rouault ; gdal-dev@lists.osgeo.org
*Subject:* Re: [gdal-dev] How to access remote data that requires 
authentication?


>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where 
MS decides is my home dir (and all the hidden dirs stuff that it puts 
there) and always have had a home at “HOME=c:\j” and it’s there that 
libcurl (I presume) seeks for the netrc file.


Thanks for all the tips. But I still wonder how GMT manages to read 
the file without anything of this.


For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif 
--config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE 
c:/TEMP/cookies.txt --config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt


Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif


Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",

Regarding authentication issues, this service is quite annoying and 
requires enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html 



You need to add things like /--config GDAL_HTTP_COOKIEFILE 
/tmp/cookies.txt --config GDAL_HTTP_COOKIEJAR /tmp/cookies.txt/


Le 05/10/2021 à 18:20, Joaquim Manuel Freire Luís a écrit :

OK, tried more things from that thread.

gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
  

  --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE

* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc 
file; using defaults ...

OK, right it's not there.

But latter down it says

* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using 
defaults

Now this is not right.

< HTTP/1.1 401 Unauthorized

...

< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. If you 
do not have a Earthdata Login, create one athttps://urs.earthdata.nasa.gov//users/new  
"

...

ERROR 11: HTTP response code: 401

So I'm back to the Authentication problem. I do have an _netrc file (and 
.netrc btw) in my home dir as well as current dir but it does seem to find it. 
Is there something else that I must to in order to that file be found/used?

-Original Message-

From: thomas bonfort    


Sent: Tuesday, October 5, 2021 4:31 PM

To: Joaquim Manuel Freire Luís  

Subject: Re: [gdal-dev] How to access remote data that requires 
authentication?

for the 206 there seems to be a similar issue posted here a few days ago, search for 
"Problem accessing NASA Cloud Optimized GeoTIFF data"

in the archives

On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís  
  wrote:

you should also change your password, now you have posted it on a

public mailing

Re: [gdal-dev] How to access remote data that requires authentication?

2021-10-05 Thread Joaquim Manuel Freire Luís

Even, sorry to continue this.

Now is from Julia

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'
 not recognized as a supported file format.

I saw a reference to VSIInstallCurlFileHandler() so I thought “right I need 
this guy too” but when I try to install it

julia> GMT.Gdal.VSIInstallCurlFileHandler()
ERROR: could not load symbol "VSIInstallCurlFileHandler":
The specified procedure could not be found.

And indeed my gdal.dll has a couple of VSIInstaller symbols but not this one 
(nor zip, gzip and others).

Is the “not supported file format” related to this? Shouldn’t that symbol be 
exported to the dll?


From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Tuesday, October 5, 2021 5:59 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to access remote data that requires authentication?


>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where MS decides 
is my home dir (and all the hidden dirs stuff that it puts there) and always 
have had a home at “HOME=c:\j” and it’s there that libcurl (I presume) seeks 
for the netrc file.

Thanks for all the tips. But I still wonder how GMT manages to read the file 
without anything of this.



For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt

Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",



Regarding authentication issues, this service is quite annoying and requires 
enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html

You need to add things like --config GDAL_HTTP_COOKIEFILE /tmp/cookies.txt 
--config GDAL_HTTP_COOKIEJAR /tmp/cookies.txt
Le 05/10/2021 à 18:20, Joaquim Manuel Freire Luís a écrit :

OK, tried more things from that thread.



gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE



* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...

OK, right it's not there.



But latter down it says



* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults



Now this is not right.



< HTTP/1.1 401 Unauthorized

...

< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. 
If you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new"

...

ERROR 11: HTTP response code: 401





So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?



-Original Message-

From: thomas bonfort 

Sent: Tuesday, October 5, 2021 4:31 PM

To: Joaquim Manuel Freire Luís 

Subject: Re: [gdal-dev] How to access remote data that requires authentication?



for the 206 there seems to be a similar issue posted here a few days ago, 
search for "Problem accessing NASA Cloud Optimized GeoTIFF data"

in the archives



On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís 
 wrote:





you should also change your password, now you have posted it on a

public mailing list :/



Shit, thanks for spotting it.



But it doesn't work with /vsicur/ neither (had tried it  before). Now

the error is  206



gdalinfo

/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected

/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

ERROR 11: HTTP response code: 206





On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís 
 wrote:



Hi,







I’ve read a lot of the docs, tried many -co options but can’t get through this 
mystery.







I can access the data through GMT, which uses GDAL to do this job,

but can’t do it with GDAL directly







gdalinfo

https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30

.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif



ERROR 1: HTTP error code : 401



gdalinfo failed - unable to open

Re: [gdal-dev] How to access remote data that requires authentication?

2021-10-05 Thread Joaquim Manuel Freire Luís

>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where MS decides 
is my home dir (and all the hidden dirs stuff that it puts there) and always 
have had a home at “HOME=c:\j” and it’s there that libcurl (I presume) seeks 
for the netrc file.

Thanks for all the tips. But I still wonder how GMT manages to read the file 
without anything of this.



For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt

Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",



Regarding authentication issues, this service is quite annoying and requires 
enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html

You need to add things like --config GDAL_HTTP_COOKIEFILE /tmp/cookies.txt 
--config GDAL_HTTP_COOKIEJAR /tmp/cookies.txt
Le 05/10/2021 à 18:20, Joaquim Manuel Freire Luís a écrit :

OK, tried more things from that thread.



gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE



* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...

OK, right it's not there.



But latter down it says



* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults



Now this is not right.



< HTTP/1.1 401 Unauthorized

...

< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. 
If you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new"

...

ERROR 11: HTTP response code: 401





So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?



-Original Message-

From: thomas bonfort 

Sent: Tuesday, October 5, 2021 4:31 PM

To: Joaquim Manuel Freire Luís 

Subject: Re: [gdal-dev] How to access remote data that requires authentication?



for the 206 there seems to be a similar issue posted here a few days ago, 
search for "Problem accessing NASA Cloud Optimized GeoTIFF data"

in the archives



On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís 
 wrote:





you should also change your password, now you have posted it on a

public mailing list :/



Shit, thanks for spotting it.



But it doesn't work with /vsicur/ neither (had tried it  before). Now

the error is  206



gdalinfo

/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected

/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

ERROR 11: HTTP response code: 206





On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís 
 wrote:



Hi,







I’ve read a lot of the docs, tried many -co options but can’t get through this 
mystery.







I can access the data through GMT, which uses GDAL to do this job,

but can’t do it with GDAL directly







gdalinfo

https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30

.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif



ERROR 1: HTTP error code : 401



gdalinfo failed - unable to open 
'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.







So passing longin:password via url does not work either. But it does

if indirectly used







grdinfo

https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30

.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via

GDAL



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration

used [Cartesian grid]



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd =

Import/export through GDAL



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max:

609780 x_inc: 30 name: x n_columns: 3660



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max:

450 y_inc: 30 name: y n_rows: 3660



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max:

0.8833 name: z

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Greg Troxel

Even Rouault  writes:

> For most packaging system, the set of dependencies available at build
> time is fully controlled by the package requirements. We can assume
> that whatever if available is wished to be used, and ideally a plain
> "cmake .." should automatically find what is available. And if the
> packager properly enumerates its build-time and run-time dependencies,
> that should work.

Generally yes, but the main mechanism is constructing include/lib paths
so that #include, -l and pkgconfig files of things that aren't declared
are not found.  So the cmake build ideally would be trying to
include/link to test if libraries are present, similar to how autoconf
does, rather than reaching out to the filesystem directly to look for
specific files.   But if there's a foo=no equivalent to --disable-foo,
it's not that hard.

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

Re: [gdal-dev] How to access remote data that requires authentication?

2021-10-05 Thread Even Rouault


The mention to _netrc is weird...

Regarding authentication issues, this service is quite annoying and 
requires enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html


You need to add things like /--config GDAL_HTTP_COOKIEFILE 
/tmp/cookies.txt --config//GDAL_HTTP_COOKIEJAR /tmp/cookies.txt/


Le 05/10/2021 à 18:20, Joaquim Manuel Freire Luís a écrit :

OK, tried more things from that thread.

gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE

* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...
OK, right it's not there.

But latter down it says

* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults

Now this is not right.

< HTTP/1.1 401 Unauthorized
...
< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. If 
you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new;
...
ERROR 11: HTTP response code: 401


So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?

-Original Message-
From: thomas bonfort 
Sent: Tuesday, October 5, 2021 4:31 PM
To: Joaquim Manuel Freire Luís 
Subject: Re: [gdal-dev] How to access remote data that requires authentication?

for the 206 there seems to be a similar issue posted here a few days ago, search for 
"Problem accessing NASA Cloud Optimized GeoTIFF data"
in the archives

On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís  wrote:


you should also change your password, now you have posted it on a
public mailing list :/

Shit, thanks for spotting it.

But it doesn't work with /vsicur/ neither (had tried it  before). Now
the error is  206

gdalinfo
/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected
/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
ERROR 11: HTTP response code: 206


On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís  wrote:

Hi,



I’ve read a lot of the docs, tried many -co options but can’t get through this 
mystery.



I can access the data through GMT, which uses GDAL to do this job,
but can’t do it with GDAL directly



gdalinfo
https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30
.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

ERROR 1: HTTP error code : 401

gdalinfo failed - unable to open 
'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.



So passing longin:password via url does not work either. But it does
if indirectly used



grdinfo
https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30
.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via
GDAL

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration
used [Cartesian grid]

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd =
Import/export through GDAL

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max:
609780 x_inc: 30 name: x n_columns: 3660

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max:
450 y_inc: 30 name: y n_rows: 3660

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max:
0.8833 name: z

HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: scale_factor: 0.0001
add_offset: 0 packed z-range: [-149,8833]

+proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs



Joaquim

___
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


--
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] How to access remote data that requires authentication?

2021-10-05 Thread Joaquim Manuel Freire Luís

OK, tried more things from that thread.

gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE 

* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...
OK, right it's not there.

But latter down it says

* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults

Now this is not right.

< HTTP/1.1 401 Unauthorized
...
< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. 
If you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new;
...
ERROR 11: HTTP response code: 401


So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?

-Original Message-
From: thomas bonfort  
Sent: Tuesday, October 5, 2021 4:31 PM
To: Joaquim Manuel Freire Luís 
Subject: Re: [gdal-dev] How to access remote data that requires authentication?

for the 206 there seems to be a similar issue posted here a few days ago, 
search for "Problem accessing NASA Cloud Optimized GeoTIFF data"
in the archives

On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís  wrote:
>
>
> you should also change your password, now you have posted it on a 
> public mailing list :/
>
> Shit, thanks for spotting it.
>
> But it doesn't work with /vsicur/ neither (had tried it  before). Now 
> the error is  206
>
> gdalinfo 
> /vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected
> /HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
> ERROR 11: HTTP response code: 206
>
>
> On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís  
> wrote:
> >
> > Hi,
> >
> >
> >
> > I’ve read a lot of the docs, tried many -co options but can’t get through 
> > this mystery.
> >
> >
> >
> > I can access the data through GMT, which uses GDAL to do this job, 
> > but can’t do it with GDAL directly
> >
> >
> >
> > gdalinfo
> > https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30
> > .0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
> >
> > ERROR 1: HTTP error code : 401
> >
> > gdalinfo failed - unable to open 
> > 'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.
> >
> >
> >
> > So passing longin:password via url does not work either. But it does 
> > if indirectly used
> >
> >
> >
> > grdinfo
> > https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30
> > .0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via 
> > GDAL
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration 
> > used [Cartesian grid]
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd = 
> > Import/export through GDAL
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max:
> > 609780 x_inc: 30 name: x n_columns: 3660
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max:
> > 450 y_inc: 30 name: y n_rows: 3660
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max:
> > 0.8833 name: z
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: scale_factor: 0.0001
> > add_offset: 0 packed z-range: [-149,8833]
> >
> > +proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs
> >
> >
> >
> > Joaquim
> >
> > ___
> > 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] HTTP range request retrying?

2021-10-05 Thread Even Rouault


Hi Sean,

The code for retry of range requests of regions of data is at 
https://github.com/OSGeo/gdal/blob/master/gdal/port/cpl_vsil_curl.cpp#L1602 
. It indeed looks like there's no test for that. You might file an issue 
about adding one.


Side node: it might become a maintenance burden on rasterio if you test 
such low level implementation detail of GDAL, especially if you test 
like we do which exact requests are done and in which order, if we 
change at some later point how requests are done


Even

Le 05/10/2021 à 17:44, Sean Gillies via gdal-dev a écrit :

Hi all,

In writing some rasterio tests I am able to get GDAL to retry head 
requests for a vsicurl dataset, but am unable to trigger retries for 
range requests to regions of the data. I don't recognize any tests for 
range request retrying in or near 
https://github.com/OSGeo/gdal/blob/master/autotest/gcore/vsicurl.py#L473 
. 
Do we intend to support this or is it a missing feature?


--
Sean Gillies

___
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

[gdal-dev] HTTP range request retrying?

2021-10-05 Thread Sean Gillies via gdal-dev

Hi all,

In writing some rasterio tests I am able to get GDAL to retry head requests
for a vsicurl dataset, but am unable to trigger retries for range requests
to regions of the data. I don't recognize any tests for range request
retrying in or near
https://github.com/OSGeo/gdal/blob/master/autotest/gcore/vsicurl.py#L473.
Do we intend to support this or is it a missing feature?

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

Re: [gdal-dev] How to access remote data that requires authentication?

2021-10-05 Thread thomas bonfort

you need to use /vsicurl/ :

gdalinfo 
/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

--
thomas

On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís  wrote:
>
> Hi,
>
>
>
> I’ve read a lot of the docs, tried many -co options but can’t get through 
> this mystery.
>
>
>
> I can access the data through GMT, which uses GDAL to do this job, but can’t 
> do it with GDAL directly
>
>
>
> gdalinfo 
> https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
>
> ERROR 1: HTTP error code : 401
>
> gdalinfo failed - unable to open 
> 'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.
>
>
>
> So passing longin:password via url does not work either. But it does if 
> indirectly used
>
>
>
> grdinfo 
> https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via GDAL
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration used 
> [Cartesian grid]
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd = 
> Import/export through GDAL
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max: 609780 
> x_inc: 30 name: x n_columns: 3660
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max: 450 
> y_inc: 30 name: y n_rows: 3660
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max: 0.8833 
> name: z
>
> HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: scale_factor: 0.0001 add_offset: 
> 0 packed z-range: [-149,8833]
>
> +proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs
>
>
>
> Joaquim
>
> ___
> 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 access remote data that requires authentication?

2021-10-05 Thread Joaquim Manuel Freire Luís

Hi,

I've read a lot of the docs, tried many -co options but can't get through this 
mystery.

I can access the data through GMT, which uses GDAL to do this job, but can't do 
it with GDAL directly

gdalinfo 
https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
ERROR 1: HTTP error code : 401
gdalinfo failed - unable to open 
'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.

So passing longin:password via url does not work either. But it does if 
indirectly used

grdinfo 
https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via GDAL
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration used 
[Cartesian grid]
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd = 
Import/export through GDAL
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max: 609780 x_inc: 
30 name: x n_columns: 3660
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max: 450 
y_inc: 30 name: y n_rows: 3660
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max: 0.8833 name: z
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: scale_factor: 0.0001 add_offset: 0 
packed z-range: [-149,8833]
+proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs

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

Re: [gdal-dev] gdal 3.3.3RC1

2021-10-05 Thread Even Rouault

If we'd do a release each time, we fix an issue, we'd do a release each 
day :-)


Use qgis-dev + gdal-dev from OSGeo4W, or you can workaround the issue by 
removing the "set VSI_CACHE=TRUE" line from the qgis.bat launcher.


Le 05/10/2021 à 16:14, Nicolas Godet a écrit :


Dear GDAL developpers,

As describe in this QGIS issue 
(https://github.com/qgis/QGIS/issues/45293 
), losing network access 
during a QGIS instance cause a crash and can lead to a data loss.


This issue was solved in the gdal PR 
(https://github.com/OSGeo/gdal/pull/4561 
) and I wonder if it could be 
possible to create a release candidate of 3.3.3 version ?
3.3.3 is due by October 25 and next QGIS release 3.22.0 by October 22. 
So we will have to wait for QGIS 3.22.1 which for November 19.
Combined with a DELL issue on our laptop (network interruption during 
idle…), we increase the chance of data loss…


Regards

Nicolas

___
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

[gdal-dev] gdal 3.3.3RC1

2021-10-05 Thread Nicolas Godet

Dear GDAL developpers,



As describe in this QGIS issue (https://github.com/qgis/QGIS/issues/45293), 
losing network access during a QGIS instance cause a crash and can lead to a 
data loss.

This issue was solved in the gdal PR (https://github.com/OSGeo/gdal/pull/4561) 
and I wonder if it could be possible to create a release candidate of 3.3.3 
version ?
3.3.3 is due by October 25 and next QGIS release 3.22.0 by October 22. So we 
will have to wait for QGIS 3.22.1 which for November 19.
Combined with a DELL issue on our laptop (network interruption during idle…), 
we increase the chance of data loss…



Regards

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

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Even Rouault




I guess that means that an option for builders to configuring drivers as
builtin / plugin / not included
is out of scope (not present in current system).
If someone is going through all the drivers it might make sense to
do this at the same time, or at least design things so that
only a central change is needed to enable it for all drivers ?

The main objective is to reach reasonable-enough feature parity, but 
that'll certainly be the oppurtunity to add new capabilities.


What you mention is something I've in mind, and cmake4gdal has already 
existing functions to control how/which drivers are built: 
https://github.com/miurahr/cmake4gdal/blob/master/helpers/GdalDriverHelper.cmake


It will certainly require some further tunings. There are also some 
complications like drivers that depend on other drivers, so it might not 
be practical for all drivers.



--
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] Not able to use gdal_translate and a TMS source

2021-10-05 Thread andy

You are right, I don't have to drink beer in the afternoon:)

Thank you very much

On Tue, 5 Oct 2021 at 15:57, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> There is not so much wrong, you should just read
> https://gdal.org/drivers/raster/wms.html more carefully and write server
> URL this way:
>
>
>
>   https://tiles.wmflabs.org/osm-no-labels/${z}/${x}/${y}.png
> 
>
>
>
> -Jukka Rahkonen-
>
>
>
>
>
>
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *andy
> *Lähetetty:* tiistai 5. lokakuuta 2021 16.42
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] Not able to use gdal_translate and a TMS source
>
>
>
> Hi,
>
> in QGIS I have set this XYZ source:
> https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png
>
> QGIS renders it properly.
>
>
>
> I have created this GDAL source
>
>
>
> 
> 
> https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png
> 
> 
> 
> -20037508.34
> 20037508.34
> 20037508.34
> -20037508.34
> 18
> 1
> 1
> top
> 
> EPSG:900913
> 256
> 256
> 3
> 
> 204,404
> 
>
>
>
> But if run
>
>
>
> gdal_translate --debug ON -of PNG -projwin 5203413 2847209 5221042 2829459
> -outsize 512 512 osm-no-labels.xml openstreetmap.png
>
>
>
> I have a black PNG.
>
>
>
> The debug shows me a wrong HTTP call (the below one), but I do not know
> how to modify my xml source to be able to run right requests.
>
>
>
> HTTP: Request [1]
> https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png/1.0.0//12/2580/1758.jpg
> 
>
>
>
> What's wrong in my settings?
>
>
>
> Thank you
>
>
>
> --
>
> ___
>
>
>
> Andrea Borruso
> website: https://medium.com/tantotanto
> 38° 7' 48" N, 13° 21' 9" E, EPSG:4326
> ___
>
> "cercare e saper riconoscere chi e cosa,
>  in mezzo all’inferno, non è inferno,
> e farlo durare, e dargli spazio"
>
> Italo Calvino
>


-- 
___

Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

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

Re: [gdal-dev] Not able to use gdal_translate and a TMS source

2021-10-05 Thread Rahkonen Jukka (MML)

Hi,

There is not so much wrong, you should just read 
https://gdal.org/drivers/raster/wms.html more carefully and write server URL 
this way:

  
https://tiles.wmflabs.org/osm-no-labels/${z}/${x}/${y}.png

-Jukka Rahkonen-




Lähettäjä: gdal-dev  Puolesta andy
Lähetetty: tiistai 5. lokakuuta 2021 16.42
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Not able to use gdal_translate and a TMS source

Hi,
in QGIS I have set this XYZ source: 
https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png
QGIS renders it properly.

I have created this GDAL source




https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png


-20037508.34
20037508.34
20037508.34
-20037508.34
18
1
1
top

EPSG:900913
256
256
3

204,404


But if run

gdal_translate --debug ON -of PNG -projwin 5203413 2847209 5221042 2829459 
-outsize 512 512 osm-no-labels.xml openstreetmap.png

I have a black PNG.

The debug shows me a wrong HTTP call (the below one), but I do not know how to 
modify my xml source to be able to run right requests.

HTTP: Request [1] 
https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png/1.0.0//12/2580/1758.jpg

What's wrong in my settings?

Thank you

--
___

Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

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

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Even Rouault

Le 05/10/2021 à 15:24, Javier Jimenez Shaw a écrit :
I also accept some included by default, that can be disabled with an 
option. But never silently depending on what is installed.

autoconf builds largely automatically uses installed things when they 
are in standard locations. That's the practice of most other projects, 
which is very convenient, and that should be kept. The only requirement 
for GDAL is PROJ, but if you don't have libcurl, libexpat, etc., you 
loose a lot of functionality, and requiring users to list all them would 
be painful.

For most packaging system, the set of dependencies available at build 
time is fully controlled by the package requirements. We can assume that 
whatever if available is wished to be used, and ideally a plain "cmake 
.." should automatically find what is available. And if the packager 
properly enumerates its build-time and run-time dependencies, that 
should work.

People can explicitly disable a dependency they don't want. We could 
perhaps have some option to disable everything by default, and require 
explicit activation in use cases where people want full control, but 
that shouldn't be the default behavior.

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

On Tue, 5 Oct 2021 at 15:11, Greg Troxel > wrote:

Javier Jimenez Shaw mailto:j...@jimenezshaw.com>> writes:

> How would CMake behave with all those options that are defined
depending on
> what is present on the compiler machine?
>
> IMHO, the libraries included should be independent on what is
already
> installed on the compiler machine. The last time something/somebody
> included "zstd" in our compiler machine, and not in the
executing machine,
> and we couldn't run anything. We did not need zstd, but it was
there,
> breaking the execution. I know that the solution there is disable it
> "--without-zstd". What I do not like is the lack of definition,
because
> what is present on the compiler machine may change.

I agree that is is best for a build to hard-require what is
required and
decline to use things that are not required.   I don't think this
issue
is any different autoconf vs cmake.

--
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] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Andrew C Aitchison


On Mon, 4 Oct 2021, Even Rouault wrote:


Please find at https://github.com/OSGeo/gdal/pull/4590 a RFC that proposes:

- to develop a CMake build system, officially integrated in the source tree.

- and remove the current GNU makefiles and nmake build systems, when the 
CMake build system has matured enough and reached feature parity.


I guess that means that an option for builders to configuring drivers as
builtin / plugin / not included
is out of scope (not present in current system).
If someone is going through all the drivers it might make sense to
do this at the same time, or at least design things so that
only a central change is needed to enable it for all drivers ?

--
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] Not able to use gdal_translate and a TMS source

2021-10-05 Thread andy

Hi,
in QGIS I have set this XYZ source:
https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png
QGIS renders it properly.

I have created this GDAL source



https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png



-20037508.34
20037508.34
20037508.34
-20037508.34
18
1
1
top

EPSG:900913
256
256
3

204,404


But if run

gdal_translate --debug ON -of PNG -projwin 5203413 2847209 5221042 2829459
-outsize 512 512 osm-no-labels.xml openstreetmap.png

I have a black PNG.

The debug shows me a wrong HTTP call (the below one), but I do not know how
to modify my xml source to be able to run right requests.

HTTP: Request [1]
https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png/1.0.0//12/2580/1758.jpg

What's wrong in my settings?

Thank you

-- 
___

Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

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

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Javier Jimenez Shaw

I also accept some included by default, that can be disabled with an
option. But never silently depending on what is installed.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Tue, 5 Oct 2021 at 15:11, Greg Troxel  wrote:

>
> Javier Jimenez Shaw  writes:
>
> > How would CMake behave with all those options that are defined depending
> on
> > what is present on the compiler machine?
> >
> > IMHO, the libraries included should be independent on what is already
> > installed on the compiler machine. The last time something/somebody
> > included "zstd" in our compiler machine, and not in the executing
> machine,
> > and we couldn't run anything. We did not need zstd, but it was there,
> > breaking the execution. I know that the solution there is disable it
> > "--without-zstd". What I do not like is the lack of definition, because
> > what is present on the compiler machine may change.
>
> I agree that is is best for a build to hard-require what is required and
> decline to use things that are not required.   I don't think this issue
> is any different autoconf vs cmake.
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Javier Jimenez Shaw

How would CMake behave with all those options that are defined depending on
what is present on the compiler machine?

IMHO, the libraries included should be independent on what is already
installed on the compiler machine. The last time something/somebody
included "zstd" in our compiler machine, and not in the executing machine,
and we couldn't run anything. We did not need zstd, but it was there,
breaking the execution. I know that the solution there is disable it
"--without-zstd". What I do not like is the lack of definition, because
what is present on the compiler machine may change.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.

On Tue, 5 Oct 2021 at 14:51, Greg Troxel  wrote:

>
> Even Rouault  writes:
>
> > Please find at https://github.com/OSGeo/gdal/pull/4590 a RFC that
> proposes:
> >
> > - to develop a CMake build system, officially integrated in the source
> tree.
> >
> > - and remove the current GNU makefiles and nmake build systems, when
> > the CMake build system has matured enough and reached feature parity.
>
> I added a comment that requirements should be stated and gave a first
> cut at them.  My big problem with cmake from packaging is that people
> write CMakefile code with OS-specific tests instead of feature tests and
> then packagers have to add lots of patches that add OS names to
> conditionals.  So the requireents should ban that practice in favor of
> feature tests.
>
> The other big comment is that "matured enough" is not just for what the
> project can test on CI, but the entire packaging world, so I included
> having a formal release with cmake where autoconf is marked deprecated
> for packagers to try to make work, so those issues can be fixed before a
> release without autoconf.  I get it that the project has CI for what
> they have, but I don't think that requirements should be driven by what
> CI exists.
>
> I'm willing to test on alpha/beta/rc; I can create a
> separate/work-in-progress package that is gdal alpha built with cmake,
> to flush out these things.
>
>
>
>
> ___
> 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] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Greg Troxel


Javier Jimenez Shaw  writes:

> How would CMake behave with all those options that are defined depending on
> what is present on the compiler machine?
>
> IMHO, the libraries included should be independent on what is already
> installed on the compiler machine. The last time something/somebody
> included "zstd" in our compiler machine, and not in the executing machine,
> and we couldn't run anything. We did not need zstd, but it was there,
> breaking the execution. I know that the solution there is disable it
> "--without-zstd". What I do not like is the lack of definition, because
> what is present on the compiler machine may change.

I agree that is is best for a build to hard-require what is required and
decline to use things that are not required.   I don't think this issue
is any different autoconf vs cmake.


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

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread Greg Troxel

Even Rouault  writes:

> Please find at https://github.com/OSGeo/gdal/pull/4590 a RFC that proposes:
>
> - to develop a CMake build system, officially integrated in the source tree.
>
> - and remove the current GNU makefiles and nmake build systems, when
> the CMake build system has matured enough and reached feature parity.

I added a comment that requirements should be stated and gave a first
cut at them.  My big problem with cmake from packaging is that people
write CMakefile code with OS-specific tests instead of feature tests and
then packagers have to add lots of patches that add OS names to
conditionals.  So the requireents should ban that practice in favor of
feature tests.

The other big comment is that "matured enough" is not just for what the
project can test on CI, but the entire packaging world, so I included
having a formal release with cmake where autoconf is marked deprecated
for packagers to try to make work, so those issues can be fixed before a
release without autoconf.  I get it that the project has CI for what
they have, but I don't think that requirements should be driven by what
CI exists.

I'm willing to test on alpha/beta/rc; I can create a
separate/work-in-progress package that is gdal alpha built with cmake,
to flush out these things.

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

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

2021-10-05 Thread thomas bonfort

> And really, I should make those smaller.  I know that some of the required 
> formats are required mostly for autotest.  I'd be be interested in working on 
> getting the minimum footprint down once things are switched to CMake.

The autotools build already supports minimal builds, with the list of
mandatory formats being:

gdalinfo --formats
Supported Formats:
  VRT -raster,multidimensional raster- (rw+v): Virtual Raster
  DERIVED -raster- (ro): Derived datasets using VRT pixel functions
  GTiff -raster- (rw+vs): GeoTIFF
  COG -raster- (wv): Cloud optimized GeoTIFF generator
  HFA -raster- (rw+v): Erdas Imagine Images (.img)
  JPEG -raster- (rwv): JPEG JFIF
  MEM -raster,multidimensional raster- (rw+): In Memory Raster
(JPEG could also technically be removed but I've kept it here for jpeg-in-tiff)

ogrinfo --formats
Supported Formats:
  MapInfo File -vector- (rw+v): MapInfo File
  OGR_VRT -vector- (rov): VRT - Virtual Datasource
  Memory -vector- (rw+): Memory
  KML -vector- (rw+v): Keyhole Markup Language (KML)
  GeoJSON -vector- (rw+v): GeoJSON
  GeoJSONSeq -vector- (rw+v): GeoJSON Sequence
  ESRIJSON -vector- (rov): ESRIJSON
  TopoJSON -vector- (rov): TopoJSON
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

Re: [gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

[gdal-dev] GDAL/OGR coordinate transformations candidate operations priority

Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create mosaics

Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create mosaics

Re: [gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] HTTP range request retrying?

[gdal-dev] HTTP range request retrying?

Re: [gdal-dev] How to access remote data that requires authentication?

[gdal-dev] How to access remote data that requires authentication?

Re: [gdal-dev] gdal 3.3.3RC1

[gdal-dev] gdal 3.3.3RC1

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] Not able to use gdal_translate and a TMS source

Re: [gdal-dev] Not able to use gdal_translate and a TMS source

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

[gdal-dev] Not able to use gdal_translate and a TMS source

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

31 matches

Site Navigation

Mail list logo

Footer information