[gdal-dev] WMS supported SRS

Even Rouault even.rouault at spatialys.com
Thu Sep 19 07:30:51 PDT 2024


Le 19/09/2024 à 15:59, Michał Kowalczuk via gdal-dev a écrit :
> Hi,
> After re-thinking this topic, I also came to conclusion that using 
> BoundingBox tags will not be a satisfactory solution for GDAL users. 
> Maybe it will better than current, but still poor...
> In my opinion the most flexible solution is to provide a list of 
> supported SRSs by a server, just like in *OGR_L_GetSupportedSRSList 
> for WFS.*
> Then add a helper function to generate a valid path for chosen layer 
> (subdataset), SRS from the list, and providing reprojection of 
> bounding box if needed (as Jukka suggested in last message in last 
> sentence).
> This ensures users to use the full capabilities of the server.

I would suggest adding 2 new virtual methods, something like:

- const GetSupportedSRSListRetType& 
GetSupportedSRSListRetTypeGDALDaset::GetSupportedSRSList()

- std::unique_ptr<GDALDataset> GDALDataset::OpenWithActiveSRS(const 
OGRSpatialReference* poSRS)

The later acts in a different way than OGRLayer::SetActiveSRS(), which 
modifies the active object. For rasters, changing the active SRS changes 
a lot of other proprerties (width, height, geotransform, etc. etc.) 
which are assumed for some of them to be immutable during the life-time 
of an object. So it is probably better to return a new dataset, and I 
suspect would make implementations in most candidate drivers easier.

Cf https://github.com/OSGeo/gdal/pull/6872 where 
OGRLayer::GetSupportedSRSList() was implemented, as a potential source 
of inspiration

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240919/86502eaf/attachment.htm>


More information about the gdal-dev mailing list