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> 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 <michkowalc...@gmail.com> > *Lähetetty:* tiistai 10. syyskuuta 2024 16.32 > *Vastaanottaja:* Rahkonen Jukka <jukka.rahko...@maanmittauslaitos.fi> > *Kopio:* 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> 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
