[gdal-dev] WMS supported SRS

[Michał Kowalczuk]

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/67ac75a8/attachment.htm>