Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr

2015-12-02 Thread GRASS GIS 
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  r.in.gdal, v.in.ogr, gui
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by hellik):

 Replying to [comment:18 marisn]:
 > AAAGH! It's the end of 2015 and GRASS continues its death march towards
 "let's dumb it down to not confuse beginners and thus lose the only reason
 why we are still relevant". If there are no "advanced" features then
 "beginners" do not see any reason why to use GRASS not QGIS (and I have to
 agree with it). If you want to see how it will end, just take a look at
 Firefox.
 >
 > I just had to explain to a QGIS user why he can not find in GRASS
 "snapping tolerance" setting he had been using in QGIS. Reason - you must
 belong to the secret society who passes its secrets only to chosen ones
 and type --ui in that black window to get a dialog with all options not an
 useless dumbed down version where is not possible to change any of not-so-
 common properties under e.g. button "advanced". (Yes, v.in.ogr snapping
 setting is exposed to QGIS users and, as far as I know, nobody has died
 because of it)
 >
 > I do not thing that users who get confused by "Launch advanced
 interface" button are the target audience of GRASS GIS.

 I'm strongly +1 for re-adding an advanced button to the wizzard. As I'm
 often working with foreign data which needs often finetuning for importing
 (e.g. snapping tolerance, where selection, etc). it's annoying to always
 start with --ui.

 I'm not sure why a 'normal' user should be confused with a advanced
 button. What is a 'normal' user?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr

2015-12-02 Thread GRASS GIS 
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  r.in.gdal, v.in.ogr, gui
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by marisn):

 AAAGH! It's the end of 2016 and GRASS continues its death march towards
 "let's dumb it down to not confuse beginners and thus lose the only reason
 why we are still relevant". If there are no "advanced" features then
 "beginners" do not see any reason why to use GRASS not QGIS (and I have to
 agree with it). If you want to see how it will end, just take a look at
 Firefox.

 I just had to explain to a QGIS user why he can not find in GRASS
 "snapping tolerance" setting he had been using in QGIS. Reason - you must
 belong to the secret society who passes its secrets only to chosen ones
 and type --ui in that black window to get a dialog with all options not an
 useless dumbed down version where is not possible to change any of not-so-
 common properties under e.g. button "advanced". (Yes, v.in.ogr snapping
 setting is exposed to QGIS users and, as far as I know, nobody has died
 because of it)

 I do not thing that users who get confused by "Launch advanced interface"
 button are the target audience of GRASS GIS.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr

2015-12-02 Thread GRASS GIS 
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  r.in.gdal, v.in.ogr, gui
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by pvanbosgeo):

 I am not sure if there are many examples of this so-called death march,
 but +1 for the specific example provided.

 I indeed see no reason why any user would get confused, on the contrary..
 I had similar experiences where beginning users were surprised they
 couldn't find the options that were described in the manual.

 In addition, adding a button called "advanced options" is quite a common
 way to 'hide' the more complex options while making it still easy to find
 in many programs.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr

2015-12-02 Thread GRASS GIS 
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.3
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  r.in.gdal, v.in.ogr, gui
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by martinl):

 * milestone:  7.0.0 => 7.0.3


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

2015-12-02 Thread GRASS GIS 
#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc 
speed
--+---
  Reporter:  sprice   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by sprice):

 Hey all, just checking in. What is remaining to get this pushed to the
 GRASS v7.1 code?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2818: wxgui: maps ordered using "natural sort"

2015-12-02 Thread GRASS GIS 
#2818: wxgui: maps ordered using "natural sort"
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.3
Component:  wxGUI|Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I think that it would be really useful in the GUI to get the maps to be
 ordered using natural sort[1]. This would be particularly useful in tools
 like `g.gui.animation` where you have to manually order the maps if they
 are named with an integer suffix. For example, now, if you have these
 maps:

 {{{
 map_1, map_2, ..., map_10, map_11, ..., map_100, ..., map_200
 }}}

 when you try to add them using "multiple add" you get something like this:

 {{{
 map_1, map_10, map_100, map_101, map_102, ..., map_19, map_2, map_20,
 map_200, map_21, map_22, ...,
 }}}

 and this is not usually the animation you intend to create.

 Other places where I think that this functionality would also be useful is
 things like `Map Layer` in the wxgui and also `g.list`.

 WRT to implementation, in python there is the `natsort` package[2] which
 is by far the most flexible solution, but it is rather trivial to
 implement a subset of the package's functionality on your own (e.g. [3]
 and [4]).

 [1] https://en.wikipedia.org/wiki/Natural_sort_order
 [2] https://pypi.python.org/pypi/natsort
 [3] http://stackoverflow.com/a/4836734/592289
 [4] http://stackoverflow.com/a/5967539/592289

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2815: Grass and Pillow > 3.0.0

2015-12-02 Thread GRASS GIS 
#2815: Grass and Pillow > 3.0.0
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.3
Component:  wxGUI|Version:
 Keywords:  animation|CPU:  All
 Platform:  Unspecified  |
-+-
 Pillow since version 3.0.0 removed the `fromstring()` method[1]. AFAIK the
 only usage of the `fromstring()` method in GRASS in g.gui.animation:

 {{{
 $ ag fromstring

 [omit etree.fromstring() results]

 gui/wxpython/animation/utils.py
 263:pilImage.fromstring(image.GetData())
 }}}

 I believe it is rather safe to replace the call with `frombytes()`. If we
 need to keep compatibility with the original PIL I guess that something
 like this would do it:
 {{{
 def WxImageToPil(image):
 """Converts wx.Image to PIL image"""
 pilImage = Image.new('RGB', (image.GetWidth(), image.GetHeight()))
 try:
 pilImage.frombytes(image.GetData())
 except Exception:
 # We are using the original Pil or an old Pillow version
 pilImage.fromstring(image.GetData())
 return pilImage
 }}}

 [1] https://github.com/python-
 pillow/Pillow/commit/71c95c8e5f3bba1845444a246d04646825e6bab3

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2817: Adding multiple raster/vector maps is slow

2015-12-02 Thread GRASS GIS 
#2817: Adding multiple raster/vector maps is slow
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.3
Component:  wxGUI|Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I am not that familiar with the codebase and I couldn't find the exact
 point where this happens, but it seems that when you try to add multiple
 raster/vector maps in the GUI the maps get added one by one.

 From a usability point of view, this can get quite slow when you try to
 add many maps (e.g. 100+) and it can get excruciatingly slow when you have
 an already rendered map because the map gets re-rendered for each and
 every one map that we add.

 At the very least, the re-rendering of the existing map should only be
 done once; after all the maps have been added.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2815: Grass and Pillow > 3.0.0

2015-12-02 Thread GRASS GIS 
#2815: Grass and Pillow > 3.0.0
-+-
  Reporter:  pmav99  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  wxGUI   |Version:  unspecified
Resolution:  |   Keywords:  animation
   CPU:  All |   Platform:  Unspecified
-+-
Changes (by pmav99):

 * version:   => unspecified


Comment:

 This should be the exact same issue:
 http://osgeo-org.1560.x6.nabble.com/d-mon-using-PIL-tostring-not-used-
 anymore-tobytes-to-be-used-td5239514.html

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr

2015-12-02 Thread GRASS GIS 
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  r.in.gdal, v.in.ogr, gui
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by martinl):

 Replying to [comment:20 pvanbosgeo]:

 > In addition, adding a button called "advanced options" is quite a common
 way to 'hide' the more complex options while making it still easy to find
 in many programs.

 better would be a new tab with all specific options. Colleague of mine is
 working on that.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2816: Save animation configuration in g.gui.animation

2015-12-02 Thread GRASS GIS 
#2816: Save animation configuration in g.gui.animation
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.3
Component:  wxGUI|Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 It would be nice if you could save a configuration in `g.gui.animation`.
 Now, whenever you close the tool you have to recreate the configuration
 from scratch.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] d.mon using PIL tostring() (not used anymore), tobytes() to be used.

