> I believe that I used http url directly after reading some QGIS tutorial
> that suggested that /vsicurl/ is no more needed.
Depends on use cases. If you need to process the whole file and that it can
fit in RAM, then direct http[s:]// without /vsicurl might be slightly faster.
> You are right
+1 for both
Thank you Even!
On Wed, 8 Jan 2020 at 14:07, Even Rouault wrote:
>
> Hi,
>
> Both announcement of availability of release candidates and motions to adopt
> them.
>
> MOT1: Adopt GDAL 3.0.3 RC1 as final 3.0.3 release
>
> +1 Even
>
> MOT2: Adopt GDAL 2.4.4 RC1 as final 2.4.4 release
>
+1 for both
-Jukka Rahkonen-
Even Rouault-2 wrote
> Hi,
>
> Both announcement of availability of release candidates and motions to
> adopt
> them.
>
> MOT1: Adopt GDAL 3.0.3 RC1 as final 3.0.3 release
>
> +1 Even
>
> MOT2: Adopt GDAL 2.4.4 RC1 as final 2.4.4 release
>
> +1 Even
>
> ~
Tested 2.4.4 RC1 here with VisualStudio 2017, works well.
+1 jeff
On 2020-01-08 9:07 AM, Even Rouault wrote:
Hi,
Both announcement of availability of release candidates and motions to adopt
them.
MOT1: Adopt GDAL 3.0.3 RC1 as final 3.0.3 release
+1 Even
MOT2: Adopt GDAL 2.4.4 RC1 as fin
Thanks (as always!) Even for the quick response and good resources.
For posterity, that is osr, not ogr:
in_crs.SetAxisMappingStrategy(osr.OAMS_TRADITIONAL_GIS_ORDER)
It also seems to impacts CRSs imported from WKT and PROJ4, not just from EPSG
as indicated in the release note.
Benjamin
-O
Hi,
The real issue appears to be in my usage of direct http url instead of using
vsicurl in between.
This takes a few seconds for me on Windows with GDAL 3.1.0dev
gdalinfo /vsicurl/http://latuviitta.kapsi.fi/data/jarvi_dem/saimaa_dem.tif
but this takes more than five minutes
gdalinfo http://latu
On mercredi 8 janvier 2020 12:27:56 CET Vincent Sarago wrote:
> Hi Jukka,
> The time you are seeing is related to your configuration and not
> specifically to the file itself.
>
> If you set `GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR` in your env, you’ll see
> that gdalinfo will be much faster.
The
Hi Jukka,
The time you are seeing is related to your configuration and not specifically
to the file itself.
If you set `GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR` in your env, you’ll see
that gdalinfo will be much faster.
```
$ time GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR gdalinfo
/vsicurl/http:
Hi,
Cloud optimized GeoTIFF is rather fast for almost anything else but not for
checking what it is with gdalinfo. I wonder if we could have some "summary
only" mode in gdalinfo that reads just what is known to be fast to read from
the image metadata. What gdalinfo is actually doing when it spe
Perfect. 6 sec now to read that file
1st thanks of 2020
Joaquim
-Original Message-
From: Even Rouault
Sent: Tuesday, January 7, 2020 7:09 PM
To: gdal-dev@lists.osgeo.org
Cc: Joaquim Manuel Freire Luís ; Paul Wessel
Subject: Re: [gdal-dev] Slow GDALComputeRasterMinMax on nc grids
On v
> > I've just added a DATE_AS_STRING=YEs open option for such situations:
> > https://github.com/OSGeo/gdal/commit/3a7914cee018d5b65dc1639368edbd8faac2543d
After further thought, I'm wondering about the name of the new option.
This is just about reading GeoJSON, right? If so, then I think a name
Wow, that was fast! This looks great.
Many thanks,
Keith
On Tue, Jan 7, 2020 at 4:35 PM Even Rouault wrote:
>
> > ... ogr2ogr converts the identifiers to "3000\/02\/31" and "2000\/01\/01".
> >
> > Is there any way to preserve the original formatting of these strings?
>
> I've just added a DATE_
Hi,
Both announcement of availability of release candidates and motions to adopt
them.
MOT1: Adopt GDAL 3.0.3 RC1 as final 3.0.3 release
+1 Even
MOT2: Adopt GDAL 2.4.4 RC1 as final 2.4.4 release
+1 Even
~
3.0.3 RC1:
Peek up an archive among the following ones (by ascending size):
htt
13 matches
Mail list logo
