[GRASS-dev] Re: [GRASS GIS] #735: r.in.wms causes g.parser buffer owerflow

2009-08-27 Thread GRASS GIS
#735: r.in.wms causes g.parser buffer owerflow
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  normal  |   Milestone:  6.5.0
 Component:  Raster  | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  Unspecified  
-+--
Comment (by marisn):

 Replying to [comment:2 hamish]:
  from grass65/scripts/r.in.wms/wms.request:
 
  {{{
g.message Requesting ${NUMBER_OF_TILES} tiles.
  }}}
 g.message is a bad choice, as on fast machine with fast WMS server it too
 soon gets burried in 200 tile downloading messages.

 Glynn: no idea. It's too hardcore for me. Still IMHO buffer owerflow isn't
 the right way how to deal with error conditions.

 It would be nice if r.in.wms could calculate resulting arg length and fail
 if it exceeds systems capabilities (theoretical limits).

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/735#comment:4
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #735: r.in.wms causes g.parser buffer owerflow

2009-08-25 Thread GRASS GIS
#735: r.in.wms causes g.parser buffer owerflow
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  normal  |   Milestone:  6.5.0
 Component:  Raster  | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  Unspecified  
-+--
Comment (by glynn):

 Replying to [ticket:735 marisn]:

  I used r.in.wms to download high resolution topographical maps from
 local WMS service. Download part went just fine but it resulted into 287
 tiles. Then r.in.wms calls r.in.gdalwarp
 input=/home/maris/grassdata/wms_download/topo_10k_psrs_0.png and so on 287
 tile names. Such call results in buffer owerflow in g.parser:

 I can fix the buffer overflow by using G_asprintf(), but some operating
 systems aren't going to like storing that much data in an environment
 variable (Linux 2.6 doesn't mind, but a limit of 4K for argv+environ is
 quite common).

 The Python scripting library in GRASS 7 has g.parser write the information
 to stdout rather than using environment variables, so this isn't an issue
 there.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/735#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #735: r.in.wms causes g.parser buffer owerflow

2009-08-25 Thread GRASS GIS
#735: r.in.wms causes g.parser buffer owerflow
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  normal  |   Milestone:  6.5.0
 Component:  Raster  | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  Unspecified  
-+--
Comment (by hamish):

 from grass65/scripts/r.in.wms/wms.request:

 {{{
   g.message Requesting ${NUMBER_OF_TILES} tiles.
   if [ $NUMBER_OF_TILES -gt 200 ] ; then
  g.message -w Proceed with care. This number of tiles may exceed \
the maximum command line argument length available from your \
operating system and cause an error later on in the r.in.gdalwarp \
step. In addition it may be considered abusive behavior by the \
server provider - check their terms of use.
   fi
 }}}

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/735#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #735: r.in.wms causes g.parser buffer owerflow

2009-08-25 Thread GRASS GIS
#735: r.in.wms causes g.parser buffer owerflow
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  normal  |   Milestone:  6.5.0
 Component:  Raster  | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  Unspecified  
-+--
Comment (by hamish):

 one trick is try to make the tiles bigger with the maxcols, maxcols so you
 need to get fewer tiles. Note many servers will restrict this size.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/735#comment:3
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev