[GRASS-dev] Re: [GRASS GIS] #857: add simple neighborhood functions to r.mapcalc

[GRASS GIS]

#857: add simple neighborhood functions to r.mapcalc
--+-
  Reporter:  dickeya  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Raster   | Version:  unspecified  
Resolution:   |Keywords:  r.mapcalc
  Platform:  All  | Cpu:  All  
--+-
Comment (by glynn):

 Replying to [ticket:857 dickeya]:

 > I find myself using a lot of neighbor functions in r.mapcalc, but find
 the syntax to be tedious.  Anything larger than a 3x3 neighborhood and
 writing out "raster[-1,-1] + raster[-1,0] + raster[-1,-1] + ..." is quite
 a task.

 For a sum, use `r.mfilter[.fp]` or `r.neighbors ... weight=...`

 > It's especially hard to do an average when nodata cells are present.

 Convert nulls first in a separate pass.

 > It would be great to have some built in neighborhood functions that
 would handle the math, taking into account nodata cells, and working on a
 rectangular or circular area.  Something like:
 >
 {{{
 neighborhood(raster, width, height, shape, function)
 }}}

 There area a couple of issues with this:

 1. The functions which make up the bulk of r.mapcalc all operate on 1-D
 arrays of size G_window_cols(). So we can't "leverage" the existing
 functions for this purpose.

 2. The above neighborhood() function cannot be implemented using the
 existing function interface; it would need to be a new language construct,
 recognised by the parser, the evaluator, and the I/O code.

 If neighborhood() was a normal function, the above call would result in
 its first argument being the current row of the specified raster, which is
 no good for a neighborhood operation (and all of its other arguments would
 also be row-sized arrays of CELL/FCELL/DCELL values; a numeric literal is
 passed as a row-sized array filled with that value).

 I suspect that it might be more fruitful to add new aggregates to
 r.neighbors.

 That still leaves a gap between what can be implemented with a combination
 of r.mapcalc + r.neighbors + r.mapcalc and what could be implemented with
 a more general language. E.g. there isn't any combination which will allow
 you to calculate:
 {{{
 output[r,c] = sum(input[r+i,c+j]  kernel[i,j])
 }}}
 for any  except multiplication.

 Implementing that specific case in r.mapcalc (or r.neighbors) would be a
 lot of work, but not entirely out of the question. My main concern is that
 it would be the thin end of the wedge; either we draw a line in the sand,
 or we end up with Perl.

 IMHO, if you can't do what you want with r.mapcalc + r.neighbors, you'll
 need a system with enough (virtual) memory to use Matlab/Octave/NumPy.

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

Re: [GRASS-dev] build errors in trunk with make -j 4

[Glynn Clements]

Anne Ghisla wrote:

> > v.krige is a known problem, and isn't specific to parallel builds. It
> > imports modules from wxGUI (even if you just use --help etc), but the
> > "scripts" directory is built before the "gui" directory, so those
> > modules aren't present in $PYTHONPATH when v.krige is initially
> > "built". If you try again when the rest of GRASS has been built, it
> > will work.
> > 
> > Also, v.krige will use the system Python when it may need to use
> > $GRASS_PYTHON (as it uses wxPython). It should probably be split into
> > a front-end script which invokes the "real" script via $GRASS_PYTHON
> > when (and if) grass.parser() returns; then, --html-description would
> > work without requiring wxPython or any wxGUI modules.
> 
> Hi Glynn, Hamish, all,
> 
> the split is done in r40303, and there are no more errors during make.
> It's far than perfect, so testing and comments are welcome :) 
> ATM, the "Plot variogram" in GUI is not functional as it is matter of
> global variables. I'm looking at this now. 
> 
> I don't understand what is the problem with #!/usr/bin/env python.

On Unix (including MacOSX), this will run whichever Python is in the
PATH, which may not work (it may not have wxPython, or it may not have
the correct version of wxPython).

The user can get around that by changing $PATH (although that might
interfere with the use of Python scripts which aren't part of GRASS).

A more significant problem is that the #! line is ignored on Windows,
which uses the .py file association instead, and the user can't easily
change that (the file associations are per-user, not per-process like
environment variables).

Consequently, anything which runs Python scripts which require
wxPython (e.g. g.gui, G_parser()) invokes the script via
$GRASS_PYTHON.

> How can the scripts use GRASS_PYTHON instead? How is the link
> between this and import wx?

scripts/v.krige/v.krige.py shouldn't use wxPython directly or
indirectly (i.e. it shouldn't import wx or any module which uses wx).
Instead, it should execute the GUI script with e.g.:

python = os.getenv("GRASS_PYTHON")
gisbase = os.getenv("GISBASE")
script = os.path.join(gisbase, "etc", "wxpython", "v_krige_wxGUI.py")
args = [python, script] + sys.argv[1:]
os.execvp(python, args)

IOW, Python scripts which may be executed directly by the user from
the command line can only assume the presence of a recent version of
Python (2.4, 2.5 or 2.6) with the standard Python library, plus the
grass.script package. They can't assume that any additional packages
(e.g. wxPython) will be available.

Anything which needs wxPython must be invoked via $GRASS_PYTHON. This
allows the user to specify a suitable version of Python in the event
that the "system" Python isn't suitable.

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

[GRASS-dev] [GRASS GIS] #857: add simple neighborhood functions to r.mapcalc

[GRASS GIS]

#857: add simple neighborhood functions to r.mapcalc
-+--
 Reporter:  dickeya  |   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  Raster   | Version:  unspecified  
 Keywords:  r.mapcalc|Platform:  All  
  Cpu:  All  |  
-+--
 I find myself using a lot of neighbor functions in r.mapcalc, but find the
 syntax to be tedious.  Anything larger than a 3x3 neighborhood and writing
 out "raster[-1,-1] + raster[-1,0] + raster[-1,-1] + ..." is quite a task.
 It's especially hard to do an average when nodata cells are present.

 It would be great to have some built in neighborhood functions that would
 handle the math, taking into account nodata cells, and working on a
 rectangular or circular area.  Something like:

 {{{
 neighborhood(raster, width, height, shape, function)
 }}}

-- 
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] #842: wx location wizard: spincontrol busted for UTM zone

[GRASS GIS]

#842: wx location wizard: spincontrol busted for UTM zone
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard, utm 
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by hamish):

 for 6.4.0 a regular text entry box should be fine; we can keep working on
 the spincontrol in the dev branches and have it ready for 6.4.1.


 Hamish

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

Re: [GRASS-dev] Issues of 6.5 build on WinXP

[Martin Landa]

Hi,

2010/1/7 Jan Tošovský :
> I've built 6.5 from svn 40297 and adding map layers is broken again. Now
> both vector and raster!

fixed in r40307.

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] Issues of 6.5 build on WinXP

[Jan Tošovský]

> > 2009/12/28 Jan Tošovský :
> > > 1) I cannot add a new vector map layer. Only a dummy one is 
> > added without
> > > the standard option dialog. All corresponding messages from 
> > the Command
> > > output tab can be found at the bottom of this e-mail. 
> > Raster maps are Ok.
> > 
> > I commented out problematic code in r40191. Now should work.
> > 
> > Martin
> 
> Wow, it works as expected (I can add a vector map via GUI)!

I've built 6.5 from svn 40297 and adding map layers is broken again. Now
both vector and raster!

Jan

=== raster log 
Traceback (most recent call last):
  File
"C:/OSGeo4W/apps/grass/grass-6.5.svn/etc/wxpython/wxgui.py",
line 1244, in OnAddRaster

self.AddRaster(event)
  File
"C:/OSGeo4W/apps/grass/grass-6.5.svn/etc/wxpython/wxgui.py",
line 1369, in AddRaster

self.curr_page.maptree.AddLayer('raster')
  File "c:/OSGeo4W/usr/src/grass6-devel/dist.i686-pc-
mingw32/etc/wxpython/gui_modules/wxgui_utils.py", line 794,
in AddLayer

self.PropertiesDialog(layer, show=True)
  File "c:/OSGeo4W/usr/src/grass6-devel/dist.i686-pc-
mingw32/etc/wxpython/gui_modules/wxgui_utils.py", line 862,
in PropertiesDialog

parentframe=self)
  File "C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\wxpython\gui
_modules\menuform.py", line 1811, in ParseCommand

get_dcmd=get_dcmd, layer=layer)
  File "C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\wxpython\gui
_modules\menuform.py", line 810, in __init__

self.goutput.SetSashPosition(int(self.GetSize()[1] * .75))
AttributeError
:
'NoneType' object has no attribute 'SetSashPosition'

= vector log 

Traceback (most recent call last):
  File
"C:/OSGeo4W/apps/grass/grass-6.5.svn/etc/wxpython/wxgui.py",
line 1301, in OnAddVector

self.AddVector(event)
  File
"C:/OSGeo4W/apps/grass/grass-6.5.svn/etc/wxpython/wxgui.py",
line 1403, in AddVector

self.curr_page.maptree.AddLayer('vector')
  File "c:/OSGeo4W/usr/src/grass6-devel/dist.i686-pc-
mingw32/etc/wxpython/gui_modules/wxgui_utils.py", line 794,
in AddLayer

self.PropertiesDialog(layer, show=True)
  File "c:/OSGeo4W/usr/src/grass6-devel/dist.i686-pc-
mingw32/etc/wxpython/gui_modules/wxgui_utils.py", line 891,
in PropertiesDialog

parentframe=self)
  File "C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\wxpython\gui
_modules\menuform.py", line 1811, in ParseCommand

get_dcmd=get_dcmd, layer=layer)
  File "C:\OSGeo4W\apps\grass\grass-6.5.svn\etc\wxpython\gui
_modules\menuform.py", line 810, in __init__

self.goutput.SetSashPosition(int(self.GetSize()[1] * .75))
AttributeError
:
'NoneType' object has no attribute 'SetSashPosition'

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

Re: [GRASS-dev] 6.4.0 never-ending story

[Michael Barton]

On Jan 7, 2010, at 3:27 AM, grass-dev-requ...@lists.osgeo.org wrote:

> Date: Thu, 07 Jan 2010 11:26:59 +0100
> From: Markus Metz 
> Subject: Re: [GRASS-dev] 6.4.0 never-ending story
> To: Glynn Clements 
> Cc: GRASS developers list 
> Message-ID: <4b45b6f3.9050...@googlemail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 
> Glynn Clements wrote:
>> Markus Metz wrote:
>> 
>> 
>>> For the final version I would very much like to see a reasonably stable
>>> Windows version, and it seems realistic to get this out soon.
>>> 
>> The Windows version is hampered by a lack of Windows developers. Most
>> of the Windows development is being done by people who use Linux or
>> MacOSX as their main platform and occasionaly build and test on
>> Windows as a favour to Windows users.
>> 
>> It's also hampered by a tendency for developers to try to "paper over"
>> Windows problems with quick hacks rather than getting to the root of
>> the problem and developing robust solutions.
>> 
> I am willing to help and to develop robust solutions where I can (C
> modules), but I have only XP, not Vista, so I can't fix Vista-specific
> problems. Can you make a little list of these quick hacks that need to
> be re-evaluated? Maybe just re-open the corresponding tickets?
> 
> Markus M


Markus,

Thanks very much. Your help is much appreciated!

Michael

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

[GRASS-dev] Re: [GRASS GIS] #842: wx location wizard: spincontrol busted for UTM zone

[GRASS GIS]

#842: wx location wizard: spincontrol busted for UTM zone
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard, utm 
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by cmbarton):

 Replying to [comment:13 hamish]:
 > Replying to [comment:12 cmbarton]:
 > > OK. I just attached a new patch for GRASS 6.4:
 > > location_wizard.patch2. It's like the first one, patched against
 > > the svn from the root of your source tree. Hopefully, this will
 > > do the trick.
 >
 > no dice.
 >
 > I can spin it, it loops past 60 and back to 1, but if I touch the
 up/down controls at all or type in a number I get a pop up window that
 says "Something is missing!  You must enter a value for Projection Zone
 (1-60)". If I don't touch it at all I can go past and create a location
 for UTM zone 30.
 >
 > after I press ok on the error popup, this appears in the terminal:
 > {{{
 > Traceback (most recent call last):
 >   File "/usr/src/grass/svn/releasebranch_6_4/dist.x86_64-unknown-linux-
 gnu/etc/wxpython/gui_modules/location_wizard.py", line 769, in
 OnPageChange
 > if int(self.pval[num]) > 60 or int(self.pval[num]) < 1:
 > ValueError: invalid literal for int() with base 10: ''
 > }}}
 >
 > If I put some debug messages directly before L769,
 > {{{
 > num = self.utmzoneNum
 > print "num=",num
 >   print "self.utmzoneNum=",self.utmzoneNum
 >   print "self.pval[num]=",self.pval[num]
 > }}}
 >
 > I get this on the terminal after pressing ok to the error popup message:
 >
 > {{{
 > num= 0
 > self.utmzoneNum= 0
 > self.pval[num]=
 > }}}
 > Hamish

 Drat!

 This is a page changing validator that someone else added since last I
 worked on the location wizard. Good idea, but it's wrong. I noticed but it
 hadn't been causing errors so I left it alone, wanting to mess with this
 as little as possible. I guess I have to fix it too.

 Michael

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

Re: [GRASS-dev] build errors in trunk with make -j 4

[Anne Ghisla]

On Thu, 2010-01-07 at 00:45 +, Glynn Clements wrote:
> Hamish wrote:
> 
> > in trunk I get errors detected building wxpython and v.kridge, but if I
> > cd into their dirs and re-run make they build ok.
> > 
> > are the pre-deps in their Makefiles healthy?
> 
> v.krige is a known problem, and isn't specific to parallel builds. It
> imports modules from wxGUI (even if you just use --help etc), but the
> "scripts" directory is built before the "gui" directory, so those
> modules aren't present in $PYTHONPATH when v.krige is initially
> "built". If you try again when the rest of GRASS has been built, it
> will work.
> 
> Also, v.krige will use the system Python when it may need to use
> $GRASS_PYTHON (as it uses wxPython). It should probably be split into
> a front-end script which invokes the "real" script via $GRASS_PYTHON
> when (and if) grass.parser() returns; then, --html-description would
> work without requiring wxPython or any wxGUI modules.

Hi Glynn, Hamish, all,

the split is done in r40303, and there are no more errors during make.
It's far than perfect, so testing and comments are welcome :) 
ATM, the "Plot variogram" in GUI is not functional as it is matter of
global variables. I'm looking at this now. 

I don't understand what is the problem with #!/usr/bin/env python. How
can the scripts use GRASS_PYTHON instead? How is the link between this
and import wx?
Thanks in advance for any hint and sorry if I'm missing something
important.

best,
Anne


signature.asc
Description: This is a digitally signed message part
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass

[GRASS GIS]

#809: v.db.addtable consistently fails in winGrass
--+-
  Reporter:  JonBall  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  critical |   Milestone:  6.4.0
 Component:  Vector   | Version:  svn-releasebranch64  
Resolution:   |Keywords:  v.db.addtable, wingrass  
  Platform:  MSWindows Vista  | Cpu:  x86-64   
--+-
Comment (by hamish):

 stuff to audit, both for spaces in path names and for correct column
 parsing when fs=':' and a path like "C:\Documents and Settings" is being
 parsed.

 {{{
 lib/db/
 dbmi_base/login.c:  ret = sscanf(buf, "%[^ ] %[^ ] %[^ ] %[^ ]", dr,
 db, usr, pwd);
 dbmi_base/dbmscap.c:if (sscanf(buf, "%[^:]:%[^:]:%[^:\n]", name,
 startup, comment) == 3)
 dbmi_base/dbmscap.c:else if (sscanf(buf, "%[^:]:%[^:\n]", name,
 startup) == 2)


 lib/vector/
 Vlib/field.c:   ndef = sscanf(buf, "%s %s %s %s %s", fldstr, tab, col, db,
 drv);
 }}}


 Hamish

-- 
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] #842: wx location wizard: spincontrol busted for UTM zone

[GRASS GIS]

#842: wx location wizard: spincontrol busted for UTM zone
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard, utm 
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by hamish):

  * priority:  major => critical

-- 
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] #73: r.out.gdal tiff output does not work

[GRASS GIS]

#73: r.out.gdal tiff output does not work
-+--
  Reporter:  helena  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.1
 Component:  Raster  | Version:  svn-trunk
Resolution:  |Keywords:  r.out.gdal, tiff 
  Platform:  All | Cpu:  All  
-+--
Changes (by hamish):

  * milestone:  6.5.0 => 6.4.1

-- 
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] #198: v.in.ascii: column scanning is borked

[GRASS GIS]

#198: v.in.ascii: column scanning is borked
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.1
 Component:  Vector| Version:  svn-develbranch6 
Resolution:|Keywords:  v.in.ascii   
  Platform:  All   | Cpu:  All  
---+
Changes (by hamish):

  * milestone:  => 6.4.1

-- 
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] #335: export floats and doubles with correct precision

[GRASS GIS]

#335: export floats and doubles with correct precision
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  task  |  Status:  new  
  Priority:  critical  |   Milestone:  6.4.1
 Component:  default   | Version:  svn-develbranch6 
Resolution:|Keywords:  precision
  Platform:  All   | Cpu:  All  
---+
Changes (by hamish):

  * milestone:  => 6.4.1

-- 
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] #713: OSGeo4W patch for g3d lib

[GRASS GIS]

#713: OSGeo4W patch for g3d lib
---+
  Reporter:  neteler   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.1
 Component:  default   | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Changes (by hamish):

  * milestone:  => 6.4.1

-- 
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] #714: spawn.c differences between 6.4 and 6.5

[GRASS GIS]

#714: spawn.c differences between 6.4 and 6.5
---+
  Reporter:  neteler   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.1
 Component:  default   | Version:  6.4.0 RCs
Resolution:|Keywords:   
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Changes (by hamish):

  * milestone:  => 6.4.1

-- 
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] #741: Small enhancements and bug fixes for v.out.ogr

[GRASS GIS]

#741: Small enhancements and bug fixes for v.out.ogr
--+-
  Reporter:  benducke |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.1
 Component:  Vector   | Version:  svn-develbranch6 
Resolution:   |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by hamish):

  * milestone:  => 6.4.1

-- 
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] #842: wx location wizard: spincontrol busted for UTM zone

[GRASS GIS]

#842: wx location wizard: spincontrol busted for UTM zone
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  svn-develbranch6 
Resolution:  |Keywords:  location wizard, utm 
  Platform:  Linux   | Cpu:  x86-64   
-+--
Comment (by hamish):

 Replying to [comment:12 cmbarton]:
 > OK. I just attached a new patch for GRASS 6.4:
 > location_wizard.patch2. It's like the first one, patched against
 > the svn from the root of your source tree. Hopefully, this will
 > do the trick.

 no dice.

 I can spin it, it loops past 60 and back to 1, but if I touch the up/down
 controls at all or type in a number I get a pop up window that says
 "Something is missing!  You must enter a value for Projection Zone
 (1-60)". If I don't touch it at all I can go past and create a location
 for UTM zone 30.

 after I press ok on the error popup, this appears in the terminal:
 {{{
 Traceback (most recent call last):
   File "/usr/src/grass/svn/releasebranch_6_4/dist.x86_64-unknown-linux-
 gnu/etc/wxpython/gui_modules/location_wizard.py", line 769, in
 OnPageChange
 if int(self.pval[num]) > 60 or int(self.pval[num]) < 1:
 ValueError: invalid literal for int() with base 10: ''
 }}}

 If I put some debug messages directly before L769,
 {{{
 num = self.utmzoneNum
 print "num=",num
 print "self.utmzoneNum=",self.utmzoneNum
 print "self.pval[num]=",self.pval[num]
 }}}

 I get this on the terminal after pressing ok to the error popup message:

 {{{
 num= 0
 self.utmzoneNum= 0
 self.pval[num]=
 }}}
 Hamish

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

Re: [GRASS-dev] 6.4.0 never-ending story

[Markus Metz]

Glynn Clements wrote:

Markus Metz wrote:

  
For the final version I would very much like to see a reasonably stable 
Windows version, and it seems realistic to get this out soon.


The Windows version is hampered by a lack of Windows developers. Most
of the Windows development is being done by people who use Linux or
MacOSX as their main platform and occasionaly build and test on
Windows as a favour to Windows users.

It's also hampered by a tendency for developers to try to "paper over"
Windows problems with quick hacks rather than getting to the root of
the problem and developing robust solutions.
  
I am willing to help and to develop robust solutions where I can (C 
modules), but I have only XP, not Vista, so I can't fix Vista-specific 
problems. Can you make a little list of these quick hacks that need to 
be re-evaluated? Maybe just re-open the corresponding tickets?


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