We’ve already set it back to the traditional axis order but that code snip
wasn’t included. I had forgotten about that change we had to make to keep our
existing code as is. I think the differences would be drastically different
otherwise, but we are seeing differences that are mostly in the 5
To partially appease the crowd, the data provider has since acknowledged
the issue on their end and are working on a fix - thankfully not one of
those providers that take a month to respond with a shrug.
Cheers,
Daniel
On Tue, 10 Sept 2024 at 16:11, thomas bonfort
wrote:
> I'm not sure that p
I'm not sure that providing a fix to work around this very broken behavior
is the best way of action to make them fix their server...
On Tue, Sep 10, 2024 at 5:07 PM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> Le 10/09/2024 à 16:10, Rahkonen Jukka via gdal-dev a écrit :
>
> H
A sample from your link:
*Rakennustietoruudukko_2017Rakennustietoruudukko
2017Tietoa rakennuksista 250 x 250m ruudukoissa
pääkaupunkiseudullafeaturesRakennustietoruudukko_2017EPSG:3879CRS:8424.5011280244855425.2584917846646660.05226532402916560.39874702231777polygo
Ok, now I see the problem. Thank you Jukka for the explanation with a
sample.
So maybe we can use information from *BoundingBox*?
and generate SUBDATASETS for each combination of Layer and BoundingBox
definition that is usually defined for "best"/dedicated projections for a
layer.
*(7.2.4.6.8 )*
Le 10/09/2024 à 16:10, Rahkonen Jukka via gdal-dev a écrit :
Hi,
Have you tried with configuration option
“CPL_VSIL_CURL_USE_HEAD=[YES/NO]: Defaults to YES. Controls whether to
use a HEAD request when opening a remote URL.”
I was just going to suggest that too. It "works", but not really.
Hi Jukka,
It seems your documentation search skills are better than mine! That does
the trick.
Cheers,
Daniel
On Tue, 10 Sept 2024 at 15:10, Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Hi,
>
>
>
> Have you tried with configuration option “CPL_VSIL_CURL_USE_HEAD=[YES/NO]:
> De
Hi,
Have you tried with configuration option "CPL_VSIL_CURL_USE_HEAD=[YES/NO]:
Defaults to YES. Controls whether to use a HEAD request when opening a remote
URL."
-Jukka Rahkonen-
Lähettäjä: gdal-dev Puolesta Daniel Evans
via gdal-dev
Lähetetty: tiistai 10. syyskuuta 2024 16.57
Vastaanottaja
Hi
* I meant to use CRSs only reported by GetCapabilities. I haven't seen that
GetCapabilities returns so many (6782) possible projections...
I was meaning the same, CRSs reported in GetCapabilities. I used a search
engine with phrase "service=WMS&version=1.3.0" and found in three minutes
Hi all,
I am attempting to read a dataset via /vsicurl/ where I believe the server
is incorrectly returning `content-length: 0` in response to HEAD requests.
This causes GDAL to believe it's a zero-length file, and it therefore can't
be read.
If I download the file via HTTP GET, it's valid, and G
That's why I favor Even's option to introduce open option
LIST_ALL_SRS=YES/NO.
Or any other solution that simplify the process of choosing layer in the
specified SRS, e.g. dedicated function that returns list of supported SRS
like in WFS...?
wt., 10 wrz 2024 o 15:31 Michał Kowalczuk
napisał(a)
Thank you for your feedback. My comments are below:
*It means that there are tens of thousands WMS services which support 6782
different projections for each layer (checked from Geoserver version
2.25.3). I would not like them all to be reported as subdatasets.*
I meant to use CRSs only reported
Hi,
WMTS typically supports a rather small number of tilematrices and tiles are
usually cached, so it makes a lot of sense to advertise the available matrices
and utilize them. On the other hand WMS maps are created on-the-fly and there
is very low technical cost on the server side to support h
Michał,
Le 10/09/2024 à 14:14, Michał Kowalczuk via gdal-dev a écrit :
I found that there was a similar issue in 2021 without any specific
answer:
https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg35549.html
I wonder if getting SUBDATASETS shouldn't return the result in a
similar way a
I found that there was a similar issue in 2021 without any specific answer:
https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg35549.html
I wonder if getting SUBDATASETS shouldn't return the result in a similar
way as it does for WMTS service,
where GDAL generates paths to all layer/tilematr
15 matches
Mail list logo