Hi,
Yesterday I had some trouble connecting to NOAA's Electronic Navigation
Chart(ENC) WMS server[1] using r.in.wms. It turns out that their WMS
server poses some challenges for us. Their ArcIMS system will not handle
POST-data, it will only respond to very long URL strings (GET requests)
[2]. Also their list of layer names include URL problematic characters
like spaces and parser problematic chars like commas[3].
In SVN/trunk I've now adjusted the code to deal with both of those
things, although I haven't done anything for commas in the layer names -
those will still be parsed incorrectly[4]. Also the script is now
slightly less chatty by default and writes metadata to the output file.
Could folks test it please? If it's good it might be worth backporting
for 6.3.0, but it would need a lot of testing before considering that.
Agustin, maybe this solves your problem?
I also tried to fix the tile patching for single-band image. The ArcIMS
server would only send JPEGs or 8bit PNG & GIF images (no GeoTIFF). The
JPGs split into three RGB bands and patch correctly, but the 8bit PNG and
GIF tiles have per-tile unique color indexes; r.patch uses the index
from the first, resulting in funky weirdness. The current solution is a
hack using r.mapcalc's r#,g#,b# operators to split into three bands, then
do the patching, and then r.compositing. Other ideas for solving that:
1- add a -c flag to r.patch to patch by common color not by cat number.
2- use the PNG driver to 'd.rast -o' all the tiles, set GRASS_WIDTH and
GRASS_HEIGHT to the region dims, then run d.out.file + 'r.in.gdal -o' +
r.region.
3- Use echo "`seq 0 255`" | r.what.color -i in=tile_0 (or colr/ files
directly) to get color tables for each tile, then for all the other
tiles do a search loop for each RGB value and create reclass rules
for each additional tile then run r.patch and copy the color index
rules from the first map.
4. (what I did) For each tile extract 3 new 0-255 maps with r.mapcalc's
r#, g#, b# operators, patch all r, g, b tiles together, then recombine
into a single map with r.composite.
5. Use gdal_merge.py (but does it have a preserve color mode?)
6. Try NetPBM's pnmcat on raw downloaded tiles before loading into GRASS.
This is what NVIZ uses to assemble the max. res PPM output.
(but does it have a preserve color mode?)
"1" would be the best but I expect easier said than done. [beyond me]
"2" is probably the quickest but dirtiest [opens to display lib pains]
"3" has elegance but may be slow [perhaps not so slow?]
"4" slow but functional hack
"5" and "6" on the raw input would probably be very fast, but it is
unknown to me if they would suffer the same multiple color index
problem as r.patch.
TODO:
* rewrite the thing in Python (any volunteers? what is the QGIS plugin
written in? Python or C++? [reuse whatever we can])
* See if GDAL 1.5.0's new WMS function could help simplify the task
[1] NOAA's WMS:
http://ocs-spatial.ncd.noaa.gov/website/encdirect/help/helpfile.htm#Webser
http://ocs-spatial.ncd.noaa.gov/wmsconnector/com.esri.wms.Esrimap/encdirect?
Some nice layers to get started with:
"layers=\
LAND,\
2DEPTH AREA(DEPARE),\
2SEA AREA(SEAARE),\
2SEABED AREA_polygon(SBDARE),\
2SOUNDINGS,\
DEPTH AREA(DEPARE)"
[2] the OGC WMS def ver 1.3.0 says that is allowed, see sec. 6.3.4
[3] the layer names are a mixed bag, most use _ not ' ', only one comma
[4] will GRASS's parser handle escaped \, in a multiple answers list?
can it be simply done in a shell script? ('s+\\,+%2C+g' is easy
enough but how to have that ignore a real '\\,' in the layer name?)
and that means the use will have to munge the layer name manually 
sorry for the long post on a high traffic day,
Hamish