gmane.comp.gis.grass.devel

Re: [GRASS GIS] #1584: error in r.walk help page

GRASS GIS — 2012-05-25T22:25:03

#1584: error in r.walk help page
--------------------+-------------------------------------------------------
 Reporter:  hamish  |       Owner:  grass-dev< at >…              
     Type:  defect  |      Status:  new                      
 Priority:  major   |   Milestone:  6.4.3                    
Component:  Docs    |     Version:  unspecified              
 Keywords:  r.walk  |    Platform:  All                      
      Cpu:  All     |  
--------------------+-------------------------------------------------------

Comment(by dkavanagh):

 My note applies to 6.5 and 7.0. The Langmuir correction applies to all
 versions.

 Replying to [comment:1 dkavanagh]:
 > There is also a mistake in the Standard Directions figure in the
 Movement Direction section. 90 should be immediately below x and the zero
 should be removed.
 >
 > Replying to [ticket:1584 hamish]:
 > > one from Agustin:
 > >
 > > {{{
 > > the documentation in r.walk is wrong. It says:
 > > "The default values for a, b, c, d are

Re: [GRASS GIS] #1664: Texts in command dialogs aregarbled

GRASS GIS — 2012-05-25T22:21:47

#1664: Texts in command dialogs are garbled
--------------------------------------------+-------------------------------
 Reporter:  wenzeslaus                      |       Owner:  grass-dev< at >…              
     Type:  defect                          |      Status:  new                      
 Priority:  normal                          |   Milestone:                           
Component:  Translations                    |     Version:  unspecified              
 Keywords:  encoding translation, wingrass  |    Platform:  MSWindows 7              
      Cpu:  Unspecified                     |  
--------------------------------------------+-------------------------------
Changes (by hamish):

  * keywords:  encoding translation => encoding translation, wingrass
  * component:  Default => Translations


Comment:

 can you provide a screenshot?
 which version of GRASS?
 which wingrass package?
 which language(s) did you try?
 what language is Windows set up to use?


 thanks,
 Hamish

Re: [GRASS GIS] #1584: error in r.walk help page

GRASS GIS — 2012-05-25T21:44:46

#1584: error in r.walk help page
--------------------+-------------------------------------------------------
 Reporter:  hamish  |       Owner:  grass-dev< at >…              
     Type:  defect  |      Status:  new                      
 Priority:  major   |   Milestone:  6.4.3                    
Component:  Docs    |     Version:  unspecified              
 Keywords:  r.walk  |    Platform:  All                      
      Cpu:  All     |  
--------------------+-------------------------------------------------------

Comment(by dkavanagh):

 There is also a mistake in the Standard Directions figure in the Movement
 Direction section. 90 should be immediately below x and the zero should be
 removed.

 Replying to [ticket:1584 hamish]:
 > one from Agustin:
 >
 > {{{
 > the documentation in r.walk is wrong. It says:
 > "The default values for a, b, c, d are those proposed by Langmuir
 > (0.72, 6.0, 1.9998, -1.9998)"
 > and it should say:
 > "The default values for a, b, c, d are those propos

Re: broken stuff in vector modules

Michael Barton — 2012-05-25T20:11:13

Thanks Anna,

I'm traveling in Europe this month, teaching and doing research. So I don't really have the facilities to do bug fixing at the moment. I appreciate the quick fix. I'll be able to use it when I get back home and can compile again.

Cheers
Michael

On May 25, 2012, at 9:29 AM, Anna Kratochvílová wrote:


_____________________
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Re: Image Segmentation - Summer of Code

Eric Momsen — 2012-05-25T16:44:50

Follow up on some of the questions below.

Also, I posted a brief project report to the other mail list:
http://lists.osgeo.org/pipermail/soc/2012-May/001747.html

On Fri, May 25, 2012 at 3:47 AM, Markus Metz <
markus.metz.giswork< at >googlemail.com> wrote:

interior borders, to make sure segmentation can continue across those
artificial boundaries.


with diagonal neighbors, you could end up with two larger regions only
joined at a diagonal in the center - but maybe that is over thinking what
will occur with real images)

Finding pixel neighbors will be just the first step.  After the segments
are growing larger, the both the center region can be irregular (not just
one pixel), and the set of possible neighbors will include irregular shapes
and pixels.

So I guess this is probably similar to finding a 1 pixel buffer, then
reducing those pixels to just check the unique segments.... so I'll look at
r.buffer as well.


get online.


Eric




_______________________________________________
grass-dev mailing list
gr

Re: [GRASS GIS] #1663: Tabs in C source code

GRASS GIS — 2012-05-25T15:19:50

#1663: Tabs in C source code
-------------------------+--------------------------------------------------
  Reporter:  wenzeslaus  |       Owner:  grass-dev< at >…              
      Type:  defect      |      Status:  closed                   
  Priority:  normal      |   Milestone:                           
 Component:  Default     |     Version:  unspecified              
Resolution:  invalid     |    Keywords:  indent tabs spaces       
  Platform:  All         |         Cpu:  All                      
-------------------------+--------------------------------------------------
Changes (by glynn):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 Replying to [ticket:1663 wenzeslaus]:

 > But C source files contains both spaces and tabs.

 This is not a problem, so long as the code is indented correctly for
 8-column tabs. Trying to enforce a spaces-only policy isn't worth the
 trouble.

 If you configure your text editor with something other than 8-column tabs,
 you're

pyGRASS: Report #1

Pietro — 2012-05-25T14:57:12

Hi all!

as reported in the new web page [0] of the pyGRASS project, at the moment you
can interact with a raster map in this way (read-only): ::

    # import the raster function
    >>> import obj
    # instantiate a Raster
    >>> dtm = obj.Raster('dtm')
    # open the raster in read mode 'r'
    >>> dtm.open()
    # get access
    >>> for row in dtm[:5]: print(row[:3])
    [718.0910034179688, 717.8709716796875, 717.551025390625]
    [718.0910034179688, 717.8709716796875, 717.551025390625]
    [718.0910034179688, 717.8709716796875, 717.551025390625]
    [718.0910034179688, 717.8709716796875, 717.551025390625]
    [718.0910034179688, 717.8709716796875, 717.551025390625]
    >>> dtm[5][:3]
    [718.051025390625, 717.7310180664062, 717.4210205078125]
    >>> dtm.close()

Any hint or suggestion are welcome! The Raster class use only the grass ctypes
library.

This report and the following ones will be available to the wiki page [1].

[0] http://code.google.com/p/pygrass/
[1]
http://grass.osgeo.org/wiki/GRASS_

"d.rast -h" adds a map layer in wxGUI

Nikos Alexandris — 2012-05-25T14:38:15

Hi!

In grass_trunk (compiled today), the command "d.rast -h" executed in the
"Command console" tab, within GRASS GIS Layer Manager, adds a "-h" entry in
the "Map layers" tab/list.

Of course no map "-h" does exist. Moreover, it would be nice for the wx-
command-console to automatically translate "-h" to "-help".

Thanks, Nikos

ps- playing a bit around with the latest wxGUI (within from/using
grass_trunk). I wish many of the rich features in the (may I call it) wx-
command-console (?) had been available long ago within the "default" grass-
shell :-/

[GRASS GIS] #1664: Texts in command dialogs are garbled

GRASS GIS — 2012-05-25T09:09:17

#1664: Texts in command dialogs are garbled
----------------------------------+-----------------------------------------
 Reporter:  wenzeslaus            |       Owner:  grass-dev< at >…              
     Type:  defect                |      Status:  new                      
 Priority:  normal                |   Milestone:                           
Component:  Default               |     Version:  unspecified              
 Keywords:  encoding translation  |    Platform:  MSWindows 7              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------
 Generated command dialogs show garbled texts. It does not apply to buttons
 and other strings which comes directly from Python code. It applies to
 string which comes from module option description (but with some
 translation activated).

 Acutes and other diacritics signs are shown before letters. However this
 is detail and it can differ between languages/encodings.

 It is necessary

Re: Image Segmentation - Summer of Code

Markus Metz — 2012-05-25T08:47:02

There are two tile cache mechanisms in GRASS, once the read-only cache
used by r.proj and i.rectify, once the more flexible and read/write
cache of the segment library. In this case I would opt for the segment
library because the data stored there can be any size, determined on
run-time. You could e.g. put all input bands (all maps in a group)
into one array and cache that array with the segment lib. The size of
the array corresponds thus to the number of input bands.


What neighbors do you mean? The eight adjacent neighbors or neighbours
in a larger neighborhood? You could look at r.neighbors for a general
solution of any neighborhood size and at r.watershed for the eight
adjacent neighbors.


What functions exactly do you have in mind?
I hope the above comments help a bit. A lot of useful functionality is
implemented not only in libraries but also in modules.

We address items on the agenda more in an ad-hoc approach, no fixed
schedule, but you can contact us any time.

Hope that helps,

Markus M

[GRASS GIS] #1663: Tabs in C source code

GRASS GIS — 2012-05-25T08:20:23

#1663: Tabs in C source code
--------------------------------+-------------------------------------------
 Reporter:  wenzeslaus          |       Owner:  grass-dev< at >…              
     Type:  defect              |      Status:  new                      
 Priority:  normal              |   Milestone:                           
Component:  Default             |     Version:  unspecified              
 Keywords:  indent tabs spaces  |    Platform:  All                      
      Cpu:  All                 |  
--------------------------------+-------------------------------------------
 I assume that GRASS C source code should be indented with spaces, more
 precisely with spaces only. And more over, mixing tabs and spaces is a bad
 practice.

 But C source files contains both spaces and tabs.

 For example changeset r47676 "code layout fixes with indent" only adds
 another tabs which are mixed with spaces. Here is a part of file worker.c
 (http://trac.osgeo.org/grass/browser/grass/trunk/raster/r

[GRASS GIS] #1662: Caching bug in 3D raster librarywith large data

GRASS GIS — 2012-05-25T07:59:31

#1662: Caching bug in 3D raster library with large data
-------------------------------------+--------------------------------------
 Reporter:  huhabla                  |       Owner:  grass-dev< at >…              
     Type:  defect                   |      Status:  new                      
 Priority:  critical                 |   Milestone:  7.0.0                    
Component:  Raster3D                 |     Version:  svn-trunk                
 Keywords:  3D raster, tiles, cache  |    Platform:  Linux                    
      Cpu:  x86-32                   |  
-------------------------------------+--------------------------------------
 There is a strange bug that appeared on an Intel Atom netbook while
 converting a list of raster maps into a 3D raster map. Operating system is
 a 32 Bit Ubuntu linux:

 {{{
 GRASS 7.0.svn (etopo_epsg4326): t.rast.to.rast3 input=temptest
 output=temptest
  100%
 Creating 3D raster map
 ERROR: Rast3d_cache_hash_remove_name: name not in hashtable
 ERROR: Un

Re: reducing screen clutter

Rainer M Krug — 2012-05-25T07:43:02

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/05/12 17:57, Benjamin Ducke wrote:

This would be a good (and intuitive) suggestion.

Cheers,

Rainer



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+/OAYACgkQoYgNqgF2egoOywCdHAl1MxCI4Fi4Ituw2IDQL5TU
0r4An3TpuTLw2450rv56I9i9U4hh9vL2
=FSsI
-----END PGP SIGNATURE-----

Re: broken stuff in vector modules

Anna Kratochvílová — 2012-05-25T07:29:27

Hi,

On Wed, May 23, 2012 at 4:43 PM, Michael Barton <Michael.Barton< at >asu.edu> wrote:


This should be fixed now. If you find this bug elsewhere, tell me or
you can fix it easily yourself.

Anna

Re: reducing screen clutter

2012-05-24T19:45:57

So long as this does not impair my ability to process the same command for
multiple data layers in multiple ways simultaneously.....

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb< at >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-bounces< at >lists.osgeo.org wrote: -----


To: GRASS developers grass-developers <grass-dev< at >lists.osgeo.org>
From: Michael Barton <michael.barton< at >asu.edu>
Sent by: grass-dev-bounces< at >lists.osgeo.org
Date: 05/24/2012 05:19AM
Subject: [GRASS-dev] reducing screen clutter

Periodically, there are complaints about 'screen clutter' with GRASS. I
realized yesterday that a big cause of this is that each time a module is
called, a new instance of its dialog opens. So if you use v.bu

Image Segmentation - Summer of Code

Eric Momsen — 2012-05-24T17:29:29

Hi,

Thanks everyone for the nice greetings, I'm very impressed with how polite
and helpful the GRASS community is.

There is a wiki [1] and source code repository [2] for the Image
Segmentation - Google Summer of Code project.

The mentors for the project have already provided a lot of advice, if there
is anyone else with an interest in segmentation you are welcome to add to
the Specifications or other areas of the wiki.

For the "code" I have started an outline, but I think there are still too
many questions to call it pseudocode yet!.  Many of the questions are for
myself to research and answer.  Of course, I welcome input and suggestions
for all of it, but some of the bigger questions are:

1.  How to best deal with images that are larger then available memory.  (I
assume too much disk I/O would be slow, but simple tiling could lead to
poor segmentation at the tile borders.)

2.  How to find neighbors. (Is this already available somewhere in GRASS?)

3.  Would any functions would be useful as a general l

Re: reducing screen clutter

Benjamin Ducke — 2012-05-24T15:57:30

This sounds like a familiar problem. Most file/web
browsers let the choose whether to stay in the same
window or open a new one when browsing to a new
location.

So perhaps there should be an option in the GUI to
"allow multiple windows per module" which could be
set to "false" by default?

Ben

On 05/24/2012 05:34 PM, Paulo van Breugel wrote:

Re: reducing screen clutter

Paulo van Breugel — 2012-05-24T15:34:38

True that having the same dialogue open several times can be annoying. But
not always, it may come in handy if you want to run the same module several
times with different parameters (run at the same time, or prepare one while
the other is still running; btw, I actually never checked how it is handled
if you run the same function twice in parallel, are they run at the same
time on different cores?).




On Thu, May 24, 2012 at 4:18 PM, Michael Barton <Michael.Barton< at >asu.edu>wrote:

_______________________________________________
grass-dev mailing list
grass-dev< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: reducing screen clutter

Michael Barton — 2012-05-24T14:18:21

This is one way, but not exactly what I was talking about. In fact, sometimes it is very useful to keep a dialog box open to rerun the same module repeatedly with different parameters.

What I meant is that once it is open, GRASS should not open additional dialogs for the same module but simply reuse the one that is open. That way you never get 5 windows for v.distance, only 1--even if you leave it open.

Michael



On May 24, 2012, at 2:26 PM, Moritz Lennert wrote:


_____________________
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Re: reducing screen clutter

Moritz Lennert — 2012-05-24T12:26:38


The tick box already exists, so you are suggesting to make closing the 
dialog the default ? I find it quite useful, especially for newbies, to 
have the dialog open and be able to correct wrong input, instead of 
having to fill the whole dialog out again... But I can confirm that it 
takes some teaching to make them aware of that feature and avoid that 
they open the same command ten times. ;-)

Moritz

RE: reducing screen clutter

Chemin, Yann (IWMI — 2012-05-24T10:25:24

Maybe we can modify the GUI preferences:

Default: All dialog boxes close after a run is complete
In Preferences: Tick this box if you want the dialog boxes to be closed manually (i.e. stay after a run)

something that direction might meet both edges.



________________________________
From: grass-dev-bounces< at >lists.osgeo.org [grass-dev-bounces< at >lists.osgeo.org] on behalf of Michael Barton [michael.barton< at >asu.edu]
Sent: Thursday, May 24, 2012 3:49 PM
To: GRASS developers grass-developers
Subject: [GRASS-dev] reducing screen clutter

Periodically, there are complaints about 'screen clutter' with GRASS. I realized yesterday that a big cause of this is that each time a module is called, a new instance of its dialog opens. So if you use v.buffer but don't close the dialog, and then call v.buffer again GRASS opens a second v.buffer dialog...and a third and a fourth, etc. So there seems to be the need to have the wxPython parser module to just bring the window for a module to the front if it is already open instead