Hi,

Your suggestion to utilize the additional layer BBOXes if they exist feels good 
to me, and better than to use the first advertised SRS from the root level. 
Beyond that what can be done with parsing the GetCapabilities is limited in my 
mind, because all projections which are supported may not be useful in real 
life.

-Jukka Rahkonen-

Lähettäjä: Michał Kowalczuk <michkowalc...@gmail.com>
Lähetetty: torstai 12. syyskuuta 2024 14.35
Vastaanottaja: Rahkonen Jukka <jukka.rahko...@maanmittauslaitos.fi>
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] WMS supported SRS

So we remain at the point that there is no good method that, using only GDAL, 
will allow to fully use the WMS service without additional work related to XML 
parsing...?

Best,
Michał Kowalczuk

wt., 10 wrz 2024 o 17:06 Michał Kowalczuk 
<michkowalc...@gmail.com<mailto:michkowalc...@gmail.com>> napisał(a):
A sample from your link:
<Layer queryable="1" opaque="0">
<Name>Rakennustietoruudukko_2017</Name>
<Title>Rakennustietoruudukko 2017</Title>
<Abstract>Tietoa rakennuksista 250 x 250m ruudukoissa 
pääkaupunkiseudulla</Abstract>
<KeywordList>
<Keyword>features</Keyword>
<Keyword>Rakennustietoruudukko_2017</Keyword>
</KeywordList>
<CRS>EPSG:3879</CRS>
<CRS>CRS:84</CRS>
<EX_GeographicBoundingBox>
<westBoundLongitude>24.50112802448554</westBoundLongitude>
<eastBoundLongitude>25.25849178466466</eastBoundLongitude>
<southBoundLatitude>60.052265324029165</southBoundLatitude>
<northBoundLatitude>60.39874702231777</northBoundLatitude>
</EX_GeographicBoundingBox>
<BoundingBox CRS="CRS:84" minx="24.50112802448554" miny="60.052265324029165" 
maxx="25.25849178466466" maxy="60.39874702231777"/>
<BoundingBox CRS="EPSG:3879" minx="6659998.5" miny="2.5472498E7" 
maxx="6698499.5" maxy="2.551425E7"/>
<Style>
<Name>polygon</Name>
<Title>Default polygon style</Title>
<Abstract>A sample style that just draws out a solid gray interior with a black 
1px outline</Abstract>
<LegendURL width="20" height="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"; xlink:type="simple" 
xlink:href="https://kartta.hsy.fi/geoserver/asuminen_ja_maankaytto/ows?service=WMS&version=1.3.0&request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Rakennustietoruudukko_2017"/>
</LegendURL>
</Style>
</Layer>

wt., 10 wrz 2024 o 17:05 Michał Kowalczuk 
<michkowalc...@gmail.com<mailto:michkowalc...@gmail.com>> napisał(a):
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 )
A Layer may have multiple BoundingBox elements, but each one shall state a 
different CRS (...)
A Layer shall not provide a BoundingBox for a CRS it does not support. 
Conversely, a Layer may support CRSs
for which it does not provide a BoundingBox: a server that has the ability to 
transform data to different CRSs may
choose not to provide an explicit BoundingBox for every possible CRS available 
for each Layer. The server
should provide BoundingBox information for at least the native CRS of the Layer 
(that is, the CRS in which the
Layer is stored in the server's database).

Best,
Michał

W dniu wt., 10.09.2024 o 16:07 Rahkonen Jukka 
<jukka.rahko...@maanmittauslaitos.fi<mailto:jukka.rahko...@maanmittauslaitos.fi>>
 napisał(a):
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 many 
examples, including this one 
kartta.hsy.fi/geoserver/asuminen_ja_maankaytto/ows?service=WMS&version=1.3.0&request=GetCapabilities<https://kartta.hsy.fi/geoserver/asuminen_ja_maankaytto/ows?service=WMS&version=1.3.0&request=GetCapabilities>.
 If you want to see more, install Geoserver on your computer and have a look at 
the default GetCapabilities.

Finding the best CRS from WMS GetCapabilities is guesswork. The server above is 
a Finnish one so probably EPSG:3067 is the most native CRS because that is what 
we tend to use in Finland. However, there is also one and only one additional 
BBOX for EPSG:3879 in GetCapabilities, but that would be somewhat odd selection 
for a country-wide CRS. It is also possible that for example some CRS of New 
Zealand does not really work in GetMap of the Finnish data even GetCapabilities 
says it will. But when WMS is configured to show a short CRS list then I would 
trust that they are all good to use. Just be aware that the list can also be 
very long.

If you start implementing the LIST_ALL_SRS option, it should be noted that the 
service level CRS list applies to all layers, and each layer can add more CRSs 
to the list. Maybe in theory there could be even "crs-list-of-service-root + 
crs-list-of-group-layer + crs-list-of-child-layer".

"7.2.4.6.7 CRS
Every Layer is available in one or more layer coordinate reference systems. 
6.7.3 discusses the Layer CRS. In
order to indicate which Layer CRSs are available, every named Layer shall have 
at least one <CRS> element that
is either stated explicitly or inherited from a parent Layer. The root <Layer> 
element shall include a sequence of
zero or more CRS elements listing all CRSs that are common to all subsidiary 
layers. A child layer may optionally
add to the list inherited from a parent layer. Any duplication shall be ignored 
by clients.
When a Layer is available in several coordinate reference systems, the list of 
available CRS values shall be
represented as a sequence of <CRS> elements, each of which contains only a 
single CRS name."

-Jukka Rahkonen-




Lähettäjä: Michał Kowalczuk 
<michkowalc...@gmail.com<mailto:michkowalc...@gmail.com>>
Lähetetty: tiistai 10. syyskuuta 2024 16.32
Vastaanottaja: Rahkonen Jukka 
<jukka.rahko...@maanmittauslaitos.fi<mailto:jukka.rahko...@maanmittauslaitos.fi>>
Kopio: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

Aihe: Re: [gdal-dev] WMS supported SRS

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 by GetCapabilities. I haven't seen that 
GetCapabilities returns so many (6782) possible projections...

WMS standard also does not define any default CRS and the first one on the list 
in GetCapabilities does not need to be the best.
Therefore, the current form of the generating subdatasets names method for WMS 
driver is even more useless, if we have a non-default (not the best) projection 
for the data.

And the only good way to work with it is to parse XML and generate paths 
manually...

That's why I favor Even's option to introduce open option LIST_ALL_SRS=YES/NO.

Any more thoughts?

Michał Kowalczuk

wt., 10 wrz 2024 o 15:03 Rahkonen Jukka 
<jukka.rahko...@maanmittauslaitos.fi<mailto:jukka.rahko...@maanmittauslaitos.fi>>
 napisał(a):
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 however many 
projections. WMS standard also does not define any default CRS and the first 
one on the list in GetCapabilities does not need to be the best.

I guess that Geoserver is the most common WMS server in the world and amazingly 
many Geoservers run with the default settings. 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 can see that ogrinfo and the OGC API Features driver report the list of 
supported projections. Test with ogrinfo 
OAPIF:https://ogc-api.nrw.de/inspire-us-feuerwehr -al -so shows "Supported SRS: 
OGC:CRS84, EPSG:25832, EPSG:25833, EPSG:4258, EPSG:4326, EPSG:3395, EPSG:3857, 
EPSG:3034, EPSG:3035"
Something similar might be an option for gdalinfo, but still about 6782 EPSG 
codes per layer is too much to be viewed by default. Maybe the CRS list could 
be reported under some metadata domain that user could read on demand?

-Jukka Rahkonen-









Lähettäjä: gdal-dev 
<gdal-dev-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Michal Kowalczuk via gdal-dev
Lähetetty: tiistai 10. syyskuuta 2024 15.15
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: Re: [gdal-dev] WMS supported SRS

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/tilematrix/tilematrixset combination.
For example if layer is available in 3 SRS, GDAL produces 3 subdatasets, so 
using only SUBDATASE_NAME property user has access to all map services shared 
by WMTS server.
In my opinion, GDAL should use the same approach for WMS.

Does anyone object?
I will then submit a new feature request/bug report.

Best regards and have a nice day
Michał Kowalczuk

pon., 9 wrz 2024 o 16:17 Michał Kowalczuk 
<michkowalc...@gmail.com<mailto:michkowalc...@gmail.com>> napisał(a):
Hi,
Does GDAL provides a method to get supported spatial reference systems by WMS 
service?
GDALGetMetadata(SUBDATASETS) generate links only for the first (default) SRS 
from GetCapabilities, so this won't be helpful.
Working with WFS I can get supported SRS using OGR OGR_L_GetSupportedSRSList 
function.
Does GDAL offers something similar for WMS, or should I get this information 
from GetCapabilities XML by myself?

Regards,
Michal
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to