2015-12-02 Thread Yann 

Hi,

in SVN trunk using Ubuntu 16.04 LTS

-

pilImageRgbData = pilImageCopyRGB.tostring()
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 686, in 
tostring

"Please call tobytes() instead.")
Exception: tostring() has been removed. Please call tobytes() instead.
 100%

--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

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

Re: [GRASS-dev] [GRASS-SVN] r66995 - grass-addons/grass7/vector/v.in.natura2000

2015-12-02 Thread Vaclav Petras 
On Wed, Dec 2, 2015 at 4:08 PM, Helmut Kudrnovsky  wrote:

> > better than this is the approach taken in v.flexture where you let parser
> > run and then you import the special dependencies. v.class.mlpy and
> > especially v.class.ml are more complicated cases where the dependencies
> > are
> > spread more through the code but similar approach is still applicable.
> >
> > As you can see from v.flexture, there was an idea to provide a way how to
> > install the dependencies but this might be too difficult and suggestions
> > in
> > the error message or manual might be just the right thing to do.
> >
> > Vaclav
> >
> >
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.flexure/v.flexure.py
> >
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.class.mlpy/v.class.mlpy.py
> >
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.class.ml/v.class.ml.py
>
> thanks for your hints.
>
> as I'm not a python guru, I've changed it like this way to catch if
> dependency pyspatalite isn't installed:
>

Thanks. This is pretty good. (Except for the indent, use pep8.)


>
>
> https://trac.osgeo.org/grass/changeset?reponame==67009%40grass-addons%2Fgrass7%2Fvector%2Fv.in.natura2000%2Fv.in.natura2000.py=66995%40grass-addons%2Fgrass7%2Fvector%2Fv.in.natura2000%2Fv.in.natura2000.py
>
> or
>
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.natura2000/v.in.natura2000.py#L151
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Different v.mkgrid table output depending on grid size

2015-12-02 Thread Michel Wortmann 
Hi Markus, sorry so late. Here is my diff of v.mkgrid/main.c

diff --git a/vector/v.mkgrid/main.c b/vector/v.mkgrid/main.c
index db733fd..5004fa0 100644
--- a/vector/v.mkgrid/main.c
+++ b/vector/v.mkgrid/main.c
@@ -451,7 +451,7 @@ int main(int argc, char *argv[])
}
else {
sprintf(buf, "( %d, %d, %d )",
-   attCount + 1, i + 1, j + 1);
+  attCount + 1, grid_info.num_rows - i, j + 1);
}
if (db_append_string(, buf) != DB_OK)
G_fatal_error(_("Unable to fill attribute table"));


It’s just this single line that is changed.
Regards,
Michel


On 28 Nov 2015, at 18:15, Markus Neteler  wrote:

> On Sat, Nov 28, 2015 at 11:24 AM, Michel Wortmann
>  wrote:
>> The magical number 27 comes from the fact that it puts letters into rown and
>> coln and the alphabet is exhausted after 27 (although I wonder why the
>> condition is && and not ||?). The inconsistency is just related to the
>> counting of the row, i.e. the second argument to sprintf() in the else
>> statement. So all thats needed is to replace the i + 1 with
>> grid_info.num_rows - i.
> 
> Can you please send a diff?
> 
> Markus

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

Re: [GRASS-dev] [GRASS-SVN] r66995 - grass-addons/grass7/vector/v.in.natura2000

2015-12-02 Thread Helmut Kudrnovsky 
Hi Vaclav,


wenzeslaus wrote
> Hi Helmut,
> 
> On Tue, Dec 1, 2015 at 5:11 AM, 

> svn_grass@

