On Jan 27, 2009, at 5:57 PM, Hamish wrote:
Adam Dershowitz wrote:
I am trying to use r.in.wms to get elevation data from
wms.jpl.nasa.gov, but I have been running into two different
problems.
I have been using the gui on a mac with 6.3, although I also tried
6.4
RC2 and got similar results.
which/who's Mac binaries?
Kyngesburye
what version of gdal tools? ("gdalinfo --version" from the command
prompt)
GDAL 1.5.4, released 2009/01/07
(I have also tried out the 1.6 release, and it reports GDAL 1.6.0,
released 2008/12/04.)
The files do download but then I can't seem to work with them
properly. I have tried geotiff and png. I have tried a bunch
of other combinations as well.
....
Here is the command that is being generated by the gui:
r.in.wms output=elev_us_ned2 mapserver=wms.jpl.nasa.gov/wms.cgi \
layers=us_ned format=png wmsquery=version=1.1.1 \
maxcols=1024 maxrows=1024 {wgetoptions=-c -t 5 -nv} \
{curloptions=-C - --retry 5 -s -S} method=cubic v=1
mapserver= usually starts with "http://";. This appears to be
optional for
wget; but I don't know about curl.
But the download seems to go fine. Although in my early testing I had
it set for a higher resolution so it was getting a bunch of downloads
and sometimes the server would complain that it was too busy. I only
figured out that problem because in those cases the ".geotiff" files
were much smaller. When I checked they contained the error message.
But r.in.wms tried to use them anyway....
method=cubic is irrelevant if the location is WGS84 Lat/lon, you can
omit it.
I am using UTM not Lat/Long. And that is why it is trying to do the
conversion, I think.
srs= is missing in above command?
By default it was filling in src=EPSG:4326, which I believe is fine
for UTM nad83 in the US. I tried it both with and without that with
the same results.
This is followed by this long list of errors:
....
Invalid map <elev_us_ned2_tile_0_tmp.alpha>
Parse error
?
perhaps a Mac/BSD vs GNU command line util using a non-portable
command?
On linux(debian/etch) I get the same result/errors as Markus.
Markus:
I tried in 6.4 and got (copying your command line):
I just tried that command again with 6.4RC2. I also get the identical
results to Markus. (and adding style=feet_real make it reasonable
units). However there are the two files created. If I try to view
one of them there is still that "crack" across the middle, where it
looks like one is rotated and the other is not. And if I try to view
the other one it is just all zeros.
6.4.0rcX or develbranch6? Note in develbranch6 null values are
broken:
trac #455, #392? http://trac.osgeo.org/grass/ticket/455
!!
GR65> r.info -r elev_us_ned65.1
min=-2147483648
max=53
#fix
GR65> r.null elev_us_ned65.1 setnull=-2147483648
strange, for <.2> min is given as -2147483648 but r.univar shows
zero null cells.
....
Using band 2 of source image as alpha.
0...10...20...30...40...50...60...70...80...90...100 -
done.
Rename raster <elev_us_ned2_tile_0.1> to <elev_us_ned2.1>
Rename raster <elev_us_ned2_tile_0.2> to <elev_us_ned2.2>
so far so good,
ERROR: Raster map <elev_us_ned2> not found in current mapset
ERROR: Raster map <elev_us_ned2> not found in current mapset
ERROR: Raster map <elev_us_ned2> not found in current mapset
ERROR: Raster map <elev_us_ned2> not found in current mapset
ERROR: Raster map <elev_us_ned2> not found in current mapset
ERROR: Raster map <elev_us_ned2> not found in current mapset
Slightly better/different but eventually failing, too. :(
fwiw, these "ERROR: Raster map <> not found in current mapset" are
from the 6 r.support calls in the r.in.wms script just after:
eval "r.in.gdalwarp $GDALWARP"
if [ $? -ne 0 ] ; then
exit 1
fi
(I am not sure if that $? check really works: is it testing that eval
could run the command, not if the command exited successfully?)
the problem here is that the output is called <map.1> and <map.2> so
the
raster map name passed to r.support are wrong. <map.2> is apparently
alpha layer (empty map), while <map.1> contains the data.
in a lat/lon WGS84 location:
grass640> g.region n=46:04N s=39:30N w=80:24W e=71:20W res=0:00:30
grass640> r.in.wms output=elev_us_ned64 \
mapserver="wms.jpl.nasa.gov/wms.cgi" layers=us_ned format=png \
wmsquery=version=1.1.1 maxcols=1024 maxrows=1024 \
wgetoptions="-c -t 5 -nv" curloptions="-C - --retry 5 -s -S" \
method=cubic v=1 --o --v
I get data in the <.1> file.
because the format is PNG & style is default, the values refer to
color
and are in the range of 0-53. To see anything but mostly-black I
needed
to do:
grass640> r.colors elev_us_ned64.1 col=bcyr
and you get a nice image.
'r.in.wms -l' says the "us_ned" layer is supposed to show:
LAYER: us_ned
Title: United States elevation, 30m
|
| Continental United States elevation, produced from the
USGS National Elevation.
| The default style is scaled to 8 bit from the orginal
floating point data.
|
STYLE: default
Style title: Default Elevation
STYLE: short_int
Style title: short int signed elevation values when format is
image/png or tiff
STYLE: feet_short_int
Style title: short int elevation values in feet when format is
image/png or image/tiff
STYLE: real
Style title: DEM real numbers, in floating point format, meters,
when used with image/tiff
STYLE: feet_real
Style title: DEM in real numbers, in floating point format, feet,
when used with image/tiff
[how do they scale to "8 bit from the orginal floating point data" ?
what elevation is 255? Mount Whitney @ 4421m?]
anyway, if I add "style=real" to the r.in.wms command (according to
the
above) you get the <.1> map in meters and the Catskills are not so
flat :)
sigh,
Hamish
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
