[gdal-dev] WMS supported SRS

Tue Sep 10 08:05:11 PDT 2024

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.rahkonen at 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.
> 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 <michkowalczuk at gmail.com>
> *Lähetetty:* tiistai 10. syyskuuta 2024 16.32
> *Vastaanottaja:* Rahkonen Jukka <jukka.rahkonen at maanmittauslaitos.fi>
> *Kopio:* gdal-dev at 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.rahkonen at 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-bounces at lists.osgeo.org> *Puolesta *Michal
> Kowalczuk via gdal-dev
> *Lähetetty:* tiistai 10. syyskuuta 2024 15.15
> *Vastaanottaja:* gdal-dev at 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 <michkowalczuk at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240910/d877e8af/attachment.htm>