>  wrote:
> 
>> +try:
>> +import pyspatialite.dbapi2 as db
>> +except ImportError:
>> +grass.warning( "pyspatialite has to be installed." )
>>
> 
> better than this is the approach taken in v.flexture where you let parser
> run and then you import the special dependencies. v.class.mlpy and
> especially v.class.ml are more complicated cases where the dependencies
> are
> spread more through the code but similar approach is still applicable.
> 
> As you can see from v.flexture, there was an idea to provide a way how to
> install the dependencies but this might be too difficult and suggestions
> in
> the error message or manual might be just the right thing to do.
> 
> Vaclav
> 
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.flexure/v.flexure.py
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.class.mlpy/v.class.mlpy.py
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.class.ml/v.class.ml.py

thanks for your hints.

as I'm not a python guru, I've changed it like this way to catch if
dependency pyspatalite isn't installed:

https://trac.osgeo.org/grass/changeset?reponame==67009%40grass-addons%2Fgrass7%2Fvector%2Fv.in.natura2000%2Fv.in.natura2000.py=66995%40grass-addons%2Fgrass7%2Fvector%2Fv.in.natura2000%2Fv.in.natura2000.py

or

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.natura2000/v.in.natura2000.py#L151




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r66995-grass-addons-grass7-vector-v-in-natura2000-tp5239422p5239706.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] error in interactive supervised classification input - update

2015-12-02 Thread Anna Petrášová 
Is it landsat 8? g.gui.iclass is rewritten i.class which supported only 256
categories...

On Tue, Dec 1, 2015 at 5:55 PM, Michael Barton 
wrote:

> Apparently no graphs work in the interactive iclass module. Also, it
> doesn’t seem to work otherwise.
>
> I can mark training fields with no problem. I can export them with no
> problem.
>
> But when I click the update button, the preview screen goes blank for a
> bit for each class then returns to the original base raster with nothing
> showing. The command console displays the following errors (one for each
> class):
>
> Data error preparing signatures: value (19592) > num of cats
> (256)
> Data error preparing signatures: value (8089) > num of cats
> (256)
> Data error preparing signatures: value (11048) > num of cats
> (256)
> Data error preparing signatures: value (9218) > num of cats
> (256)
>
>
> I’ve looked at the very slim help file and it did not help. Copying Helena
> and Anna in case they’ve be successful with this working.
>
> Michael
>
>
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> 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 Dec 1, 2015, at 3:33 PM, Michael Barton  wrote:
>
> When I try to use g.gui.iclass, I get the error in the attached file. It
> says it was unable to import matplotlib. Then it says it did find
> matplotlib but it was the wrong architecture.
>
> If I fire up Python from the GRASS terminal and import matplotlib, it is
> fine. I also tried to install matplotlib from the terminal in case it would
> find a correct architecture version. This also went fine.
>
> So I begin to suspect that this is a bug instead of a problem with my
> systems. Any thoughts?
>
> Mac OS X 10.10.3
> GRASS 7.0.2, compliled a week ago.
>
> Michael
>
>
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] error in interactive supervised classification input - update

2015-12-02 Thread Michael Barton 
It is landsat 8, which is 16 bit. So that may account for one issue. If so, the 
error about matplotlib is a 2nd issue.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
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 Dec 2, 2015, at 8:20 PM, Anna Petrášová 
> wrote:

Is it landsat 8? g.gui.iclass is rewritten i.class which supported only 256 
categories...

On Tue, Dec 1, 2015 at 5:55 PM, Michael Barton 
> wrote:
Apparently no graphs work in the interactive iclass module. Also, it doesn’t 
seem to work otherwise.

I can mark training fields with no problem. I can export them with no problem.

But when I click the update button, the preview screen goes blank for a bit for 
each class then returns to the original base raster with nothing showing. The 
command console displays the following errors (one for each class):

Data error preparing signatures: value (19592) > num of cats
(256)
Data error preparing signatures: value (8089) > num of cats
(256)
Data error preparing signatures: value (11048) > num of cats
(256)
Data error preparing signatures: value (9218) > num of cats
(256)


I’ve looked at the very slim help file and it did not help. Copying Helena and 
Anna in case they’ve be successful with this working.

Michael



C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
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 Dec 1, 2015, at 3:33 PM, Michael Barton 
> wrote:

