>
> 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
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 appro
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
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.osg
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
-
Op
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.
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
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_HTT
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 conf
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.
>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)
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
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_
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
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 ras
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/autotes
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 -
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.20
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,
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 b
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 cent
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 carefull
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
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 prac
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 matu
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
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, G
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, an
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
> i
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 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
31 matches
Mail list logo
