[GRASS-user] r.in.wms issues

Tue Jan 27 21:44:19 EST 2009

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
>
>
>
>
>