When I try to use g.gui.iclass, I get the error in the attached file. It says 
it was unable to import matplotlib. Then it says it did find matplotlib but it 
was the wrong architecture.

If I fire up Python from the GRASS terminal and import matplotlib, it is fine. 
I also tried to install matplotlib from the terminal in case it would find a 
correct architecture version. This also went fine.

So I begin to suspect that this is a bug instead of a problem with my systems. 
Any thoughts?

Mac OS X 10.10.3
GRASS 7.0.2, compliled a week ago.

Michael



C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
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


















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

Re: [GRASS-dev] Unable to rename cell/null file - NULL file messed up

2015-12-02 Thread Glynn Clements 

Paulo van Breugel wrote:

> Can't answer that, but I see that a related (?) ticket

#2434 isn't related to #2712. #2712 relates specifically to the null
file compression changes. #2434 was opened a year before those changes
were started.

> https://trac.osgeo.org/grass/ticket/2434 was retargeted to 7.03? From the
> description that issue seems to be very similar to the problem described
> above?

The problem described above:

> > > WARNING: Unable to rename cell file
> > > 'C:\GIS\GrassJvdS/latlong/YLD_NUT/.tmp/unknown/3988.0' to
> > > 'C:\GIS\GrassJvdS/latlong/YLD_NUT/fcell/Shan3_CA_Renyi_0_0': File exists
> > > WARNING: Unable to rename null file
> > > 'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/.tmp/unknown/4100.1' to
> > > 'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/cell_misc/Shan3_CA_Renyi_1_0/null':
> > > File exists

doesn't match the symptoms of either #2434 or #2712. In both of those
cases, the rename() fails with EACCESS ("Permission denied"), which is
symptomatic of the file being open.

This case fails with EEXIST ("File exists"), which suggests that the
destination file wasn't deleted first. On Unix, deleting the original
isn't required (or even desired); rename() will atomically remove any
existing file. Windows generates an error if the destination exists. 
So we (try to) remove it first (on all platforms).

remove(path);
if (rename(fcb->temp_name, path)) {
G_warning(_("Unable to rename cell file '%s' to '%s': %s"),
  fcb->temp_name, path, strerror(errno));
stat = -1;
}

(close_new() in lib/raster/close.c).

The warning suggests that the file exists and remove() failed to
remove it. On Windows, that can happen if the file is open.

And looking at r.biodiversity.py, I notice:

grass.mapcalc("$outl = -1 * $outl", 
  outl=out_renyi,
  overwrite=True,
  quiet=True)

I.e. it's running r.mapcalc with the same map as both input and
output. That isn't guaranteed to work. And in fact it doesn't, because
the close_maps() function (which closes all of the input maps) is
never actually called.

So when it tries to close the output maps, which involves renaming the
new cell/fcell/null files into place, the original cell/fcell/null
files are still open for reading, meaning that the remove() will fail,
as will the subsequent rename().

Having r.mapcalc close the input maps would avoid that, and should be
done, but ultimately that's fixing the symptoms. r.biodiversity
shouldn't be trying to modify out_renyi "in-place". It should create a
new map then, if necessary, replace the original using g.remove and
g.rename.

One problem with in-place modification is that closing an output map
writes a number of support files (history, range, quant, cats,
histogram). But after closing the output maps, r.mapcalc will
sometimes copy some of the metadata (cats, colors, history) from the
input map. Currently, it only does this if the entire expression is
just a map with optional modifiers, but it may get more "intelligent"
in the future. Clearly, that's a problem if the input map has already
been replaced.

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

Re: [GRASS-dev] Unable to rename cell/null file - NULL file messed up

2015-12-02 Thread Paulo van Breugel 



On 03-12-15 05:15, Glynn Clements wrote:

Paulo van Breugel wrote:


Can't answer that, but I see that a related (?) ticket

#2434 isn't related to #2712. #2712 relates specifically to the null
file compression changes. #2434 was opened a year before those changes
were started.


