Re: [GRASS-dev] grass mapswipe issue

2013-07-08 Thread Anna Petrášová
Hi,


On Sun, Jul 7, 2013 at 2:42 PM, Yann Chemin yche...@gmail.com wrote:

 Hi

 mapswipe is having a small issue,
 when i start it from a zoomed area with a single map layer selected,
 then I selected a second map layer, the second map layer does not have
 the zzomed extents of the first one...

 a screenshot available on request...


sorry, I don't have this problem on my computer, but I suggest to have a
look at it in Prague.

Anna



 --
 
 ___
 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

Re: [GRASS-dev] [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool

2013-07-08 Thread Štěpán Turek



span style='color: rgb(51, 51, 51); font-family: helvetica, arial, sans-serif; 
line-height: 19px; white-space: normal;'Hi Michael,/spanbr

Are you planning to use wxPlot for the scatterplot display? This provides a 
consistent graphical  interface with the other plotting modules.


currently matplotlib [1] is used. The library provides events [2], which 
allows you to find out where the user clicked. With this information you are
able to keep track of selected regions in a scatter plot.




Best,

Stepan

 

 

[1] http://matplotlib.org/(http://matplotlib.org/)


[2] http://matplotlib.org/users/event_handling.html
(http://matplotlib.org/users/event_handling.html)





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

Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column names

2013-07-08 Thread GRASS GIS
#2012: d.vect wx module GUI forgets column names
-+--
  Reporter:  hamish  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  6.4.4
 Component:  wxGUI   | Version:  svn-trunk
Resolution:  fixed   |Keywords:  d.vect   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by annakrat):

  * status:  new = closed
  * resolution:  = fixed


Comment:

 Replying to [comment:2 hamish]:
  tested in trunk, now remembers size_col and rotation_column. thanks.
 drop down menu and no-db issues also seem to be fixed.

 so I am closing this ticket as fixed
 
  during testing it's still printing a traceback error to the terminal
 though:
  {{{
  (wxgui.py:3206): Pango-CRITICAL **: pango_layout_get_cursor_pos:
 assertion `index = 0  index = layout-length' failed
  }}}

 Usually, this is harmless. It's not easy to fix this, so if you consider
 this as a problem open a new ticket (with minor priority).

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/2012#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

[GRASS-dev] [GRASS GIS] #2023: r.li.edgedensity

2013-07-08 Thread GRASS GIS
#2023: r.li.edgedensity
--+-
 Reporter:  matmar|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.3
Component:  Raster| Version:  unspecified  
 Keywords:  r.li.edgedensity  |Platform:  Linux
  Cpu:  x86-64|  
--+-
 r.li.edgedensity doesn't work using a configuration file (generated with
 r.li.setup) with a vector map to overlay. Attached you can find the
 generated configuration file.

 The r.li.edgedensity error is:

 

 GRASS 6.4.3svn (WGS_84):~  r.li.edgedensity map=globcover conf=landscape
 output=edge_den_map --o
 ERROR: Program error, worker() toReceive.type=-1451052184
 Segmentation fault (core dumped)
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184
 ERROR: Program error, worker() toReceive.type=-1451052184

 

 Thanks, Matteo

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/2023
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] [GRASS GIS] #2024: r.li.setup

2013-07-08 Thread GRASS GIS
#2024: r.li.setup
+---
 Reporter:  matmar  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  Raster  | Version:  svn-releasebranch64  
 Keywords:  r.li.setup  |Platform:  Linux
  Cpu:  x86-64  |  
+---
 I've noticed a difference between the configuration file I generated 3
 weeks ago using vector map to overlay with the one I've just generated
 (same procedure, again using vector map to overlay). In detail, the second
 seems almost empty, without any specified regions.
 I've upgraded grass a couple of times between the two configuration files.
 I've attached the two files (old and new).

 Thanks, Matteo

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/2024
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [GRASS GIS] #2023: r.li.edgedensity

2013-07-08 Thread GRASS GIS
#2023: r.li.edgedensity
--+-
 Reporter:  matmar|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.3
Component:  Raster| Version:  svn-releasebranch64  
 Keywords:  r.li.edgedensity  |Platform:  Linux
  Cpu:  x86-64|  
--+-
Changes (by matmar):

  * version:  unspecified = svn-releasebranch64


-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/2023#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

Re: [GRASS-dev] i.segment on panchromatic band of Worldview 2 scene: what resources are necessary to complete segmentation ?

2013-07-08 Thread Moritz Lennert
After some improvements to the module by MarkusM, I tried again during 
the night, but it got stuck again with heavy swapping going on. I'm 
definitively giving up to segment the panchromatic image in its entirety 
on my machine.


Question: Does the memory= parameter limit total memory usage of the 
module, or does it only limit the memory usage for certain parts of it ?


On 07/07/13 11:52, Yann Chemin wrote:

1 - Find a faster CPU machine with 16Gb RAM and a SSD for a start, it
will be better,
Also if you have the opportunity check that the RAM is a 1800MHz one,
details like this may actually add your computation performance.


I'll try on a machine with more RAM and better CPU (i7 instead of i3).



2 - Cut in pieces (See Markus Comment about supercomputing) and run 4
quads on 4 CPUs instead of one large image in one CPU.


I can do that. Will this have any influence on segmentation results ?



3 - Recode i.segment to work natively on heterogeneous computers...
(would be fun!)


Would parallization help ? Should i.segment be included into the list of 
OpenMP candidates:

http://grasswiki.osgeo.org/wiki/OpenMP#Candidates ?

Moritz


Good luck!

On 4 July 2013 14:10, Moritz Lennertmlenn...@club.worldonline.be  wrote:

Hello,

In parallel to the discussion going on in another thread, I have a question
concering the segmentation of another Worldview 2 scene:

I first used all 8 multispectral bands and managed to get a series of
results with increasing thresholds in very reasonable running times. The
region was as follows:


g.region -p

projection: 1 (UTM)
zone:   -36
datum:  wgs84
ellipsoid:  wgs84
north:  7251172
south:  7234772
west:   333792
east:   350192
nsres:  2
ewres:  2
rows:   8200
cols:   8200
cells:  6724

and the command line:

i.segment group=xs out=seg_xs minsize=2 memory=3072 threshold=0.05 (and
thresh=0.1 and 0.2 in successive runs using the results of the previous run
as seeds).

Now, I would like to test segmentation of just the panchromatic band. This
means the following region settings:

projection: 1 (UTM)
zone:   -36
datum:  wgs84
ellipsoid:  wgs84
north:  7251172
south:  7234772
west:   333792
east:   350192
nsres:  0.5
ewres:  0.5
rows:   32800
cols:   32800
cells:  107584

Trying to run with the following command line on my i3, 8GB RAM machine:

i.segment group=pan out=seg_pan_005 threshold=0.05 memory=3072

had the process running for almost 13 hours with it then becoming apparently
stuck in the fourth pass at 10%. At that point the percent didn't change for
over an hour, so I decided to kill the process. Can I assume that I'm here
above the capacities of my machine ? Is there anything (besides working on a
smaller subsample of the image) that I can do to make it work ? What kind of
resources would I need to be able to run such a segmentation?

I guess I'll have to move these kinds of treatments to our university
supercomputer, but I first have to get them to install GRASS...

Moritz
___
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


Re: [GRASS-dev] i.segment on panchromatic band of Worldview 2 scene: what resources are necessary to complete segmentation ?

2013-07-08 Thread Markus Metz
On Mon, Jul 8, 2013 at 2:18 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
 After some improvements to the module by MarkusM, I tried again during the
 night, but it got stuck again with heavy swapping going on. I'm definitively
 giving up to segment the panchromatic image in its entirety on my machine.

 Question: Does the memory= parameter limit total memory usage of the module,
 or does it only limit the memory usage for certain parts of it ?

The memory= parameter should limit the total memory usage. In my
tests, it used always a bit less memory than specified. It would be a
bug if the module uses more memory than specified.

The only limitations are 1) disk space, 2) how long you want to wait.
Memory should not be a limit because of the memory option.



 On 07/07/13 11:52, Yann Chemin wrote:



 2 - Cut in pieces (See Markus Comment about supercomputing) and run 4
 quads on 4 CPUs instead of one large image in one CPU.


 I can do that. Will this have any influence on segmentation results ?

Of course. There will be edge effects, objects will not cross region
borders. Therefore you would need one final run with the pieces
patched together, thus using the former output as input seeds for the
last run. This last run should be faster and use less memory because
it uses seeds.

On a standard HPC system, you are usually allowed to compile your own
software in your $HOME. You could compile trunk there, then set up the
tiles and tile management, and launch jobs with the HPC's job manager
(typically gridengine or derivates, torque and/or MPI).


 3 - Recode i.segment to work natively on heterogeneous computers...
 (would be fun!)


 Would parallization help ? Should i.segment be included into the list of
 OpenMP candidates:
 http://grasswiki.osgeo.org/wiki/OpenMP#Candidates ?

Hmm, because the final global run is needed to remove edge effects, I
would expect the results to be different (not wrong, but different).
But definitively an interesting idea!

Markus M


 Moritz


 Good luck!

 On 4 July 2013 14:10, Moritz Lennertmlenn...@club.worldonline.be  wrote:

 Hello,

 In parallel to the discussion going on in another thread, I have a
 question
 concering the segmentation of another Worldview 2 scene:

 I first used all 8 multispectral bands and managed to get a series of
 results with increasing thresholds in very reasonable running times. The
 region was as follows:

 g.region -p

 projection: 1 (UTM)
 zone:   -36
 datum:  wgs84
 ellipsoid:  wgs84
 north:  7251172
 south:  7234772
 west:   333792
 east:   350192
 nsres:  2
 ewres:  2
 rows:   8200
 cols:   8200
 cells:  6724

 and the command line:

 i.segment group=xs out=seg_xs minsize=2 memory=3072 threshold=0.05 (and
 thresh=0.1 and 0.2 in successive runs using the results of the previous
 run
 as seeds).

 Now, I would like to test segmentation of just the panchromatic band.
 This
 means the following region settings:

 projection: 1 (UTM)
 zone:   -36
 datum:  wgs84
 ellipsoid:  wgs84
 north:  7251172
 south:  7234772
 west:   333792
 east:   350192
 nsres:  0.5
 ewres:  0.5
 rows:   32800
 cols:   32800
 cells:  107584

 Trying to run with the following command line on my i3, 8GB RAM machine:

 i.segment group=pan out=seg_pan_005 threshold=0.05 memory=3072

 had the process running for almost 13 hours with it then becoming
 apparently
 stuck in the fourth pass at 10%. At that point the percent didn't change
 for
 over an hour, so I decided to kill the process. Can I assume that I'm
 here
 above the capacities of my machine ? Is there anything (besides working
 on a
 smaller subsample of the image) that I can do to make it work ? What kind
 of
 resources would I need to be able to run such a segmentation?

 I guess I'll have to move these kinds of treatments to our university
 supercomputer, but I first have to get them to install GRASS...

 Moritz
 ___
 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


Re: [GRASS-dev] [GRASS GIS] #2010: r.in.wms2 fails to install on 6.x

2013-07-08 Thread GRASS GIS
#2010: r.in.wms2 fails to install on 6.x
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.4
Component:  Addons | Version:  svn-releasebranch64  
 Keywords:  r.in.wms2  |Platform:  Linux
  Cpu:  All|  
---+

Comment(by turek):

 Hi,

 Replying to [comment:7 hamish]:
 
   * png8 support missing for WMS 1.3.0
 In capabilties file of WMS 1.1.1 there are two formats: image/png;
 mode=8bit and image/png8. In WMS 1.3.0 there is only image/png; mode=8bit
 format. I am not sure which one to use. Currently is used image/png8
 therefore you can not see png8 in WMS 1.3.0. Maybe it should be used
 image/png; mode=8bit, because WMS 1.3.0 is more restrictive regarding
 formats. It requires only MIME types formats. WMS 1.1.1. is more
 benevolent. It could mean that image/png; mode=8bit is MIME type and the
 other is not. Or it just changes randomly from server to server?

   * color picker greyed out in the Add web service layer WMS gui.

 That is not very user friendly. If you check do not request transparent
 data, the button will be activated. Should be the tooltip added there or
 the button should be hidden if the choice is not checked? Or just let it
 activated also when it is unchecked?

   * loss of region precision in the saved map,
 

 Probably it is caused by reprojection (using gdalwarp).

   * WFS mixes in WMS layers, and has lot of traceback parse errors, but
 realistic data plots; can't query it in the map display window though.  is
 WFS supposed to work yet or is it still a work in progress?

 WFS is not supported, parser just tries interpret capabilities file
 somehow. The parser is written in tolerant way, so it does not enforce
 standards strictly, instead of this it tries to interpret everything what
 it can understood.

 Best
 Stepan

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/2010#comment:8
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] i.segment on panchromatic band of Worldview 2 scene: what resources are necessary to complete segmentation ?

2013-07-08 Thread Nikos Alexandris
Hi!

Very interested in this discussion.  I am working with some QuickBird and 
WorldView images myself, for classification as well (in the coming days).  
However, I only want to deal with small areas.

Let me know if I can load my new system to run any tests (although it has more 
RAM and disk-space than laptops or low-end PCs).  I.e., I might try to 
replicate what Moritz is doing (meaning the region extent).

Best, N

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


[GRASS-dev] [GRASS GIS] #2025: r.kappa: output file saving error on Windows

2013-07-08 Thread GRASS GIS
#2025: r.kappa: output file saving error on Windows
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Raster   | Version:  svn-releasebranch64  
 Keywords:  r.kappa  |Platform:  MSWindows 7  
  Cpu:  Unspecified  |  
-+--
 winGRASS users report that they are unable to save the error
 matrix and kappa to a file.

 Feb 28, 2013 Rebecca wrote:[[BR]]
 I have tried both with the GUI and in python script.[[BR]]

 I am running it using NX client and so my file paths have '\' symbols to
 represent directories. When I use the 'browse' icon to locate the correct
 directory/file, grass automatically uses '\'.  However I am receiving the
 error msg:

 Illegal filename. Character / not allowed.

 For a similar report, see also:

 http://fromgistors.blogspot.it/2013/07/classification-error-QGIS.html (at
 page bottom)

 Random ideas:

 There must be something lacking in the ask() function:
 
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/gis/ask.c#L345

 Perhaps a Windows specific directory separator is needed,
 similar to

 
http://trac.osgeo.org/grass/changeset/55135/grass/branches/releasebranch_6_4/lib/g3d

 ?

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/2025
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool

2013-07-08 Thread Michael Barton
OK. I originally wanted to use matplotlib because it is a much richer 
environment, but it was nixed by the dev team because it added a new 
dependency. If we start using it, it will make numerous, powerful analytical 
functions accessible.

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu












On Jul 8, 2013, at 2:24 AM, Štěpán Turek stepan.tu...@seznam.cz
 wrote:

 Hi Michael,
 Are you planning to use wxPlot for the scatterplot display? This provides a 
 consistent graphical  interface with the other plotting modules.
 currently matplotlib [1] is used. The library provides events [2], which 
 allows you to find out where the user clicked. With this information you are 
 able to keep track of selected regions in a scatter plot.
 
 Best,
 Stepan
  
  
 [1] http://matplotlib.org/
 [2] http://matplotlib.org/users/event_handling.html
 

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

Re: [GRASS-dev] GRASS 6.4.3 release planning, mapcalc expressions in wingrass

2013-07-08 Thread Helena Mitasova
I am happy to report that the expressions with || now work on windows from 
command console when quotes are used.
Thank you Anna and Glynn for solving this long standing problem for wingrass 
users,

Helena

On Jul 4, 2013, at 4:45 PM, Anna Petrášová wrote:

 
 
 
 On Tue, Jul 2, 2013 at 8:57 PM, Anna Petrášová kratocha...@gmail.com wrote:
 Hi,
 
 
 On Fri, Jun 28, 2013 at 2:29 AM, Helena Mitasova hmit...@ncsu.edu wrote:
 regarding the r.mapcalc issue in command console on wingrass -
 (sorry I did not make it clear it was for wingrass - it always worked well on 
 Mac and linux)
 
 It is not critical, windows users can still use the mapcalculator GUI where 
 it runs OK,
 but the r.mapcalc in the command console still does not seem to work - tried 
 by a student
 using June 26 snapshot this is what she says:
 
 Here are examples of the commands run and the errors received:
 r.mapcalc urban2_30m=if(landuse96_28m==1 || 
 landuse96_28m==2,landuse96_28m,null())
 syntax error, unexpected $end, expecting ')'
 Parse error
 'landuse96_28m' is not recognized as an internal or external
 
 command,
 operable program or batch file.
 
 r.mapcalc MASK=if((elevation100  elevation60)  (landuse96_28m==1 || 
 landuse96_28m==2),1,null())
 1 was unexpected at this time.
 
 This is the same we were getting in GRASS6.4.3RC2 and apparently the proposed 
 solutions did not work
 http://lists.osgeo.org/pipermail/grass-dev/2013-February/062047.html
 http://lists.osgeo.org/pipermail/grass-dev/2013-March/062607.html
 
 
 I had the opportunity to test Glynn's patch (the second link above) on 
 Windows and it seems to solve the problems. From the discussion I can see 
 that Markus already tested it but he was not successful, so I applied the 
 patch to 6.5 first.
 All the commands causing problems are now working with both (, ') quotes and 
 without, only the command with || requires quotes.
 
 Anna
 
 Seems to work, I applied it to all branches, please test (using e.g. the 
 commands above).
 
 Anna
 
 
 
 
 if I get this confirmed I will file a bug report (I thought I already did, 
 but it is not there).
 If it is not fixable it should be at least mentioned on the known issues web 
 page
 http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules
 
 Helena
 
 
 
 
 
  Helena:
  I am also wondering whether the r.mapcalc expressions with || (or)
  now run from the wxGUI command console.
 
  I just tried on linux 6.4.3svn wxGUI command console:
 
r.mapcalc either = 0 || 1
  and it worked.
 
  In general I wouldn't be surprised if full command line quoting took
  years and huge amounts of effort to (re)perfect. And even then, does
  it try to follow Bash conventions, or python, or DOS, or some mix of
  all those? How much do we try to (re)teach about command line
  techniques in our own docs? Will unquoted input=C:\Users\files\data.txt
  always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d)
  in the command console in that case?
 
 
  best,
 
  Hamish
 
  ___
  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 mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev