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> 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> *Puolesta *Michal > Kowalczuk via gdal-dev > *Lähetetty:* tiistai 10. syyskuuta 2024 15.15 > *Vastaanottaja:* 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> > 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