https://trac.osgeo.org/grass/ticket/2434 was retargeted to 7.03? From the
description that issue seems to be very similar to the problem described
above?

The problem described above:


WARNING: Unable to rename cell file
'C:\GIS\GrassJvdS/latlong/YLD_NUT/.tmp/unknown/3988.0' to
'C:\GIS\GrassJvdS/latlong/YLD_NUT/fcell/Shan3_CA_Renyi_0_0': File exists
WARNING: Unable to rename null file
'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/.tmp/unknown/4100.1' to
'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/cell_misc/Shan3_CA_Renyi_1_0/null':
File exists

doesn't match the symptoms of either #2434 or #2712. In both of those
cases, the rename() fails with EACCESS ("Permission denied"), which is
symptomatic of the file being open.

This case fails with EEXIST ("File exists"), which suggests that the
destination file wasn't deleted first. On Unix, deleting the original
isn't required (or even desired); rename() will atomically remove any
existing file. Windows generates an error if the destination exists.
So we (try to) remove it first (on all platforms).

remove(path);
if (rename(fcb->temp_name, path)) {
G_warning(_("Unable to rename cell file '%s' to '%s': %s"),
  fcb->temp_name, path, strerror(errno));
stat = -1;
}

(close_new() in lib/raster/close.c).

The warning suggests that the file exists and remove() failed to
remove it. On Windows, that can happen if the file is open.

And looking at r.biodiversity.py, I notice:

 grass.mapcalc("$outl = -1 * $outl",
   outl=out_renyi,
   overwrite=True,
   quiet=True)

I changed that already, now output is different from any of the input layers


I.e. it's running r.mapcalc with the same map as both input and
output. That isn't guaranteed to work. And in fact it doesn't, because
the close_maps() function (which closes all of the input maps) is
never actually called.

So when it tries to close the output maps, which involves renaming the
new cell/fcell/null files into place, the original cell/fcell/null
files are still open for reading, meaning that the remove() will fail,
as will the subsequent rename().

Having r.mapcalc close the input maps would avoid that, and should be
done, but ultimately that's fixing the symptoms. r.biodiversity
shouldn't be trying to modify out_renyi "in-place". It should create a
new map then, if necessary, replace the original using g.remove and
g.rename.


Thanks for the detailed explanation. After I changed the r.mapcalc 
statement the script also works on Windows, but it is good to know 
better the underlying problem.




One problem with in-place modification is that closing an output map
writes a number of support files (history, range, quant, cats,
histogram). But after closing the output maps, r.mapcalc will
sometimes copy some of the metadata (cats, colors, history) from the
input map. Currently, it only does this if the entire expression is
just a map with optional modifiers, but it may get more "intelligent"
in the future. Clearly, that's a problem if the input map has already
been replaced.



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

Re: [GRASS-dev] d.mon using PIL tostring() (not used anymore), tobytes() to be used.

2015-12-02 Thread Anna Petrášová 
On Wed, Dec 2, 2015 at 4:06 AM, Yann  wrote:

> Hi,
>
> in SVN trunk using Ubuntu 16.04 LTS
>
> -
>
> pilImageRgbData = pilImageCopyRGB.tostring()
>   File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 686, in
> tostring
> "Please call tobytes() instead.")
> Exception: tostring() has been removed. Please call tobytes() instead.
>  100%
>
>
Please try r67011.

Anna

> --
> -
> Yann Chemin
> Address: 3 Toul Melin, 56400 Plumergat
> Mobile: +33 (0)7 83 85 52 34
>
> ___
> 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-SVN] r66995 - grass-addons/grass7/vector/v.in.natura2000

