[gdal-dev] WMS supported SRS

Tue Sep 10 08:06:50 PDT 2024

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 <michkowalczuk at 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.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/014e530d/attachment-0001.htm>