[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