[GRASS-user] r.in.wms issues

[Hamish]

Adam wrote:
> 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....

yeah, we try to catch that but WMS servers act differently when they
fail so it is hard.. and apparently the "file" program is not very
portable to the Mac.


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

ok, good. Those last 6 errors are just because setting the map title
and history fail because the map name is wrong (added ".1"). Nothing to
worry about too much. (in SVN I haven't fixed it but now you only see one
error)


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

this is a separate bug apparently, stored range is also wrong in
grass 6.4.0rc2:  (but "min=0" here)

# spearfish
g.region rasy=elevation.10m

r.in.wms output=elev_us_ned64gtif mapserver=wms.jpl.nasa.gov/wms.cgi \
  layers=us_ned style=real format=geotiff method=cubic

r.info -r elev_us_ned64gtif.1
min=0
max=1843.64624023438

r.univar -g elev_us_ned64gtif.1
min=1060.62268066406
max=1843.64624023438



> I am using UTM not Lat/Long.  And that is why it is trying
> to do the conversion, I think.

ok, with the above spearfish example I see the tile lines too.

they are there because the reprojection is done before the patching?,
and the convergence angle* is not zero.

[*] grid north vs. true north  ('g.region -n' in newer versions of grass)
using "d.grid -w 0:03 color=black" to overlay a lat/lon grid makes it obvious.


actually, I see that the sliver areas are 0.0 not null, so maybe the patch
is ok** but the nodata is set wrong. (so related to min=0 range error
above?)

[**] ie r.patch treats null as transparent but not 0s. so r.patch is
just following what the input data gives it.


much to do here,
Hamish