[GRASS-dev] r.reclass.area problem in svn

[Yann Chemin]

Hello list,

r.reclass.area does not find specified rules and string conversion problem.
Thanks for help,
Yann

---
(Tue Apr 13 08:19:56 2010)
r.reclass.area input=rs_thin...@permanent output=RS_clump_reclass_area
greater=100 --overwrite
Generating a clumped raster file ...
Pass 1...
Pass 2...
r.clump complete. 12544 clumps.
Generating a reclass map with area size greater than or equal to
100.00 hectares...
ERROR: No rules specified
Traceback (most recent call last):
  File "/usr/local/grass-7.0.svn/scripts/r.reclass.area",
line 126, in 
main()
  File "/usr/local/grass-7.0.svn/scripts/r.reclass.area",
line 119, in main
grass.message(_("Generating output raster map
<$outfile>...") % outfile)
TypeError: not all arguments converted during string
formatting
(Tue Apr 13 08:20:01 2010) Command finished (5 sec)
-

-- 
Yann Chemin
Senior Spatial Hydrologist
www.csu.edu.au/research/icwater
M +61-4-3740 7019
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: New DWG import module

[Rodrigo Rodrigues da Silva]

On 13-03-2010 13:44, Markus Neteler wrote:

On Thu, Dec 24, 2009 at 10:16 PM, Rodrigo Rodrigues da Silva
  wrote:

There are some preliminary results on the module I've been writing. It
is a DWG file (http://www.naval.com/drawings/dwg/PRA430d.dwg - there's
a PDF too) that we've been using with testSVG, rendered with GRASS's
nviz module.


(somewhat late answer)
Congratulations to your first results!


Sorry I haven't seen your reply before. I have left work on that module 
behind for a while due to LibreDWG issues. Now the issues seem to be 
addressed and I plan to get back to work on the module by next week. I 
was wondering if I could get access to the Addons SVN, and if someone 
would be wanting to mentor me on that (I've read RFC2). I can publish a 
tarball before that for evaluation, but I'd like to make it available to 
the community anyway.



I think that it looks a bit aliased, maybe because GRASS
is tuned for larger orders of magnitude (kilometers) by default, and
not circuit boards (centimeters) -- I'm just wondering, I'm not a
GRASS user nor a SIG specialist. I need to test it with a proper DWG
file or change some configurations.


No, GRASS can work with any unit, also nanometers if you want.
The problem must be elsewhere.
For inspection, you can use v.out.ascii to see the vectors in ASCII.

I'll check it out, thanks.



I'll submit it as soon as I get the INSERTs and BLOCKs working.

Rodrigo.


Markus


--
Rodrigo Rodrigues da Silva
GNU LibreDWG maintainer
FSF Associate Member #7788
PoliGNU - Grupo de Estudos de Software Livre da Poli/USP
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] diglib test.c fails on 64bit win

[Glynn Clements]

Martin Landa wrote:

> > Do you have LFS active?
> > http://trac.osgeo.org/grass/ticket/930#comment:1
> 
> yes, using
> 
> https://svn.osgeo.org/grass/grass/trunk/mswindows/osgeo4w/package.sh

That should be fixed, then. On Windows, --enable-largefile has no
effect other than breaking the diglib test.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1031: More specific parameter information in command line help

[GRASS GIS]

#1031: More specific parameter information in command line help
--+-
  Reporter:  huhabla  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  7.0.0
 Component:  libgis   | Version:  svn-trunk
Resolution:   |Keywords:  parser, help 
  Platform:  All  | Cpu:  All  
--+-
Comment (by glynn):

 Replying to [comment:5 huhabla]:
 > I have attached a patch for lib/gis/parser_help.c and
 lib/gis/parser_stanndard_options.c which implements the discussed ideas.

 1. The patch makes unnecessary formatting changes, which also contravene
 the GRASS formatting conventions. In general, formatting changes should be
 kept separate from other changes to make it easier to review the substance
 of the changes. But in this case, the formatting changes just shouldn't be
 there.

 2. The updated output is unnecessarily verbose, which is a bad thing IMHO.
 The "required" and "multiple" status can already be determined from the
 "Usage:" section. Non-required options are listed in square brackets,
 while multiple options use the "option=value,..." convention. If you
 really want this format, it should be a separate option, e.g. --verbose-
 help.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] diglib test.c fails on 64bit win

[Martin Landa]

Hi,

2010/4/12 Markus Neteler :
> Do you have LFS active?
> http://trac.osgeo.org/grass/ticket/930#comment:1

yes, using

https://svn.osgeo.org/grass/grass/trunk/mswindows/osgeo4w/package.sh

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] diglib test.c fails on 64bit win

