[gdal-dev] Error InvalidTile when download a WMS
Rahkonen Jukka (MML)
jukka.rahkonen at maanmittauslaitos.fi
Mon Feb 14 12:33:01 PST 2022
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-bounces at lists.osgeo.org> Puolesta Elena Ruiz
Lähetetty: maanantai 14. helmikuuta 2022 17.42
Vastaanottaja: gdal-dev at 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-bounces at lists.osgeo.org> En nombre de gdal-dev-request at lists.osgeo.org Enviado el: domingo, 12 de septiembre de 2021 18:24
Para: gdal-dev at lists.osgeo.org
Asunto: gdal-dev Digest, Vol 208, Issue 17
Send gdal-dev mailing list submissions to
gdal-dev at 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-request at lists.osgeo.org
You can reach the person managing the list at
gdal-dev-owner at 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 <rajsekar at gmail.com>
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] Get error handler user data when removing CPL
Error Handler
Message-ID:
<CA+4CNMGZsOaKZi_oVe9K7sKBrUkpWSkciapAG0NdL5j-zpbB2w at 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.rouault at spatialys.com>
To: Rajsekar Manokaran <rajsekar at gmail.com>, gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Get error handler user data when removing CPL
Error Handler
Message-ID: <0637288e-2945-443c-5f02-39f318003644 at 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 at 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 <rajsekar at gmail.com>
To: Even Rouault <even.rouault at spatialys.com>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Get error handler user data when removing CPL
Error Handler
Message-ID:
<CA+4CNMFrAFBr+xg-JhAnPde6Am9d7pknL87zNYzEt-TuVa_eRQ at 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.rouault at 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 at 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 <sean at mapbox.com>
To: gdal dev <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] Get error handler user data when removing CPL
Error Handler
Message-ID:
<CADPhZXzuZFJ4kg+nBRh_+jKi9aUAHUEbjM2Ee8RUiS4tTc5NeA at 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.rouault at 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 at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
------------------------------
End of gdal-dev Digest, Vol 208, Issue 17
*****************************************
More information about the gdal-dev
mailing list