[GRASS-user] WMS fails on Geosciences Australia downloads

Richard Chirgwin rchirgwin at ozemail.com.au
Tue May 13 23:50:30 EDT 2008


Hamish wrote:
> Richard Chirgwin wrote:
>   
>> I am trying to access layers on the Geosciences Australia
>> OGC Web Map server:
>> http://www.ga.gov.au/wms/getmap?dataset=national&request=getCapabilities
>>     
> ....
>   
>> Is it a bug in Grass-GIS or at the other end?
>>     
>
> 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. Yes, a query server which doesn't accept queries. !@$##$%
>
> Anyway, in the past I tried to auto-detect that and switch to the other method, but the error mode the remote server sends seems to vary for each, so it is hard to do that well. I've now added a new flag to r.in.wms (-g) to force using the GET method. With that I can fetch data from Geosciences Australia's WMS:
>
> r.in.wms -l -g mapserv="http://www.ga.gov.au/wms/getmap?dataset=national&"
>
> # search for Gold:
> r.in.wms mapserv="http://www.ga.gov.au/wms/getmap?dataset=national&" \
>    -g layers=au_occdd output=au_gold format=tiff
>
>
> I also discovered that Geosciences Australia's WMS server does not ship GeoTiffs, which is r.in.wms's default. So you'll have to use format=<other>.
> An issue with format=tiff is that the alpha (transparency) layer that comes from Geosci. Aust. runs from 1-255 instead of 0-255, and so no-data is treated as some-data and the resulting data looks a bit funky. That is easily fixed with r.mapcalc or r.null after import or in the case of the Gold, a simple call to r.colors:
>   echo "1023 yellow" | r.colors au_gold col=rules
>
> format=gif and png are really slow as the individual tiles use their own custom 8bit color palettes and when merged together the palette from the first tile is used and the rest of the tiles look nuts. So r.in.gdalwarp goes the long way to ensure good results, which is very very slow. gdal_merge.py is probably a much better method for the future.
>
> format=jpeg now works (fixed in latest commit; it has no alpha layer), but the results are subject to lossy JPEG compression/blurring.
>
>
> yikes.
>
>
> If you get the contents of the scripts/r.in.wms/ dir from develbranch_6 and put replace 6.3.0's versions and re-make that dir you should be able get it to work (proof attached :)
> http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/r.in.wms
>
>
>
> calmly,
> Hamish
>
>
> 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.
>   
I didn't notice the mail wrapping issue ...

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". So the server would have to be 
considered "a little flaky" on a good day.

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.

Oh well ...

Richard
>
>
>       ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> ------------------------------------------------------------------------
>
-------------- next part --------------
Skipped content of type multipart/related


More information about the grass-user mailing list