Hi,
Not my catch really, I was reading
https://gis.stackexchange.com/questions/485416/is-the-ilike-operator-in-qgis-not-working-correctly
-Jukka-
Lähettäjä: gdal-dev Puolesta Even Rouault
via gdal-dev
Lähetetty: lauantai 31. elokuuta 2024 1.48
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re:
good catch. Fixed in
https://github.com/OSGeo/gdal/commit/9b1ab02e7b8cb5504cb65cacb287bc717ccee3f7
Le 31/08/2024 à 00:37, Rahkonen Jukka via gdal-dev a écrit :
Hi,
The documentation of the SQLite dialect
https://gdal.org/en/latest/user/sql_sqlite_dialect.html#like-operator
can make user bel
Hi,
The documentation of the SQLite dialect
https://gdal.org/en/latest/user/sql_sqlite_dialect.html#like-operator can make
user believe that the dialect supports ILIKE operator since GDAL version 3.9
but that is not true. Maybe that is a copy-paste error in
https://github.com/OSGeo/gdal/commit
Understood. Thank you.
On Fri, Aug 30, 2024 at 2:54 PM Even Rouault
wrote:
> I can't think of other formats with similar behavior right now, but you
> shouldn't trust my memory. That said, reported block sizes might very well
> change with versions. Like in JPEG2000 drivers where heuristics to
>
I can't think of other formats with similar behavior right now, but you
shouldn't trust my memory. That said, reported block sizes might very
well change with versions. Like in JPEG2000 drivers where heuristics to
determine which block size to expose may be tuned, although this hasn't
changed m
Thank you, Even.
Does that whole-image optimization only apply to PNG? I mean, obviously
that particular build option is PNG-specific, but are there other formats
which might exhibit similar differences in presented block size? If it's
just PNG, I'm not worried, as there aren't many geospatial PNG
Simon,
One is the declared block size of a simple RGB PNG image, which we use
for some raster import tests. The image is 320x225 and gdalinfo on x86
reports that for the block size of the three bands also. However, on
ARM it reports the block sizes as 320x1.
Yes, this is expected, as on x86
Dear List,
We are in the process of creating an ARM build of our system, and we have
discovered some differences in GDAL behavior between the two.
One is the declared block size of a simple RGB PNG image, which we use for
some raster import tests. The image is 320x225 and gdalinfo on x86 reports
- When debugging *gdal_translate *I noticed that both gdal_translate and
GDALRasterIO chose tilematrix=22 (*WMTS: Using tilematrix=22 (zoom level
22)*
- The difference is in the next log line:
- gdal_translate uses XML as argument for GdalOpen:
*HTTP:
Fetch(https://basemap
Hi,
I do not know either, I am not a programmer. I have used sometimes a local
proxy server for capturing the http traffic. With gdal_translate the http
requests are printed when the command is run with -- debug on. It would
probably be good to run gdal_translate with -ovr NONE
https://gdal.or
Full GDAL log attached.
Sorry, but I do not know how to test your suggestion. GDAL logger creates
some caches and I do not know which http request i should use...
Thanks, Michał
pt., 30 sie 2024 o 09:23 Rahkonen Jukka
napisał(a):
> Hi,
>
>
>
> Capture and show the http request that your code ge
Hi,
Capture and show the http request that your code generates and sends to the
WMTS server. Does it work if you send the same request with curl or with a
browser? Or does the error come before the GetTile request is generated?
-Jukka Rahkonen-
Lähettäjä: Michał Kowalczuk
Lähetetty: perjantai
Sorry for incorrect sample commands in the last message.
I fixed it. The problem stays the same, because the problem was in email
not in my tested code.
*gdal_translate -srcwin 0 0 1073741760 1553779 -outsize 691 1
"WMTS:https://basemap.nationalmap.gov/arcgis/rest/services/USGSHydroCached/MapServer
13 matches
Mail list logo
