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.vaut...@caris.com
<mailto:andre.vaut...@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@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
