[GRASS-user] r.in.wms failure

Massimo wrote:

> I'm tring to use r.in.wms on mac osx leopard using grass64
> (binary version) this the log :
>
> GRASS 6.4.0RC5 (lonlat_pg):~ > g.region res=30 -ap
> projection: 3 (Latitude-Longitude)
> zone: 0
> datum: wgs84
> ellipsoid: wgs84
> north: 60N
> south: 30N
> west: 0
> east: 30E
> nsres: 30
> ewres: 30

Hamish:

umm, your resolution is set to 30 degrees and so it is just
requesting a single cell. probably not what you want.

if you were trying to use a 30m resolution that is ~ 1" aka 0:00:01.

but that is in total a 108000 x 108000 raster map, which is a) probably
too big a map for your computer to handle well, b) too many tiles for
r.in.wms to handle well, and c) rather abusive of their poor overloaded
WMS server.

Please read the top statement on the OnEarth WMS web page.
  http://wms.jpl.nasa.gov/

It reads:

"ATTENTION:

Due to server overloading, client applications are strongly advised to use the existing tile datasets wherever possible, as described in the Tiled WMS or Google Earth KML support

Frequent and repetitive requests for non-cached, small WMS tiles require an excessive amount of server resources and will be blocked in order to preserve server functionality. The OnEarth server is an experimental technology demonstrator and does not have enough resources to support these requests.
*An alternative solution already exists in the form of tiled WMS*
While sets of tiles with different sizes and alignment can be added when needed, for large datasets the duplication of storage, processing and data management resources is prohibitive."

If they notice that these huge requests are coming from GRASS software
it is rather bad karma for us...

cheers,
Hamish

Hi all,

Uploading the lengths of lines in 1)km and 2)degrees in an lat-long
location with the v.to.db module returns a strange result as
d = 1000*km

So what do these (decimal)degrees mean?

achim

Il giorno 09/lug/09, alle ore 10:14, Hamish ha scritto:

Massimo wrote:

I'm tring to use r.in.wms on mac osx leopard using grass64
(binary version) this the log :

GRASS 6.4.0RC5 (lonlat_pg):~ > g.region res=30 -ap
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 60N
south: 30N
west: 0
east: 30E
nsres: 30
ewres: 30

Hamish:

umm, your resolution is set to 30 degrees and so it is just
requesting a single cell. probably not what you want.

if you were trying to use a 30m resolution that is ~ 1" aka 0:00:01.

but that is in total a 108000 x 108000 raster map, which is a) probably
too big a map for your computer to handle well, b) too many tiles for
r.in.wms to handle well, and c) rather abusive of their poor overloaded
WMS server.

really is not my intention to overload nothing :wink:

i'm just testing r.in.wms

i used a so "bad" resolution "res=30" (here maybe i'm wrong)
just to see if "r.in.wms" it works,

tring on a small region :

GRASS 6.4.0RC5 (lonlat_pg):~ > g.region rast=new -ap
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 40:36:27N
south: 39:50:16N
west: 15:04:28E
east: 15:58:47E
nsres: 0:00:01
ewres: 0:00:01
rows: 2771
cols: 3259
cells: 9030689
GRASS 6.4.0RC5 (lonlat_pg):~ > r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi output=wms_global_mosaic
Calculating tiles
Requesting 12 tiles.
Downloading tiles
Downloading data
http://wms.jpl.nasa.gov/wms.cgi:
2009-07-09 10:39:15 ERROR 403: Forbidden.
ERROR: Failed while downloading the data
Downloading data
...
http://wms.jpl.nasa.gov/wms.cgi:
2009-07-09 10:39:23 ERROR 403: Forbidden.
ERROR: Failed while downloading the data
WARNING: 12 failed to download
ERROR 4: `/Users/Shared/grassdata/wms_download/wms_global_mosaic__0.geotiff' not recognised as a supported file format.

ERROR: r.in.gdalwarp: gdalwarp failure.
ERROR: r.in.gdalwarp failed

maybe it is a server problem ... but no clue

i have acces forbidden, i dn't know why, i just followed the grass help example

Please read the top statement on the OnEarth WMS web page.
http://wms.jpl.nasa.gov/

It reads:

"ATTENTION:

Due to server overloading, client applications are strongly advised to use the existing tile datasets wherever possible, as described in the Tiled WMS or Google Earth KML support

Frequent and repetitive requests for non-cached, small WMS tiles require an excessive amount of server resources and will be blocked in order to preserve server functionality. The OnEarth server is an experimental technology demonstrator and does not have enough resources to support these requests.
*An alternative solution already exists in the form of tiled WMS*
While sets of tiles with different sizes and alignment can be added when needed, for large datasets the duplication of storage, processing and data management resources is prohibitive."

If they notice that these huge requests are coming from GRASS software
it is rather bad karma for us...

cheers,
Hamish