2015-12-02 Thread Markus Neteler 
On Tue, Dec 1, 2015 at 7:24 PM, Vaclav Petras  wrote:
> Hi Helmut,
>
> On Tue, Dec 1, 2015 at 5:11 AM,  wrote:
>>
>> +try:
>> +import pyspatialite.dbapi2 as db
>> +except ImportError:
>> +grass.warning( "pyspatialite has to be installed." )
>
>
> better than this is the approach taken in v.flexture where you let parser
> run and then you import the special dependencies. v.class.mlpy and
> especially v.class.ml are more complicated cases where the dependencies are
> spread more through the code but similar approach is still applicable.
>
> As you can see from v.flexture, there was an idea to provide a way how to
> install the dependencies but this might be too difficult and suggestions in
> the error message or manual might be just the right thing to do.
>
> Vaclav
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.flexure/v.flexure.py
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.class.mlpy/v.class.mlpy.py
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.class.ml/v.class.ml.py

FWIW, today I have added a termcolor check to g.search.modules, just
within the code.

https://trac.osgeo.org/grass/changeset/67001

Only if the user requested -c (colorize) the check is executed (hence,
after the parser was called).

Hope this makes sense,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Unable to rename cell/null file - NULL file messed up

2015-12-02 Thread Paulo van Breugel 



On 01-12-15 14:51, Paulo van Breugel wrote:



On Tue, Dec 1, 2015 at 2:04 PM, Helmut Kudrnovsky > wrote:


pvanbosgeo wrote
> When running a script (r.biodiversity) in GRASS 7.0 for Windows, I am
> getting the warning:
>
> WARNING: Unable to rename cell file
> 'C:\GIS\GrassJvdS/latlong/YLD_NUT/.tmp/unknown/3988.0' to
> 'C:\GIS\GrassJvdS/latlong/YLD_NUT/fcell/Shan3_CA_Renyi_0_0':
File exists
> WARNING: Unable to rename null file
> 'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/.tmp/unknown/4100.1' to
>
'C:\GIS\GrassJvdS/latlong_2005/YLD_NUT/cell_misc/Shan3_CA_Renyi_1_0/null':
> File exists

tested here:

r.biodiversity -r --verbose
input=spec1@data,spec2@data,spec3@data,spec4@data,spec5@data
output=renyi
alpha=0,1,2
WARNING: Unable to rename null file
'C:\grassdata/test3035/data/.tmp/unknown/1680.1' to
'C:\grassdata/test3035/data/cell_misc/renyi_Renyi_0_0/null': File
exists
WARNING: Unable to rename cell file
'C:\grassdata/test3035/data/.tmp/unknown/1680.0' to
'C:\grassdata/test3035/data/fcell/renyi_Renyi_0_0': File exists
WARNING: Unable to rename null file
'C:\grassdata/test3035/data/.tmp/unknown/8936.1' to
'C:\grassdata/test3035/data/cell_misc/renyi_Renyi_1_0/null': File
exists
WARNING: Unable to rename cell file
'C:\grassdata/test3035/data/.tmp/unknown/8936.0' to
'C:\grassdata/test3035/data/fcell/renyi_Renyi_1_0': File exists
WARNING: Unable to rename null file
'C:\grassdata/test3035/data/.tmp/unknown/9328.1' to
'C:\grassdata/test3035/data/cell_misc/renyi_Renyi_2_0/null': File
exists
WARNING: Unable to rename cell file
'C:\grassdata/test3035/data/.tmp/unknown/9328.0' to
'C:\grassdata/test3035/data/fcell/renyi_Renyi_2_0': File exists

is there some overwriting of existing files in the script? AFAIR
there may
be some issues with overwriting existing files in windows os.

Thanks Helmut. Yes, the script does also overwrite some intermediate 
files (with r.mapcalc). I will look into that and see how to change that.


Hi Helmut, you were absolutely right, the problem was with r.mapcalc 
overwriting some intermediate files, so I changed that. I don't have 
Windows myself, but had a quick try on my colleagues computer, and it 
seems to work now.  Thanks for your help.




I wonder though, if I use overwrite on the command line, there is no 
problem. So than that would be a problem specific to 
grass.script.mapcalc ?




-
best regards
Helmut
--
View this message in context:

http://osgeo-org.1560.x6.nabble.com/Unable-to-rename-cell-null-file-NULL-file-messed-up-tp5239350p5239357.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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