[gdal-dev] Determining GDAL WMS download limit?

[Andre Vautour]

On 2015-07-07 15:34, Carl Godkin wrote:
>
> Hi Andre,
>
> Thank you very much for the reply.  I hadn't thought of querying the 
> levels as you suggest but I'll remember next time that it makes a good 
> test.
>
> However, I'm not sure what I would do with the 
> <TileLevel>7</TileLevel>  suggestion
> you make.
Even's response is definitely more accurate/relevant then mine.

I originally thought that the tile set only had so many levels, but as 
Even indicated, it varies by region in this case, so you'd be better 
advised to handle 404 (not found) errors as transparent tiles as he 
suggested. As long as those land areas have data up to the TileLevel 
that is specified (20), that should be all that you need to do.

> If I change my WMS control file to use that value, gdal_translate 
> doesn't work at all so there must be something more to it than that. 
>  (I've learned the hard way over the years that changing the WMS 
> control file is not for amateurs.)
Well, the problem is that srcwin is defined in pixel space, and changing 
the tile level means that the WMS raster is now coarser, so naturally 
has fewer pixels. You would have had to redo whatever google merc to 
pixel space conversion you had done previously as the pixel-space window 
would have changed.

>
> If you could explain what you meant, I'd be very grateful. Thanks,
>
> carl
Sorry for the confusion and do let me know if you want more clarification,
André

>
> On Tue, Jul 7, 2015 at 7:22 AM, Andre Vautour <andre.vautour at caris.com 
> <mailto:andre.vautour at caris.com>> wrote:
>
>     Looks like that server only has 7 levels for that satellite layer:
>     http://mt.google.com/vt/lyrs=s&x=0&y=0&z=7
>     http://mt.google.com/vt/lyrs=s&x=0&y=0&z=8
>
>     The terrain and map layers have 22 levels:
>     http://mt.google.com/vt/lyrs=t&x=0&y=0&z=22
>     http://mt.google.com/vt/lyrs=t&x=0&y=0&z=23
>     http://mt.google.com/vt/lyrs=m&x=0&y=0&z=22
>     http://mt.google.com/vt/lyrs=m&x=0&y=0&z=23
>
>     So, you'd have to change the TileLevel element:
>     <TileLevel>7</TileLevel>
>
>     That smaller size probably ended up querying tile levels < 8 which
>     is why it worked.
>     André
>
>
>
>     On 2015-07-07 11:02, Carl Godkin wrote:
>>
>>     Hi,
>>
>>     I would like to know if there's a way to determine if a GDAL WMS
>>     download
>>     is going to work or not from the information in the local
>>     description file.
>>
>>     I'm using C++ code to do this, but can illustrate my question
>>     with a gdal_translate
>>     command.  This command fails:
>>
>>     gdal_translate -outsize 6700 6700 \
>>          -srcwin 144884562 100729336 178000 178687 \
>>          frmt_wms_googlemaps_tms.xml \
>>          out.tif
>>
>>     Input file size is 268435456, 268435456
>>     0...10...20...30...40...50...60...70ERROR 1: GDALWMS: Unable to
>>     download block 35372, 24624.
>>       URL: http://mt.google.com/vt/lyrs=s&x=35372&y=24624&z=16
>>       HTTP status code: 404, error: (null).
>>     ERROR 1: frmt_wms_googlemaps_tms.xml, band 1: IReadBlock failed
>>     at X offset 35372, Y offset 24624
>>
>>     but if I change the -outsize arguments to 6500 and 6500, it works
>>     fine.
>>
>>     I am perfectly willing to accept the limitations of what's
>>     available, but can I tell where that limit will be?
>>
>>     The service file is from the frmts/wms directory with the
>>     "Satellite" ServerURL line active instead of the "Map" line.
>>
>>     Notes:
>>     1. Curiously, the default "Map" ServerURL works to much higher
>>     resolution (at least 15000) which makes me
>>     think that the answer to my question will be "no" since the
>>     service description files are otherwise identical!
>>     2. The map area above is Italy, but I see the same sort of
>>     behavior around the world.
>>
>>     I am using GDAL 1.11.2 on Windows7 x64, but see the same behavior
>>     on Linux RHEL5 64-bit as well.
>>
>>     Thank you very much for any insight,
>>
>>     carl
>>
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org  <mailto:gdal-dev at lists.osgeo.org>
>>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150707/e0826664/attachment.html>