r.in.wms failure

[Massimo Di Stefano]

Hi,

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
rows:       1
cols:       1
cells:      1
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 1 tiles.
Downloading tiles
Downloading data
2009-07-08 20:23:14 URL:http://wms.jpl.nasa.gov/wms.cgi [89223] -> "/
Users/Shared/grassdata/wms_download/wms_global_mosaic__0.geotiff" [1]
All tiles downloaded successfully
Creating output file that is 3P x 3L.
Processing input file /Users/Shared/grassdata/wms_download/
wms_global_mosaic__0.geotiff.
0...10...20...30...40...50...60...70...80...90...100 - done.
WARNING: G_set_window(): Illegal latitude for North
ERROR: r.in.gdalwarp: r.in.gdal failure.
ERROR: r.in.gdalwarp failed

have you any suggestion on how to get it works?

thanks!


Massimo
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

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
> rows:       1
> cols:       1
> cells:      1

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


> GRASS 6.4.0RC5 (lonlat_pg):~ > r.in.wms
>   layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi
>   output=wms_global_mosaic

If I set res=0:05 that works nicely.


Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

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



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[achim]

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
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Massimo Di Stefano]

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

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

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

Massimo wrote:
....
> Requesting 12 tiles.
> Downloading tiles
> Downloading data
> http://wms.jpl.nasa.gov/wms.cgi:
> 2009-07-09 10:39:15 ERROR 403: Forbidden.

"403" is a message is from the web server.

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

have a look in that file. it will probably be a XML message (not a tiff)
with a statement that the server is currently overloaded. (it often is)

next time you run r.in.wms use the -c flag to remove that otherwise it
will think it has already downloaded that tile successfully.


Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

achim wrote:
> 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?

what version of GRASS?

the error is with "units=d", yes?


Hamish



     
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Luca Casagrande]

hamish-2 wrote:

Massimo wrote:
....
> Requesting 12 tiles.
> Downloading tiles
> Downloading data
> http://wms.jpl.nasa.gov/wms.cgi:
> 2009-07-09 10:39:15 ERROR 403: Forbidden.

"403" is a message is from the web server.

To use the same server with OpenLayers, I had to set the size of the tiles to 512px.
Could this be the problem?

Ciao
Luca

[achim]

Its in grass 6.5:
v.to.db map=rivers@achim option=length units=d columns=a_lenght
same as
v.to.db map=rivers@achim option=length units=degrees columns=a_lenght

(there is no degree-option in grass 6.4; I am interested in length
relative to an degree-raster)

achim


Hamish schrieb:

> achim wrote:
>> 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?
>
> what version of GRASS?
>
> the error is with "units=d", yes?
>
>
> Hamish
>
>
>
>      

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

achim wrote:
> Its in grass 6.5:
> v.to.db map=rivers@achim option=length units=d columns=a_lenght
> same as
> v.to.db map=rivers@achim option=length units=degrees columns=a_lenght
>
> (there is no degree-option in grass 6.4; I am interested in
> length relative to an degree-raster)

a degree is a unit of angle, not a unit of length. you may consider that
a degree latitude has a certain number of meters in it (~1852*60) depending
on the radius of the sphere, and perhaps modify that if you are measuring
on an ellipsoid not a true sphere- but then it is only good for measuring
exactly in the north-south direction, as scale in east-west varies with
the cos(lat).

For v.to.db, radian and degree units are only useful with option=azimuth.
For option=anything_else it should probably exit with an error.
Also option=azimuth should potentially refuse to work if the location is
LL. (in a geodesic/great circle line there is a departure angle and an
arrival angle, but between those it necessarily slowly changes)


Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

Luca wrote:
> To use the same server with OpenLayers, I had to set the
> size of the tiles to 512px.
> Could this be the problem?

probably not. arbitrary sizes work for me.

I don't know, but OpenLayers might be using the pre-cut tiles as JPL's
web page pleads you do, in which case the power-of-2 size makes sense.


?,
Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Luca Casagrande]

hamish-2 wrote:

Luca wrote:
> To use the same server with OpenLayers, I had to set the
> size of the tiles to 512px.
> Could this be the problem?