[Markus Neteler]

On Mon, Apr 12, 2010 at 8:40 PM, Martin Landa  wrote:
> Hi,
>
> test in diglib fails (trunk) on MS Windows 64bit
>
> la...@geo1 /osgeo4w/usr/src/grass_trunk/lib/vector/diglib
> $ make
> if [ "" != "" -a -f "".html ] ; then make html ; fi
> ==TEST=
> make test
> make[1]: Entering directory `/osgeo4w/usr/src/grass_trunk/lib/vector/diglib'
> diff OBJ.i686-pc-mingw32/test.tmp test64.ok
> Files OBJ.i686-pc-mingw32/test.tmp and test64.ok differ
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/osgeo4w/usr/src/grass_trunk/lib/vector/diglib'
> make: *** [default] Error 2
>
> Not sure how to fix it. Any pointer welcomed. Martin

Do you have LFS active?
http://trac.osgeo.org/grass/ticket/930#comment:1

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] diglib test.c fails on 64bit win

[Martin Landa]

Hi,

test in diglib fails (trunk) on MS Windows 64bit

la...@geo1 /osgeo4w/usr/src/grass_trunk/lib/vector/diglib
$ make
if [ "" != "" -a -f "".html ] ; then make html ; fi
==TEST=
make test
make[1]: Entering directory `/osgeo4w/usr/src/grass_trunk/lib/vector/diglib'
diff OBJ.i686-pc-mingw32/test.tmp test64.ok
Files OBJ.i686-pc-mingw32/test.tmp and test64.ok differ
make[1]: *** [test] Error 2
make[1]: Leaving directory `/osgeo4w/usr/src/grass_trunk/lib/vector/diglib'
make: *** [default] Error 2

Not sure how to fix it. Any pointer welcomed. Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules

[Doug_Newcomb]

>>Jordan,
>>I've dealt with ERDAS Imagine files larger than 10 GB on a regular 
basis.  I have occasionally tried to >>reproject and merge all of the 1 m 
NAIP imagery tiles  for North Carolina into 1 BigTIFF > 500GB with gdal. 
>> Any parallelizaion work for open source geospatial tools would be 
welcome :-).
>So you "tried" to do that? Does that mean you failed or is the system 
still processing it? :-P I kid, but that is a very large file... it's 
bigger than my current desktop's hard drive. 
Jordan,
It would be a shame to leave those multicore  64 bit processors with 
multi-terabyte hard drives with nothing to challange them.  Just think of 
me as part of the hardware entertainment committee. :-) 
The process ran overnight and finished, I just have not gotten to phase 2 
of that particular project, chopping the resulting image into overlapping 
DOQQ - size images.  I was going to go back and change the projection 
method slightly, hopefully to make it more accurate.  If you're looking 
for big images to play with, go to http://datagateway.nrcs.usda.gov/  and 
select a naip county mosaic of imagery.  The mosaic comes as a MrSid 
format file, but once you uncompress it ( I suggest using gdal's nearblack 
utility ) to ERDAS Imagine format, the resulting image will probably be in 
the multi-gigbyte range per county.

Doug
 

Doug Newcomb 
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the 
official policy of the U.S.Fish and Wildlife Service or Dept. of the 
Interior.   Life is too short for undocumented, proprietary data formats.



Jordan Neumeyer  
Sent by: grass-dev-boun...@lists.osgeo.org
04/08/2010 01:09 AM

To
doug_newc...@fws.gov
cc
GRASS developers list 
Subject
Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules






Thanks guys for putting that into perspective.

On Mon, Apr 5, 2010 at 6:38 PM,  wrote:

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the 
official policy of the U.S.Fish and Wildlife Service or Dept. of the 
Interior.   Life is too short for undocumented, proprietary data formats.

-grass-dev-boun...@lists.osgeo.org wrote: -

To: Jordan Neumeyer 
From: Markus Neteler 
Sent by: grass-dev-boun...@lists.osgeo.org
Date: 04/05/2010 04:06AM
cc: GRASS developers list 
Subject: Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector 
modules

On Sun, Apr 4, 2010 at 3:22 AM, Jordan Neumeyer
 wrote:
> I didn't realize how big the data set could be. What's
> biggest map you've seen?

Our provincial DEM is a 3.5GB Geotiff which is of 48800x58000 size.
Another file which I recently had to import was a 4GB Geotiff with
21550 bands. Finally, in remote sensing, you can quickly generate
quickly files in the multi-GB range.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

~Jordan 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1031: More specific parameter information in command line help

[GRASS GIS]

#1031: More specific parameter information in command line help
--+-
  Reporter:  huhabla  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  7.0.0
 Component:  libgis   | Version:  svn-trunk
Resolution:   |Keywords:  parser, help 
  Platform:  All  | Cpu:  All  
--+-
Comment (by huhabla):

 Replying to [comment:3 martinl]:
 > Replying to [comment:2 huhabla]:
 > > I am aware that some of informations i requests are given by the usage
 string. But IMHO it is more convenient and easier to understand
 (especially for command line beginner) to make these informations also
 available in the help description. My enhancement request is only related
 to the command line. It does not touch the automated gui generation.
 >
 > I think that the beginners usually do not use CLI at all. At least
 'type' and 'required' are redundant info
 >

 > {{{
 >   input   Name of input raster map
 >   status: input
 >   type: cell
 >   required: yes
 > }}}
 >
 > We could use {{{key_desc}}} attribute for defining prompt type.
 >
 > {{{
 > input=raster
 > }}}
 >
 > instead of
 >
 > {{{
 > input=name
 > }}}
 >
 > The question is how to handle 'status' of the options.
 >
 > > The usage string does not always provide the convenient information if
 the parameter is of type raster, vector, volume, integer or float. In many
 modules input and output parameter are named related to the modules
 purpose, the information if its an input or output is only present if you
 read the help page.
 >
 > Right, it could be improved by better {{{key_desc}}} usage.

 Thats a good idea. We could start modifying the default options in
 lib/gis/parser.c adding {{{key_desc}}}. Although this information is
 already specified in the {{{gisprompt}}} string ... we can use the
 convenient naming scheme used in {{{gisprompt}}} for {{{key_desc}}}.

 >
 > > Martin Landa currently renamed in several modules the input and output
 parameter to make clear which of them are inputs or outputs. I.e:
 elevation -> elevation_input, direction -> direction_output, but this is
 IMHO not a good idea. It is redundant information, especially if you are
 using the gui.
 >
 > Right, see [wiki:Grass7/NewFeatures#Renamedoptions Rename options]. Your
 idea about 'status' info seems to be better solution. If you prefer I can
 remove '_input/optput' from paramaters key string.

 Well this is only my humble opinion. In case other developers prefer the
 your naming schema i will accept it. Thats why i would like to discuss
 this topic.

 I would personally prefer to remove '_input/optput' from paramaters key
 string and establish a combination of {{{key_desc}}} and the additional
 "status" parameter in the command line. Maybe we can use a better name
 than "status" ... like "type"? Additionally we can hide the status
 parameter in case "input", "map" and "output" are used as {{{key}}}
 strings?

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1031: More specific parameter information in command line help

[GRASS GIS]

#1031: More specific parameter information in command line help
--+-
  Reporter:  huhabla  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  7.0.0
 Component:  libgis   | Version:  svn-trunk
Resolution:   |Keywords:  parser, help 
  Platform:  All  | Cpu:  All  
--+-
Comment (by huhabla):

 I have attached a patch for lib/gis/parser_help.c and
 lib/gis/parser_stanndard_options.c which implements the discussed ideas.

 Examples:

 {{{
 lib/gis> r.neighbors help

 Description:
  Makes each cell category value a function of the category values assigned
 to the cells around it, and stores new cell values in an output raster map
 layer.

 Keywords:
  raster

 Usage:
  r.neighbors [-ac] input=raster [selection=raster] output=raster
[method=string] [size=value] [title=phrase] [weight=filename]
[gauss=value] [quantile=value] [--overwrite] [--verbose] [--quiet]

 Flags:
   -a   Do not align output with the input
   -c   Use circular neighborhood
  --o   Allow output files to overwrite existing files
  --v   Verbose module output
  --q   Quiet module output

 Parameters:
   input   Name of input raster map
   selection   Name of an input raster map to select the cells which should
 be processed
   type: input
  output   Name for output raster map
  method   Neighborhood operation
   options: average,median,mode,minimum,maximum,stddev,sum,
 variance,diversity,interspersion,quart1,quart3,perc90,
quantile
   default: average
size   Neighborhood size
   default: 3
   title   Title of the output raster map
  weight   Text file containing weights
   gauss   Sigma (in cells) for Gaussian filter
quantile   Quantile to calculate for method=quantile
   options: 0.0-1.0
   default: 0.5
 }}}

 {{{
 lib/gis> r.buffer2 help

 Description:
  Creates a raster map layer showing buffer zones surrounding cells that
 contain non-NULL category values.

 Keywords:
  raster, buffer

 Usage:
  r.buffer2 [-z] input=raster output=raster distances=value[,value,...]
[units=string] [--overwrite] [--verbose] [--quiet]

 Flags:
   -z   Ignore zero (0) data cells instead of NULL cells
  --o   Allow output files to overwrite existing files
  --v   Verbose module output
  --q   Quiet module output

 Parameters:
   input   Name of input raster map
  output   Name for output raster map
   distances   Distance zone(s)
   units   Units of distance
   options: meters,kilometers,feet,miles,nautmiles
   default: meters
 }}}

 {{{
 lib/gis> r.gwflow help

 Description:
  Numerical calculation program for transient, confined and unconfined
 groundwater flow in two dimensions.

 Keywords:
  raster, groundwater flow

 Usage:
  r.gwflow [-f] phead=raster status=raster hc_x=raster hc_y=raster
[q=raster] s=raster [recharge=raster] top=raster bottom=raster
output=raster [vx=raster] [vy=raster] [budget=raster] type=string
[river_bed=raster] [river_head=raster] [river_leak=raster]
[drain_bed=raster] [drain_leak=raster] dt=value [maxit=value]
[error=value] [solver=name] [--overwrite] [--verbose] [--quiet]

 Flags:
   -f   Allocate a full quadratic linear equation system, default is a
 sparse linear equation system.
  --o   Allow output files to overwrite existing files
  --v   Verbose module output
  --q   Quiet module output

 Parameters:
phead   The initial piezometric head in [m]
type: input
   status   Boundary condition status, 0-inactive, 1-active,
 2-dirichlet
type: input
 hc_x   X-part of the hydraulic conductivity tensor in [m/s]
type: input
 hc_y   Y-part of the hydraulic conductivity tensor in [m/s]
type: input
q   Raster map water sources and sinks in [m^3/s]
type: input
s   Specific yield in [1/m]
type: input
 recharge   Recharge map e.g: 6*10^-9 per cell in [m^3/s*m^2]
type: input
  top   Top surface of the aquifer in [m]
type: input
   bottom   Bottom surface of the aquifer in [m]
type: input
   output   The map storing the numerical result [m]
   vx   Calculate and store the groundwater filter velocity vector
 part in x direction [m/s]
type: output
   vy   Calculate and store the groundwater filter velocity vector
 part in y direction [m/s]
type: output
   budget   Store the groundwater budget for each cell [m^3/s]
type: outp

Re: [GRASS-dev] r.buffer python script breaks from within r.fillnulls

[Glynn Clements]

Yann Chemin wrote:

> Hello list,
> Could anybody help?

> Error in atexit._run_exitfuncs:

> NameError: global name 'vecttmp' is not defined

This should be fixed by r41817.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev