[GRASS-dev] r.in.wms improvements (call for testing)
Agustin Diez Castillo
Agustin.Diez at uv.es
Tue Mar 11 05:18:23 EDT 2008
I can't r.in.wms yet (william's svn build, so I'm not absolutely sure
if your changes are there)
r.in.wms -l mapserver=http://www.idee.es/wms/PNOA/PNOA srs=EPSG:23030
format=png wmsquery=version=1.1.1 maxcols=1024 maxrows=1024
'curloptions=-C - --retry 5 -s -S' method=nearest --verbose
Using WGET for downloading data.
List of layers for server <http://www.idee.es/wms/PNOA/PNOA>:
18:51:17 URL:http://www.idee.es/wms/PNOA/PNOA [448/448] -> "/Volumes/
wget -c -t 5 -nv --post-
" -O "/Volumes/LaCieDisk/Users/Shared/agus_compartido/grassdata/
ERROR: Parsing XML file
<?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE ServiceExceptionReport SYSTEM
REQUEST INEXISTENTE O INVALIDA
On Mar 5, 2008, at 9:36 AM, Hamish wrote:
> Yesterday I had some trouble connecting to NOAA's Electronic
> Chart(ENC) WMS server using r.in.wms. It turns out that their WMS
> server poses some challenges for us. Their ArcIMS system will not
> POST-data, it will only respond to very long URL strings (GET
> . Also their list of layer names include URL problematic characters
> like spaces and parser problematic chars like commas.
> 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. Also the script is now
> slightly less chatty by default and writes metadata to the output
> 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
> server would only send JPEGs or 8bit PNG & GIF images (no GeoTIFF).
> 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,
> 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
> 2- use the PNG driver to 'd.rast -o' all the tiles, set GRASS_WIDTH
> GRASS_HEIGHT to the region dims, then run d.out.file + 'r.in.gdal -
> o' +
> 3- Use echo "`seq 0 255`" | r.what.color -i in=tile_0 (or colr/
> 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#, g#, b# operators, patch all r, g, b tiles together, then
> 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
> 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.
> * 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
>  NOAA's WMS:
> Some nice layers to get started with:
> 2DEPTH AREA(DEPARE),\
> 2SEA AREA(SEAARE),\
> 2SEABED AREA_polygon(SBDARE),\
> DEPTH AREA(DEPARE)"
>  the OGC WMS def ver 1.3.0 says that is allowed, see sec. 6.3.4
>  the layer names are a mixed bag, most use _ not ' ', only one
>  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,
> grass-dev mailing list
> grass-dev at lists.osgeo.org
More information about the grass-dev