probably not. arbitrary sizes work for me.

I don't know, but OpenLayers might be using the pre-cut tiles as JPL's
web page pleads you do, in which case the power-of-2 size makes sense.

By default OL request a tile of 256px x 256px but this size is too small for NASA WMS.

Ciao
Luca

[adiez]

r.in.wms is a big problem, on my side, I haven't been able to download  
but from the NASA server, in Spain we got a bunch of wms servers and  
AFAICT none works with r.in.wms, surely, it's a problem of  
(mis)understanding the parameters but I use the same services all the  
time with GIS other than grass w/o problems.

An unsuccessful r.in.wms
First of all, I can assure that http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
  is a pretty stable server but does not work with my [lack] of  
knowledge, I will be grateful if somebody explain what I'm doing wrong.
i.e.
g.region -p
projection: 1 (UTM)
zone:       30
datum:      eur50
ellipsoid:  international
north:      4290000
south:      4280000
west:       715000
east:       735000
nsres:      10
ewres:      10
rows:       1000
cols:       2000
cells:      2000000

r.in.wms -l output=cccc mapserver=http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
  format=png maxcols=1024 maxrows=1024 method=nearest

returns the following

List of layers for server <http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
 >:
2009-07-09 15:13:32 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx? [316/316] -> "/Users/adiez/Document
s/grassdata/nueva/adiez2/.tmp/boquique.prearq.uv.es/56792.0c
apabilities.xml" [1]
The 'xml2' program was not found. Proceeding with internal XML parsing  
which may not be as reliable.
ERROR: Parsing XML file
------------------------
<?xml version='1.0' encoding="ISO-8859-1"  standalone="no" ?>
<ServiceExceptionReport version="1.1.1">
<ServiceException code="InvalidFormat">
<![CDATA[
Unable to encode text. Please set encoding in GUI preferences.
  </ServiceException>
</ServiceExceptionReport>
(Thu Jul  9 15:13:33 2009) Command finished (0 sec)

with get I'm able to get the layers but when I try something else:
r.in.wms -l output=cccc mapserver=http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
  format=png maxcols=1024 maxrows=1024 method=nearest
List of layers for server <http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
 >:
2009-07-09 15:13:32 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx? [316/316] -> "/Users/adiez/Document
s/grassdata/nueva/adiez2/.tmp/boquique.prearq.uv.es/56792.0c
apabilities.xml" [1]
The 'xml2' program was not found. Proceeding with internal XML parsing  
which may not be as reliable.
ERROR: Parsing XML file
------------------------
<?xml version='1.0' encoding="ISO-8859-1"  standalone="no" ?>
<ServiceExceptionReport version="1.1.1">
<ServiceException code="InvalidFormat">
<![CDATA[
Unable to encode text. Please set encoding in GUI preferences.
  </ServiceException>
</ServiceExceptionReport>
(Thu Jul  9 15:13:33 2009) Command finished (0 sec)
(Thu Jul  9 15:16:08 2009)
r.in.wms -l -g output=cccc mapserver=http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
  format=png maxcols=1024 maxrows=1024 method=nearest
List of layers for server <http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
 >:
                n~OGC:WMS~
                nt --Cartografia catastral
                n
Unable to encode text. Please set encoding in GUI preferences.
                        nLAYER:
                                n~Catastro~
                                nt --Catastro
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~CONSTRU~
                                nt --CONSTRU
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~TXTCONSTRU~
                                nt --TXTCONSTRU
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~SUBPARCE~
                                nt --SUBPARCE
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~TXTSUBPARCE~
                                nt --TXTSUBPARCE
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~PARCELA~
                                nt --PARCELA
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~TXTPARCELA~
                                nt --TXTPARCELA
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~MASA~
                                nt --MASA
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~TXTMASA~
                                nt --TXTMASA
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~EJES~
                                nt --EJES
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~LIMITES~
                                nt --LIMITES
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~TEXTOS~
                                nt --TEXTOS
                 nStyle:
                   n~Default~
                   nt --Default

                       
                        nLAYER:
                                n~ELEMLIN~
                                nt --ELEMLIN
                 nStyle:
                   n~Default~
                   nt --Default

                       
               
2009-07-09 15:16:08 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx??service=WMS&request=GetCapabilities
&version=1.1.1 [27412/27412] -> "/Users/adiez/Documents/gras
sdata/nueva/adiez2/.tmp/boquique.prearq.uv.es/56866.0capabil
ities.xml" [1]
The 'xml2' program was not found. Proceeding with internal XML parsing  
which may not be as reliable.
(Thu Jul  9 15:16:08 2009) Command finished (0 sec)
(Thu Jul  9 15:17:19 2009)
r.in.wms -g output=cccc mapserver=http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
  layers=Catastro styles=default srs=EPSG:23030 format=png  
maxcols=1024 maxrows=1024 method=nearest cap_file=catastatro
Calculating tiles
Requesting 2 tiles.
Downloading tiles
Downloading data
2009-07-09 15:17:21 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx??request=GetMap&layers=Catastro&styl
es=default&srs=EPSG:23030&bbox=715000.00000148000000000000,4
279999.99999735000000000000,725019.98002192594905092907,4290
019.98001840215784213786&width=1003&height=1003&format=image
/png&transparent=TRUE&version=1.1.1 [239/239] ->
"/Users/adiez/Documents/grassdata/wms_download/cccc__0.png"
[1]
Downloading data
2009-07-09 15:17:21 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx??request=GetMap&layers=Catastro&styl
es=default&srs=EPSG:23030&bbox=725000.00000194500000000000,4
279999.99999735000000000000,735039.96004237189810185814,4290
019.98001840215784213786&width=1003&height=1003&format=image
/png&transparent=TRUE&version=1.1.1 [239/239] ->
"/Users/adiez/Documents/grassdata/wms_download/cccc__1.png"
[1]
All tiles downloaded successfully
ERROR 4:
`/Users/adiez/Documents/grassdata/wms_download/cccc__0.png'
not recognised as a supported file format.
ERROR: GRASS-6.5: gdalwarp failure.
ERROR: r.in.gdalwarp failed
(Thu Jul  9 15:17:22 2009) Command finished (3 sec)
(Thu Jul  9 15:18:41 2009)
r.in.wms -g --overwrite --verbose output=cccc mapserver=http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
  layers=Catastro styles=default srs=EPSG:23030 maxcols=1024  
maxrows=1024 method=nearest cap_file=catastatro v=5
Using WGET for downloading data.
The verbosity option is superseded. Use --verbose instead
Skipping argument for region
Skipping argument for tileoptions
wms.request
'folder=/Users/adiez/Documents/grassdata/wms_download'
'prefix=cccc' 'mapserver=http://ovc.catastro.meh.es/Cartogra
fia/WMS/ServidorWMS.aspx?' 'layers=Catastro'
'styles=default' 'srs=EPSG:23030' 'format=geotiff'
'wmsquery=version=1.1.1' 'maxcols=1024' 'maxrows=1024'
Calculating tiles
Requesting 2 tiles.
wms.download  -g 'requestfile=/Users/adiez/Documents/grassda
ta/wms_download/cccc_.wget' 'wgetoptions=-c -t 5 -nv'
'curloptions=-C - --retry 5 -s -S'
Downloading tiles
Downloading data
Requesting Data from <http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
 >:
request=GetMap&layers=Catastro&styles=default&srs=EPSG:
23030
&bbox
=
715000.00000148000000000000,4279999.99999735000000000000,725019.98002192594905092907,4290019.98001840215784213786
&width=1003&height=1003&format=image/
geotiff&transparent=TRUE&version=1.1.1
2009-07-09 15:18:43 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx??request=GetMap&layers=Catastro&styl
es=default&srs=EPSG:23030&bbox=715000.00000148000000000000,4
279999.99999735000000000000,725019.98002192594905092907,4290
019.98001840215784213786&width=1003&height=1003&format=image
/geotiff&transparent=TRUE&version=1.1.1 [239/239] -> "/Users
/adiez/Documents/grassdata/wms_download/cccc__0.geotiff" [1]
Downloading data
Requesting Data from <http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?
 >:
request=GetMap&layers=Catastro&styles=default&srs=EPSG:
23030
&bbox
=
725000.00000194500000000000,4279999.99999735000000000000,735039.96004237189810185814,4290019.98001840215784213786
&width=1003&height=1003&format=image/
geotiff&transparent=TRUE&version=1.1.1
2009-07-09 15:18:44 URL:http://ovc.catastro.meh.es/Cartograf
ia/WMS/ServidorWMS.aspx??request=GetMap&layers=Catastro&styl
es=default&srs=EPSG:23030&bbox=725000.00000194500000000000,4
279999.99999735000000000000,735039.96004237189810185814,4290
019.98001840215784213786&width=1003&height=1003&format=image
/geotiff&transparent=TRUE&version=1.1.1 [239/239] -> "/Users
/adiez/Documents/grassdata/wms_download/cccc__1.geotiff" [1]
All tiles downloaded successfully
r.in.gdalwarp  -c 'input=/Users/adiez/Documents/grassdata/wm
s_download/cccc__0.geotiff,/Users/adiez/Documents/grassdata/
wms_download/cccc__1.geotiff' 'output=cccc' 'method=nearest'
's_srs=EPSG:23030'
ERROR 4: `/Users/adiez/Documents/grassdata/wms_download/cccc
__0.geotiff' not recognised as a supported file format.
ERROR: GRASS-6.5: gdalwarp failure.
ERROR: r.in.gdalwarp failed
(Thu Jul  9 15:18:44 2009) Command finished (2 sec)

[1] http://www.idee.es/show.do?to=pideep_desarrollador_wms.ES
[2] http://www.idee.es/CatalogoServicios/cat2/indexWMS.html

On Jul 9, 2009, at 2:17 PM, Luca Casagrande wrote:

>
>
>
> hamish-2 wrote:
>>
>>
>> Luca wrote:
>>> To use the same server with OpenLayers, I had to set the
>>> size of the tiles to 512px.
>>> Could this be the problem?
>>
>> probably not. arbitrary sizes work for me.
>>
>> I don't know, but OpenLayers might be using the pre-cut tiles as  
>> JPL's
>> web page pleads you do, in which case the power-of-2 size makes  
>> sense.
>>
>>
>>
>
> By default OL request a tile of 256px x 256px but this size is too  
> small for
> NASA WMS.
>
> Ciao
> Luca
> --
> View this message in context: http://n2.nabble.com/r.in.wms-failure-tp3227181p3231076.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> _______________________________________________
> grass-user mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[William Kyngesburye]

It's been noted in the past (and the note in the r.in.wms output) that  
the fallback parsing (when xml2 program is not found) doesn't work  
well for some WMS servers.

I bundle an xml2 binary in my OSX GRASS binaries.  You can easily  
build one yourself.  Grab the source from:

http://ofb.net/~egnor/xml2/

Get the .3 source, .4 is exactly the same source, but with a  
configure, BUT it requires pkg-config (yuck!).

edit the makefile (there's no configure in .3), change the CFLAGS and  
LDLIBS lines to match:

CFLAGS = -Os -I/usr/include/libxml2/libxml -I/usr/include/libxml2
LDLIBS = -lxml2 -lz -lpthread -liconv -lm

Then make.  Then copy it to /usr/local/bin.  Or use the OSX app  
bundle.sh to copy it to the GRASS package/bin.

On Jul 9, 2009, at 8:28 AM, Agustin Diez Castillo wrote:

> The 'xml2' program was not found. Proceeding with internal XML  
> parsing which may not be as reliable.
> ERROR: Parsing XML file

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled  
with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in a  
bucket filled with hyena offal?
First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy


_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Martin Landa]

Hi,

2009/7/9 William Kyngesburye <[hidden email]>:
> It's been noted in the past (and the note in the r.in.wms output) that the
> fallback parsing (when xml2 program is not found) doesn't work well for some
> WMS servers.

or try untested r.in.wms Python port from trunk.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user