<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hamish wrote:
<blockquote cite="mid:237802.42418.qm@web45805.mail.sp1.yahoo.com"
type="cite">
<pre wrap="">Richard Chirgwin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am trying to access layers on the Geosciences Australia
OGC Web Map server:
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://www.ga.gov.au/wms/getmap?dataset=national&request=getCapabilities">http://www.ga.gov.au/wms/getmap?dataset=national&request=getCapabilities</a>
.....
Hamish:
</pre>
<blockquote type="cite">
<pre wrap="">I'll be kind and say GRASS because /technically/ the other end conforms
to the WMS spec. The problem was that the other end does not accept
queries in the form of HTTP POST data.
</pre>
</blockquote>
<pre wrap=""><!---->[r.in.wms -g flag added to deal with that; this works:]
</pre>
<blockquote type="cite">
<pre wrap="">r.in.wms -l -g mapserv=<a class="moz-txt-link-rfc2396E" href="http://www.ga.gov.au/wms/getmap?dataset=national&">"http://www.ga.gov.au/wms/getmap?dataset=national&"</a>
# search for Gold:
r.in.wms mapserv=<a class="moz-txt-link-rfc2396E" href="http://www.ga.gov.au/wms/getmap?dataset=national&">"http://www.ga.gov.au/wms/getmap?dataset=national&"</a> \
-g layers=au_occdd output=au_gold format=tiff
</pre>
</blockquote>
<pre wrap=""><!---->....
</pre>
<blockquote type="cite">
<pre wrap="">ps- sorry if this email is wrapping at about char 90, yahoo as upgraded
their system & removed the "wrap at 72" compose setting, I suppose to
make things simpler for us.
</pre>
</blockquote>
<pre wrap=""><!---->[I hope to get back to using fetchyahoo.pl+cron and a sane client soon]
Richard:
</pre>
<blockquote type="cite">
<pre wrap="">I didn't notice the mail wrapping issue ...
</pre>
</blockquote>
<pre wrap=""><!---->
yours is missing newlines- even worse! :)
(hint: don't post as HTML/rich formatted)
</pre>
<blockquote type="cite">
<pre wrap="">Thanks for all your efforts. There's still something strange at the
Geosciences Australia end; I have repeated your test with the Gold
layer (success). But other layers show errors like "wms_roads__0.png
not recognised as a supported file format".
</pre>
</blockquote>
<pre wrap=""><!---->
if you look in that file you will see text not an image:
<?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE ServiceExceptionReport SYSTEM <a class="moz-txt-link-rfc2396E" href="http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd">"http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd"</a>>
<ServiceExceptionReport version="1.1.1">
<ServiceException code="InvalidSRS">
msWMSLoadGetMapParams(): WMS server error. Invalid SRS given : SRS must be valid for all requested layers.
</ServiceException>
</ServiceExceptionReport>
be sure to delete those old files from $GISDBASE/wms_downloads/ or they will be cached and it'll try to reuse them. ('r.in.wms -c' helps)
'r.in.wms -l' and <a class="moz-txt-link-freetext" href="http://www.ga.gov.au/map/broker/wms_info.php">http://www.ga.gov.au/map/broker/wms_info.php</a> state that the roads layer is in EPSG:3112, so you need to provide that on the command line:
# from a latlon/wgs84 location
g.region n=9S s=46S w=112E e=155E res=0:01 -p
r.in.wms mapserv=<a class="moz-txt-link-rfc2396E" href="http://www.ga.gov.au/wms/getmap?dataset=national&">"http://www.ga.gov.au/wms/getmap?dataset=national&"</a> \
-g layers=roads output=au_roads format=tiff srs=EPSG:3112
</pre>
</blockquote>
Richard: <br>
You're right; so the trick is to be careful!<br>
<br>
I hope this is the last maddening issue; working with:<br>
g.region n=33S s=34S w=150 e=151 nsres=00:00:05 ewres=00:00:05<br>
r.in.wms -c
mapserv=<a class="moz-txt-link-rfc2396E" href="http://www.ga.gov.au/wms/getmap?dataset=national&">"http://www.ga.gov.au/wms/getmap?dataset=national&"</a> -g
layers=dem_9sec output=dem_9sec format=png srs=EPSG:3112<br>
(The small region keeps the the tile size down)<br>
<br>
I get the 9-second DEM. It looks and displays okay, but the elevation
data is wild. <br>
r.what -f input=dem_9sec@PERMANENT east_north=150.8177882,-33.785157971<br>
produces:<br>
150.8177882|-33.785157971||31407|<br>
<br>
Since I can reasonably assume that the elevation isn't 31,407 metres,
nor that the elevation in the mountains is lower than near the ocean,
something's awry with the elevation... I will test it later with TIFF
to see if that works better on elevation, I'm getting called away at
the moment...<br>
<br>
Richard<br>
<br>
<br>
<blockquote cite="mid:237802.42418.qm@web45805.mail.sp1.yahoo.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">So the server would have to be considered "a little flaky" on a good day.
</pre>
</blockquote>
<pre wrap=""><!---->
naw, blame r.in.wms. the server is limited in what it will provide and r.in.wms is not handling the error messages well. (the error can come in the form of a web page, XML, or empty output, and success is a real image, so it is hard to pick how to recognize and pass on the error)
devs: One problem is that I don't know how to test for r.in.gdalwarp's exit code. it is called from r.in.wms with eval- the exit code returned is eval's not r.in.gdalwarp's.
</pre>
<blockquote type="cite">
<pre wrap="">The tiles download okay - the directory shows files with .wget, .png
(or tiff or whatever), .proj4 and .tfw formats, so I guess something is
breaking / broken in the files GA is sending.
</pre>
</blockquote>
<pre wrap=""><!---->
no, open the tile in a text editor and see
with the extra "srs=EPSG:3112" on the command line I could download the roads layer and it looks good.
Hamish
</pre>
</blockquote>
</body>
</html>