[GRASS-user] Re: [GRASS-dev] r.in.wms improvements (call for testing)

[Agustin Diez Castillo]

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/ 
LaCieDisk/Users/Shared/agus_compartido/grassdata/Projecte/adiez2/.tmp/ 
regadiuet.prearq.uv.es/4333.0capabilities.xml" [1]
wget -c -t 5 -nv --post- 
data="service=WMS&request=GetCapabilities&version=1.1.1" "http://www.idee.es/wms/PNOA/PNOA 
" -O "/Volumes/LaCieDisk/Users/Shared/agus_compartido/grassdata/ 
Projecte/adiez2/.tmp/regadiuet.prearq.uv.es/4333.0capabilities.xml";


ERROR: Parsing XML file
------------------------
<?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE ServiceExceptionReport SYSTEM
  "http://www.idee.es/SgdWms/Server/exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1">
   <ServiceException code="InvalidFormat">
     <![CDATA[
   Par?metros:
     REQUEST INEXISTENTE O INVALIDA
     Verticesdisponibles:
     ]]>
   </ServiceException>
</ServiceExceptionReport>



On Mar 5, 2008, at 9:36 AM, Hamish wrote:

> 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
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>