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 <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 <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> 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> 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
