Hi, Have you tried to use the URL without &TILED=TRUE? That vendor option is meant for clients like OpenLayers so that they can get cacheable tiles from standard GeoServer WMS https://geoserver-pdf.readthedocs.io/en/latest/services/wms/vendor.html
That such tiling and metatiling can work the requests must have a certain width and height. For regular WMS clients it is better not to use &TILED=TRUE. -Jukka Rahkonen- -----Alkuperäinen viesti----- Lähettäjä: gdal-dev <gdal-dev-boun...@lists.osgeo.org> Puolesta Elena Ruiz Lähetetty: maanantai 14. helmikuuta 2022 17.42 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Error InvalidTile when download a WMS Hello, I'm trying to download a WMS image using gdla_translate from a server in Sweden: http://kartor.stockholm.se/bios/wms/app/baggis/web/WMS_STHLM_ORTOFOTO_2020, with EPSG:3011 (attached xml ) , but it returns me this error, I've searched the internet, but I can't find any entry that refers to it, could someone tell me what this error means and how I could solve it, thanks >gdal_translate -of JPEG "C:\Users\elena\AppData\Local\Temp\tmpnuevo.xml" >"C:\Users\elena\AppData\Local\Temp\prueba.jpg" Input file size is 766, 577 0ERROR 1: GDALWMS: The server returned exception code 'InvalidTile': Width(254) differs from tile width(256) ERROR 1: C:\Users\elena\AppData\Local\Temp\tmpnuevo.xml, band 1: IReadBlock failed at X offset 0, Y offset 0: GDALWMS: The server returned exception code 'InvalidTile': Width(254) differs from tile width(256) Regards, -----Mensaje original----- De: gdal-dev <gdal-dev-boun...@lists.osgeo.org> En nombre de gdal-dev-requ...@lists.osgeo.org Enviado el: domingo, 12 de septiembre de 2021 18:24 Para: gdal-dev@lists.osgeo.org Asunto: gdal-dev Digest, Vol 208, Issue 17 Send gdal-dev mailing list submissions to gdal-dev@lists.osgeo.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osgeo.org/mailman/listinfo/gdal-dev or, via email, send a message with subject or body 'help' to gdal-dev-requ...@lists.osgeo.org You can reach the person managing the list at gdal-dev-ow...@lists.osgeo.org When replying, please edit your Subject line so it is more specific than "Re: Contents of gdal-dev digest..." Today's Topics: 1. Get error handler user data when removing CPL Error Handler (Rajsekar Manokaran) 2. Re: Get error handler user data when removing CPL Error Handler (Even Rouault) 3. Re: Get error handler user data when removing CPL Error Handler (Rajsekar Manokaran) 4. Re: Get error handler user data when removing CPL Error Handler (Sean Gillies) ---------------------------------------------------------------------- Message: 1 Date: Sun, 12 Sep 2021 19:33:10 +0530 From: Rajsekar Manokaran <rajse...@gmail.com> To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] Get error handler user data when removing CPL Error Handler Message-ID: <ca+4cnmgzsoakzi_ove9k7skbrukpwskciapag0ndl5j-zpb...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, In the gdal rust bindings (https://github.com/georust/gdal), we're trying to facilitate the use of CPLSetErrorHandlerEx and related APIs. While setting a handler, we may pass a heap allocated data pointer to the second argument, which is then read via the CPLGetErrorHandlerUserData in the handler and passed to the user. However, while removing or setting another handler, we're unable to find a race-free method to get the associated user data of the previous handler. This is needed to properly deallocate the memory. Is there an atomic way to get both the previous handler (as returned by CPLSetErrorHandler), along with the associated user data? The issue with making two calls, is that another thread might make changes in between the two calls. We could synchronize in our API, but it still has the same issue if the user parallely used the C APIs directly or via a different interface. Relevant PR in rust gdal bindings: https://github.com/georust/gdal/pull/215 - Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210912/695f9a37/attachment-0001.html> ------------------------------ Message: 2 Date: Sun, 12 Sep 2021 16:12:19 +0200 From: Even Rouault <even.roua...@spatialys.com> To: Rajsekar Manokaran <rajse...@gmail.com>, gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Get error handler user data when removing CPL Error Handler Message-ID: <0637288e-2945-443c-5f02-39f318003...@spatialys.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi, no there's no thread safe API to do what you want. You'd need a new function CPLErrorHandler CPLSetErrorHandlerEx2( CPLErrorHandler pfnErrorHandlerNew, void* pUserData, void** ppOldUserData ) to do that. But as you mention threads that might compete to set an error handler, using CPLSetErrorHandlerEx() is probably not the best strategy. You'd be better with CPLPushErrorHandler() / CPLPopErrorHandler() that only affects the current thread. Even Le 12/09/2021 ? 16:03, Rajsekar Manokaran a ?crit?: > Hi, > > In the gdal rust bindings (https://github.com/georust/gdal > <https://github.com/georust/gdal>), we're trying to facilitate the use > of CPLSetErrorHandlerEx and related APIs.? While setting a handler, we > may pass a heap allocated data pointer to the second argument, which > is then read via the CPLGetErrorHandlerUserData in the handler and > passed to the user. > > However, while removing or setting another handler, we're unable to > find a race-free method to get the associated user data of the > previous handler.?? This is needed to properly deallocate the memory. > > Is there an atomic way to get both the previous handler (as returned > by CPLSetErrorHandler), along with the associated user data?? The > issue with making two calls, is that another thread might make changes > in between the two calls. > > We could synchronize in our API, but it still has the same issue if > the user parallely used the C APIs directly or via a different interface. > > Relevant PR in rust gdal bindings: > https://github.com/georust/gdal/pull/215 > <https://github.com/georust/gdal/pull/215> > > - > Regards > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- 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/20210912/a1407600/attachment-0001.html> ------------------------------ Message: 3 Date: Sun, 12 Sep 2021 20:34:26 +0530 From: Rajsekar Manokaran <rajse...@gmail.com> To: Even Rouault <even.roua...@spatialys.com> Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Get error handler user data when removing CPL Error Handler Message-ID: <ca+4cnmfrafbr+xg-jhanpde6am9d7pknl87znyzet-tuva_...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Thanks for the clarification! The API you suggest would indeed be quite convenient. We do intend to support the thread local variants too, but wanted to see how much we can support the global one. - Regards On Sun, Sep 12, 2021 at 7:42 PM Even Rouault <even.roua...@spatialys.com> wrote: > Hi, > > no there's no thread safe API to do what you want. You'd need a new > function > > CPLErrorHandler CPLSetErrorHandlerEx2( CPLErrorHandler > pfnErrorHandlerNew, > void* pUserData, void** ppOldUserData ) > > to do that. > > But as you mention threads that might compete to set an error handler, > using CPLSetErrorHandlerEx() is probably not the best strategy. You'd > be better with CPLPushErrorHandler() / CPLPopErrorHandler() that only > affects the current thread. > > Even > Le 12/09/2021 ? 16:03, Rajsekar Manokaran a ?crit : > > Hi, > > In the gdal rust bindings (https://github.com/georust/gdal), we're > trying to facilitate the use of CPLSetErrorHandlerEx and related APIs. > While setting a handler, we may pass a heap allocated data pointer to > the second argument, which is then read via the > CPLGetErrorHandlerUserData in the handler and passed to the user. > > However, while removing or setting another handler, we're unable to > find a race-free method to get the associated user data of the previous > handler. > This is needed to properly deallocate the memory. > > Is there an atomic way to get both the previous handler (as returned > by CPLSetErrorHandler), along with the associated user data? The > issue with making two calls, is that another thread might make changes > in between the two calls. > > We could synchronize in our API, but it still has the same issue if > the user parallely used the C APIs directly or via a different interface. > > Relevant PR in rust gdal bindings: > https://github.com/georust/gdal/pull/215 > > - > Regards > > > _______________________________________________ > gdal-dev mailing > listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/g > dal-dev > > -- 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/20210912/6a64af4d/attachment-0001.html> ------------------------------ Message: 4 Date: Sun, 12 Sep 2021 10:23:15 -0600 From: Sean Gillies <s...@mapbox.com> To: gdal dev <gdal-dev@lists.osgeo.org> Subject: Re: [gdal-dev] Get error handler user data when removing CPL Error Handler Message-ID: <cadphzxzuzfj4kg+nbrh_+jki9auahuebjm2ee8ruis4ttc5...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, For what it's worth, In the Python package named rasterio we're using the push/pop API: https://github.com/mapbox/rasterio/blob/master/rasterio/_env.pyx#L336. While Rust's needs may differ, a single handler without any support for user data works well for Python: everything goes to the logging infrastructure, one of the kind of globals that Howard refers to in https://github.com/OSGeo/gdal/blob/master/gdal/doc/source/development/rfc/rfc37_cplerror_userdata.rst#rationale, and Python developers extend the logger if they want behavior that is different from the basic defaults. On Sun, Sep 12, 2021 at 8:12 AM Even Rouault <even.roua...@spatialys.com> wrote: > Hi, > > no there's no thread safe API to do what you want. You'd need a new > function > > CPLErrorHandler CPLSetErrorHandlerEx2( CPLErrorHandler > pfnErrorHandlerNew, > void* pUserData, void** ppOldUserData ) > > to do that. > > But as you mention threads that might compete to set an error handler, > using CPLSetErrorHandlerEx() is probably not the best strategy. You'd > be better with CPLPushErrorHandler() / CPLPopErrorHandler() that only > affects the current thread. > > Even > Le 12/09/2021 ? 16:03, Rajsekar Manokaran a ?crit : > > Hi, > > In the gdal rust bindings (https://github.com/georust/gdal), we're > trying to facilitate the use of CPLSetErrorHandlerEx and related APIs. > While setting a handler, we may pass a heap allocated data pointer to > the second argument, which is then read via the > CPLGetErrorHandlerUserData in the handler and passed to the user. > > However, while removing or setting another handler, we're unable to > find a race-free method to get the associated user data of the previous > handler. > This is needed to properly deallocate the memory. > > Is there an atomic way to get both the previous handler (as returned > by CPLSetErrorHandler), along with the associated user data? The > issue with making two calls, is that another thread might make changes > in between the two calls. > > We could synchronize in our API, but it still has the same issue if > the user parallely used the C APIs directly or via a different interface. > > Relevant PR in rust gdal bindings: > https://github.com/georust/gdal/pull/215 > > - > Regards > > -- Sean Gillies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210912/cef13953/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ------------------------------ End of gdal-dev Digest, Vol 208, Issue 17 ***************************************** _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
