Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Glynn Clements]

Moritz Lennert wrote:

> Yes. Do we have any existing module to calculate area by pixel ? An
> area() function in r.mapcalc would be nice...

I notice that this has been added, but I'm not sure that it's adequate
for this task.

For anything other than lat-lon locations, G_area_of_cell_at_row()
assumes that the area of a cell is constant over the region. That's
true for equal-area projections, and not far off for small scales
(where projection would be almost an affine transformation), but it
could be quite far off at larger scales.

Ideally, r.proj should provide the option to generate maps containing
metadata for a projection: source coordinates, horizontal/vertical
scale factors, area scale factor, rotation angle, skew angle. I.e. 
projected coordinates, horizontal/vertical first derivatives, and
information derived from them (maybe also second derivatives, and
derived quantaties such as curvature or radius of curvature, but that
can be quite inaccurate for discrete samples).

IOW, rather than inverse-projecting coordinates and performing a
look-up in a source map, it would inverse-project coordinates and
write the resulting coordinates (or differences).

The main issue is an appropriate choice of delta. Too large a value
means that you're calculating an average over a non-negligible
distance, too small a value means that you lose accuracy due to
subtracting numerically-close values.

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

Re: [GRASS-dev] does GRASS need HOME to be defined?

[Glynn Clements]

Helmut Kudrnovsky wrote:

> regarding windows, the configuration directory is defined by the %APPDATA%
> variable; HOME is defined by %HOMEDRIVE% and %HOMEPATH%.
> 
> it expands to:
> 
> >>> import os
> >>> os.getenv('HOME')
> 'C:\\Users\\yourusername'
> >>> os.getenv('APPDATA')
> 'C:\\Users\\yourusername\\AppData\\Roaming'
> 
> would it harm if %HOME% would be extended from _C:\Users\yourusername\_ to
> _C:\Users\yourusername\Documents_ in windows?

Note that:

1. %HOMEPATH% isn't guaranteed to be Users\.

2. The preferred way of referencing that directory is %USERPROFILE%.

3. While %USERPROFILE%\Documents is created automatically, that isn't
guaranteed to be the location of the user's "My Documents" folder (it
can be changed, and in networked environments is typically located on
a file server).

FWIW, the "My Documents" location can be obtained by querying the
registry key

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell 
Folders\Personal

then expanding the result; the default value is "%USERPROFILE\Documents".

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

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

The issue is solved in Python 2.7.12 from 2016-06-25.

https://hg.python.org/cpython/raw-file/v2.7.12/Misc/NEWS

On Wed, Dec 7, 2016 at 6:59 PM, Michael Barton 
wrote:

> We need to do something other than update Python.


There is not that much which can be done on the GRASS site. According to
Python issue #26083, the root of the problem is in Mac OS read() which
causes pre-2.7.12 subprocess package to fail on anything longer than 512
bytes when piping is used (significant part of GRASS Python code in GUI,
lib and modules). We can workaround it (example below causing other things
to fail), included fixed subprocess code in GRASS or switch to
subprocess32. None of these is feasible for 7.2 and they are not even worth
it considering that the fixed Python was released.

Example workaround (not recommended):

Index: gui/wxpython/core/toolboxes.py
===
--- gui/wxpython/core/toolboxes.py(revision 70036)
+++ gui/wxpython/core/toolboxes.py(working copy)
@@ -670,8 +670,20 @@
 try:
 task = gtask.parse_interface(module)
 except ScriptError as e:
+# This tries to solve failed build or run of a module
 sys.stderr.write("%s: %s\n" % (module, e))
 return '', ''
+except ValueError as e:
+# This is testing for Python's #26083 on Mac OS.
+# http://bugs.python.org/issue26083
+# The whole except ValueError should be removed once it
+# is fixed in Python (likely 2.7.12) or subprocess32 is used.
+from sys import platform
+if platform == "darwin":
+sys.stderr.write("%s: %s\n" % (module, e))
+return '', ''
+# raise exception again on other platforms
+raise

 return task.get_description(full=True), \
 task.get_keywords()
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

On Wed, Dec 7, 2016 at 7:00 PM, Michael Barton 
wrote:

> Also, why did this appear in GRASS 7.2 since mid-September? If we can
> answer that, perhaps we can avoid this issue.


Perhaps certain version of Python (the "patch" one, not just minor) or
change in Mac OS API. Does it happen with other versions of GRASS (freshly
compiled from scratch)?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Michael Barton]

Also, why did this appear in GRASS 7.2 since mid-September? If we can answer 
that, perhaps we can avoid this 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 7, 2016, at 4:48 PM, Vaclav Petras 
> wrote:


On Wed, Dec 7, 2016 at 2:23 PM, Anna Petrášová 
> wrote:
Looks like this:
http://bugs.python.org/issue26083

Then it seems that the issue is unrelated to GRASS source code. Maybe an update 
of system Python would help. Many GRASS modules written in Python won't work 
with this Python bug.

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

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Michael Barton]

We need to do something other than update Python. We've had numerous issue with 
running GRASS that arise when people install non-system Python. If we package 
Python with GRASS, that would solve it of course. But that is another issue 
right now.

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 7, 2016, at 4:48 PM, Vaclav Petras 
> wrote:


On Wed, Dec 7, 2016 at 2:23 PM, Anna Petrášová 
> wrote:
Looks like this:
http://bugs.python.org/issue26083

Then it seems that the issue is unrelated to GRASS source code. Maybe an update 
of system Python would help. Many GRASS modules written in Python won't work 
with this Python bug.

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

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

On Wed, Dec 7, 2016 at 2:23 PM, Anna Petrášová 
wrote:

> Looks like this:
> http://bugs.python.org/issue26083
>

Then it seems that the issue is unrelated to GRASS source code. Maybe an
update of system Python would help. Many GRASS modules written in Python
won't work with this Python bug.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal: add scale and shift parameters?

[Markus Neteler]

On Sun, May 22, 2016 at 12:09 PM, Markus Neteler  wrote:
> On Sat, May 21, 2016 at 7:45 AM, Glynn Clements  
> wrote:
>> Markus Neteler wrote:
>>
>>> sometimes it is convenient to scale/shift input maps on the fly during
>>> the import in order to avoid an extra step with r.mapcalc (think: tons
>>> of scaled Landsat data etc).
>>
>> Perhaps a better option (albeit one which requires some amount of
>> design, rathern than just coding) would be to have this performed
>> during read, i.e. similarly to how reclass maps are handled.
>>
>> This would allow it to be used with r.external maps without needing to
>> make a copy (which largely defeats the point of using r.external).
>>
>> It would also allow most maps to be stored as CELL, with better
>> precision than FCELL (32 bits rather than 24) and less space than
>> DCELL. It's quite rare for physical measurements to be sufficiently
>> accurate that 32 bits isn't enough.
>
> The latter idea, to store all data as CELL and the derive the
> different representations from that I quite like.
>
> As an example: Temperature data are often shipped as e.g. degree
> Celsius * 10 or degree Celsius * 100. While I prefer to continue in
> GRASS with Celsius (hence divide by the respective value) it is a
> waste of disk space to then make all subsequent maps e.g. DCELL since
> that precision isn't there anyway available from the original data.
>
> As soon as 7.2.svn is branched off, we could consider to implement
> such a change in trunk and publish it later as 7.4 or even 8.

I found also a related ticket:

https://trac.osgeo.org/grass/ticket/1640

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

Re: [GRASS-dev] [release planning] 7.2.0

[Markus Neteler]

On Mon, Dec 5, 2016 at 1:49 PM, Martin Landa  wrote:
> Hi,
>
> 2016-12-05 9:33 GMT+01:00 Luca Delucchi :
>> Yes I also think this, but I'm not sure if it is better to change the
>> behavior of r.out.xyz or keep it like the actual one and change it in
>> the next main release.
>> For sure we should add parameter to permit to return also NULL values
>> before the 7.2 release
>
> I am not sure complicated it is and who will do it soon.

Solved with a non-invasive new flag.

Now the current showstopper is MacOSX it seems...

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

Re: [GRASS-dev] t.rast.out.xyz not exporting all cells in the computational region

[Markus Neteler]

On Wed, Dec 7, 2016 at 9:10 AM, Veronica Andreo  wrote:
> Hi,
>
> 2016-12-06 23:24 GMT+01:00 Martin Landa :
>>
>> Hi,
>>
>> 2016-12-06 23:06 GMT+01:00 Markus Neteler :
>> > I have submitted a new -i flag to include no data values (r70017).
>> > This can be used for  t.rast.out.xyz and backported for 7.2.1.
>
>
> IMHO, if we wait to backport this new flag in r.out.xyz until 7.2.1, then
> t.rast.out.xyz could only be modified after that and this might happen in
> ~3-4 months from now according to a previous email from Martin. What I mean
> is that the original problem that was regarding exporting time series
> containing NULL values with t.rast.out.xyz, is then not solved, but
> postponed some months. Otherwise, we would have an add-on (t.rast.out.xyz)
> with features that only works along with trunk and that is not desirable,
> right?

I overlooked that t.rast.out.xyz is an addon that depends on the release branch.
Ok, while I dislike it I have backported the new flag in r70034.

Now someone else please update t.rast.out.xyz accordingly.

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

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Michael Barton]

I keep it to the system default, 2.7

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 7, 2016, at 12:23 PM, Anna Petrášová  wrote:
> 
> Looks like this:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bugs.python.org_issue26083=DQIBaQ=AGbYxfJbXK67KfXyGqyv2Ejiz41FqQuZFk4A-1IxfAU=vxOW6PLS28MPea_dWUwPfRf71TAIziRDuFqWJimQN1I=eYAqKgNPkJUKeMRk8YVKJGgyd7q9RVjLmzIIuDlNpaE=izrhRx4RpfcJf2yER0JkRJgCsAWIh7M9eHxPTWb6YAk=
>  
> 
> but not sure why I don't have the problem. Which python do you use?
> 
> On Wed, Dec 7, 2016 at 12:59 PM, Michael Barton  
> wrote:
>> I did make distclean and recomplied, without send the output to a log. I
>> searched for menudata.xml in my terminal output and may have found the
>> problem. What do  you thing?
>> 
>> ValueError: insecure string pickle
>> make[4]: *** [xml/menudata.xml] Error 1
>> make[3]: [default] Error 2 (ignored)
>> Traceback (most recent call last):
>>  File "core/toolboxes.py", line 903, in 
>>sys.exit(main())
>>  File "core/toolboxes.py", line 887, in main
>>userDefined=False)
>>  File "core/toolboxes.py", line 297, in createTree
>>moduleItems=moduleItems)
>>  File "core/toolboxes.py", line 334, in toolboxes2menudata
>>_expandRuntimeModules(root)
>>  File "core/toolboxes.py", line 634, in _expandRuntimeModules
>>desc, keywords = _loadMetadata(name)
>>  File "core/toolboxes.py", line 671, in _loadMetadata
>>task = gtask.parse_interface(module)
>>  File
>> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/task.py",
>> line 528, in parse_interface
>>tree = etree.fromstring(get_interface_description(name))
>>  File
>> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/task.py",
>> line 480, in get_interface_description
>>stderr=PIPE)
>>  File
>> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/core.py",
>> line 74, in __init__
>>subprocess.Popen.__init__(self, args, **kwargs)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
>> line 710, in __init__
>>errread, errwrite)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
>> line 1334, in _execute_child
>>child_exception = pickle.loads(data)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
>> line 1382, in loads
>>return Unpickler(file).load()
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
>> line 858, in load
>>dispatch[key](self)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
>> line 966, in load_string
>>raise ValueError, "insecure string pickle"
>> ValueError: insecure string pickle
>> make[4]: *** [xml/module_tree_menudata.xml] Error 1
>> make[3]: [default] Error 2 (ignored)
>> Traceback (most recent call last):
>>  File "core/menutree.py", line 245, in 
>>menudata = LayerManagerMenuData(filename)
>>  File
>> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/gui/wxpython/lmgr/menudata.py",
>> line 42, in __init__
>>self, filename, expandAddons=expandAddons)
>>  File
>> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/gui/wxpython/core/menutree.py",
>> line 65, in __init__
>>xmlTree = etree.parse(filename)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
>> line 1182, in parse
>>tree.parse(source, parser)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
>> line 657, in parse
>>self._root = parser.close()
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
>> line 1654, in close
>>self._raiseerror(v)
>>  File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
>> line 1506, in _raiseerror
>>raise err
>> xml.etree.ElementTree.ParseError: no element found: line 1, column 0
>> make[4]: *** [menustrings.py] Error 1
>> make[3]: [default] Error 2 (ignored)
>> 
>> 
>> 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 

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Anna Petrášová]

Looks like this:
http://bugs.python.org/issue26083

but not sure why I don't have the problem. Which python do you use?

On Wed, Dec 7, 2016 at 12:59 PM, Michael Barton  wrote:
> I did make distclean and recomplied, without send the output to a log. I
> searched for menudata.xml in my terminal output and may have found the
> problem. What do  you thing?
>
> ValueError: insecure string pickle
> make[4]: *** [xml/menudata.xml] Error 1
> make[3]: [default] Error 2 (ignored)
> Traceback (most recent call last):
>   File "core/toolboxes.py", line 903, in 
> sys.exit(main())
>   File "core/toolboxes.py", line 887, in main
> userDefined=False)
>   File "core/toolboxes.py", line 297, in createTree
> moduleItems=moduleItems)
>   File "core/toolboxes.py", line 334, in toolboxes2menudata
> _expandRuntimeModules(root)
>   File "core/toolboxes.py", line 634, in _expandRuntimeModules
> desc, keywords = _loadMetadata(name)
>   File "core/toolboxes.py", line 671, in _loadMetadata
> task = gtask.parse_interface(module)
>   File
> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/task.py",
> line 528, in parse_interface
> tree = etree.fromstring(get_interface_description(name))
>   File
> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/task.py",
> line 480, in get_interface_description
> stderr=PIPE)
>   File
> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/core.py",
> line 74, in __init__
> subprocess.Popen.__init__(self, args, **kwargs)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
> line 710, in __init__
> errread, errwrite)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
> line 1334, in _execute_child
> child_exception = pickle.loads(data)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
> line 1382, in loads
> return Unpickler(file).load()
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
> line 858, in load
> dispatch[key](self)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
> line 966, in load_string
> raise ValueError, "insecure string pickle"
> ValueError: insecure string pickle
> make[4]: *** [xml/module_tree_menudata.xml] Error 1
> make[3]: [default] Error 2 (ignored)
> Traceback (most recent call last):
>   File "core/menutree.py", line 245, in 
> menudata = LayerManagerMenuData(filename)
>   File
> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/gui/wxpython/lmgr/menudata.py",
> line 42, in __init__
> self, filename, expandAddons=expandAddons)
>   File
> "/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/gui/wxpython/core/menutree.py",
> line 65, in __init__
> xmlTree = etree.parse(filename)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
> line 1182, in parse
> tree.parse(source, parser)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
> line 657, in parse
> self._root = parser.close()
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
> line 1654, in close
> self._raiseerror(v)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
> line 1506, in _raiseerror
> raise err
> xml.etree.ElementTree.ParseError: no element found: line 1, column 0
> make[4]: *** [menustrings.py] Error 1
> make[3]: [default] Error 2 (ignored)
>
> 
> 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 6, 2016, at 9:04 PM, Michael Barton  wrote:
>
> I'm at home and can't check until tomorrow. Previously, the python make
> section that generated the xml files failed. IIRC, with some other similar
> issues in the past, the error (which might be in the make.log) suggested it
> was looking for 64bit python when I'm compiling with 32bit python because we
> are still stuck with wxPython 2.8.12.
>
> 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
> 

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Michael Barton]

I did make distclean and recomplied, without send the output to a log. I 
searched for menudata.xml in my terminal output and may have found the problem. 
What do  you thing?

ValueError: insecure string pickle
make[4]: *** [xml/menudata.xml] Error 1
make[3]: [default] Error 2 (ignored)
Traceback (most recent call last):
  File "core/toolboxes.py", line 903, in 
sys.exit(main())
  File "core/toolboxes.py", line 887, in main
userDefined=False)
  File "core/toolboxes.py", line 297, in createTree
moduleItems=moduleItems)
  File "core/toolboxes.py", line 334, in toolboxes2menudata
_expandRuntimeModules(root)
  File "core/toolboxes.py", line 634, in _expandRuntimeModules
desc, keywords = _loadMetadata(name)
  File "core/toolboxes.py", line 671, in _loadMetadata
task = gtask.parse_interface(module)
  File 
"/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/task.py",
 line 528, in parse_interface
tree = etree.fromstring(get_interface_description(name))
  File 
"/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/task.py",
 line 480, in get_interface_description
stderr=PIPE)
  File 
"/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/etc/python/grass/script/core.py",
 line 74, in __init__
subprocess.Popen.__init__(self, args, **kwargs)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
 line 710, in __init__
errread, errwrite)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
 line 1334, in _execute_child
child_exception = pickle.loads(data)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
 line 1382, in loads
return Unpickler(file).load()
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
 line 858, in load
dispatch[key](self)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py",
 line 966, in load_string
raise ValueError, "insecure string pickle"
ValueError: insecure string pickle
make[4]: *** [xml/module_tree_menudata.xml] Error 1
make[3]: [default] Error 2 (ignored)
Traceback (most recent call last):
  File "core/menutree.py", line 245, in 
menudata = LayerManagerMenuData(filename)
  File 
"/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/gui/wxpython/lmgr/menudata.py",
 line 42, in __init__
self, filename, expandAddons=expandAddons)
  File 
"/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/gui/wxpython/core/menutree.py",
 line 65, in __init__
xmlTree = etree.parse(filename)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
 line 1182, in parse
tree.parse(source, parser)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
 line 657, in parse
self._root = parser.close()
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
 line 1654, in close
self._raiseerror(v)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
 line 1506, in _raiseerror
raise err
xml.etree.ElementTree.ParseError: no element found: line 1, column 0
make[4]: *** [menustrings.py] Error 1
make[3]: [default] Error 2 (ignored)


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 6, 2016, at 9:04 PM, Michael Barton 
> wrote:

I'm at home and can't check until tomorrow. Previously, the python make section 
that generated the xml files failed. IIRC, with some other similar issues in 
the past, the error (which might be in the make.log) suggested it was looking 
for 64bit python when I'm compiling with 32bit python because we are still 
stuck with wxPython 2.8.12.

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 6, 2016, at 8:57 PM, Vaclav Petras 
> wrote:


On Tue, Dec 6, 2016 at 7:03 

Re: [GRASS-dev] [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Michael Barton]

This works if you are compiling it yourself. But I am providing installable 
binaries for people who do not want to compile or are unable to do so. AFAIK, 
Homebrew does not do this.

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 7, 2016, at 8:59 AM, Rainer M Krug  wrote:
> 
> Adam Dershowitz  writes:
> 
>> Michael,
>> 
>> Was there ever a solution found to running GRASS on the Mac (10.11 or now 
>> 10.12) without disabling SIP? 
> 
> I was using the homebrew way of installing it and it worked with enabled
> SIP.
> 
> No idea about the native way.
> 
> Cheers,
> 
> Rainer
> 
> 
>> 
>> Thanks,
>> 
>> -- Adam
>> 
>> From: grass-user  on behalf of Michael 
>> Barton 
>> Date: Wednesday, June 1, 2016 at 7:50 PM
>> To: GRASS developers list , grass-user grass-user 
>> 
>> Subject: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
>> problem - please test
>> 
>> I just posted a new binary for GRASS 7.3 built fully 64 bit, with wxPython 
>> 3.0.2.0 to the GRASS for Mac site (http://grassmac.wikidot.com) 
>> 
>> It turns out the previous "64bit" GRASS binary still ran 32bit Python. I had 
>> to hack the python_wrapper.py file, but this one is fully 64bit AFAICT. I 
>> also tried
>> some hacks that might be a way to solve the inability to run GRASS on El 
>> Capitan with SIP enabled. There are a couple of known bugs in the wxPython 
>> 3.x
>> GUI
>> 
>> 1. The most serious is switching to 3D mode and back to 2D mode leaves one 
>> of the map display menu buttons corrupted. It seems the only thing you can
>> do is to close the map display and open a new one. 
>> 
>> 2. There are also some popup lists (e.g., for switching mapsets) that do not 
>> behave as they should. You cannot select an item with a mouse (but you can
>> select with arrow keys and ) unless you hit  to destroy part 
>> of the control. Then you can use the mouse to click something. 
>> 
>> Please let us know if you encounter any other bug or strange behavior. 
>> 
>> Also, and importantly if anyone is running El Capitan, it would be great if 
>> you could reenable SIP (if you've turned it off) and see if this version 
>> runs. Of
>> course, maybe I've "fixed" it so that it only runs on my system and crashes 
>> on everyone else's. 
>> 
>> Enjoy!
>> 
>> 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-user mailing list
>> grass-u...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>> 
> 
> -- 
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982

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

Re: [GRASS-dev] [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Michael Barton]

Not yet. Working with a programmer here I think there is a way to do it, but I 
will need help to implement it.

Our idea is to:

1) switch to the new (current) Apple binary install protocol. The one we use is 
deprecated.
2) compile all dependencies outside of /usr/... and in locales not affected by 
SIP
3) package ALL dependencies (including frameworks) in a single installation 
package

If nothing else, it will make installation easier and more reliable with 
respect to dependencies.

#2 would be helped considerably if we could solve the few remaining issues with 
wxPython 3 and switch all to 64 bit.

In the midst of the academic year, I don't have time to do a lot of trial and 
error compiling, but can squeeze in time to test alternative methods.

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 7, 2016, at 7:26 AM, Adam Dershowitz 
> wrote:

Michael,

Was there ever a solution found to running GRASS on the Mac (10.11 or now 
10.12) without disabling SIP?

Thanks,


-- Adam


From: grass-user 
> 
on behalf of Michael Barton 
>
Date: Wednesday, June 1, 2016 at 7:50 PM
To: GRASS developers list 
>, grass-user 
grass-user >
Subject: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

I just posted a new binary for GRASS 7.3 built fully 64 bit, with wxPython 
3.0.2.0 to the GRASS for Mac site 
(http://grassmac.wikidot.com)

It turns out the previous "64bit" GRASS binary still ran 32bit Python. I had to 
hack the python_wrapper.py file, but this one is fully 64bit AFAICT. I also 
tried some hacks that might be a way to solve the inability to run GRASS on El 
Capitan with SIP enabled. There are a couple of known bugs in the wxPython 3.x 
GUI

1. The most serious is switching to 3D mode and back to 2D mode leaves one of 
the map display menu buttons corrupted. It seems the only thing you can do is 
to close the map display and open a new one.

2. There are also some popup lists (e.g., for switching mapsets) that do not 
behave as they should. You cannot select an item with a mouse (but you can 
select with arrow keys and ) unless you hit  to destroy part of 
the control. Then you can use the mouse to click something.

Please let us know if you encounter any other bug or strange behavior.

Also,  and importantly if anyone is running El Capitan, it would be great if 
you could reenable SIP (if you've turned it off) and see if this version runs.  
Of course, maybe I've "fixed" it so that it only runs on my system and crashes 
on everyone else's.

Enjoy!
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] [GRASS GIS] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by hellik):

 Replying to [comment:4 mlennert]:
 > Replying to [comment:1 martinl]:
 > > Import (`v.import/v.in.ogr`) with `encoding=cp1252` will not help?
 >
 > Looking at the file, I do not have the feeling that it is in cp1252, but
 rather in utf-8, so IIUC the parameter setting for v.in.ogr should be
 encoding=utf-8.

 Tried it also with UTF-8,it fails here too.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment gives different results in G72 and G73

[Moritz Lennert]

On 07/12/16 12:13, Martin Landa wrote:

Hi,

2016-12-07 12:11 GMT+01:00 Markus Metz :

OK. Figuring out a reasonable threshold based on small sample regions is
IMHO of general interest for i.segment, because you would expect similar
results when you increase the region. Therefore I think the behaviour in G73
is an improvement.


sorry for bothering you, but is it documented somewhere (in the
manual).


Check r70032. Is that sufficient/correct ?

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

Re: [GRASS-dev] [GRASS GIS] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by mlennert):

 Replying to [comment:1 martinl]:
 > Import (`v.import/v.in.ogr`) with `encoding=cp1252` will not help?

 Looking at the file, I do not have the feeling that it is in cp1252, but
 rather in utf-8, so IIUC the parameter setting for v.in.ogr should be
 encoding=utf-8.

--
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] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by razz):

 Replying to [comment:1 martinl]:
 > Import (`v.import/v.in.ogr`) with `encoding=cp1252` will not help?
 [[BR]]

 encoding=cp1252 in v.in.ogr did not help. And I'm getting them messed even
 with v.db.select but without any error output:


 {{{
 v.db.select map=test_points
 cat|id|names
 1|1|ÄÖÅ
 2||Æ
 3||Ø
 4||Å,å,Æ,æ,Ø,ø
 5||ø, Ø
 6||Þ
 7||Ð
 8||Ã…
 9||æ
 (Wed Dec 07 15:32:51 2016) Command finished (0 sec)
 }}}

 I used the stand-alone installer for both GRASS 7.0.5 and GRASS 7.2.0svn,
 if it matters.

--
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] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---+-
  Reporter:  SCrommelinck  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Imagery   |Version:  unspecified
Resolution:|   Keywords:  SLIC image segmentation
   CPU:  Unspecified   |   Platform:  Unspecified
---+-

Comment (by tgrippa):

 Replying to [comment:13 rashadkm]:
 > Okay. in that case we should decide on module name. i.superpixels.slic
 or i.segment.slic ?
 I think i.superpixels.slic is more interesting in perspective of further
 development of other superpixels methods, but it's only my opinion.

--
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] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---+-
  Reporter:  SCrommelinck  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Imagery   |Version:  unspecified
Resolution:|   Keywords:  SLIC image segmentation
   CPU:  Unspecified   |   Platform:  Unspecified
---+-

Comment (by rashadkm):

 Okay. in that case we should decide on module name. i.superpixels.slic or
 i.segment.slic ?

--
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] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---+-
  Reporter:  SCrommelinck  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Imagery   |Version:  unspecified
Resolution:|   Keywords:  SLIC image segmentation
   CPU:  Unspecified   |   Platform:  Unspecified
---+-

Comment (by mlennert):

 Replying to [comment:11 rashadkm]:
 > could i.segment have an option to choose between slic and other ones?

 It's possible, but:

 * SLIC itself is complex enough that MarkusM suggested it should go into a
 separate module to not overcharge i.segment
 * From what I've seen up to now, the use of superpixels in remote sensing
 is mostly to reduce the number of "pixels" to treat for segmentation. In
 that sense the "segmentation" into superpixels is not exactly the same as
 segmentation using other algorithms. But my experience is limited and the
 differences I see are more semantic than anything else.

--
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] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---+-
  Reporter:  SCrommelinck  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Imagery   |Version:  unspecified
Resolution:|   Keywords:  SLIC image segmentation
   CPU:  Unspecified   |   Platform:  Unspecified
---+-

Comment (by rashadkm):

 could i.segment have an option to choose between slic and other ones?

--
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] #3219: wxnviz: encoding error when exporting image file with accent in name

[GRASS GIS]

#3219: wxnviz: encoding error when exporting image file with accent in name
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.6
 Component:  wxGUI|Version:  unspecified
Resolution:  fixed|   Keywords:  3d image encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 In [changeset:"70031" 70031]:
 {{{
 #!CommitTicketReference repository="" revision="70031"
 wxGUI/nviz: fix #3219 (merge from trunk, r70029)
 }}}

--
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] #3219: wxnviz: encoding error when exporting image file with accent in name

[GRASS GIS]

#3219: wxnviz: encoding error when exporting image file with accent in name
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.6
 Component:  wxGUI|Version:  unspecified
Resolution:  fixed|   Keywords:  3d image encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by annakrat):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"70030" 70030]:
 {{{
 #!CommitTicketReference repository="" revision="70030"
 wxGUI/nviz: fix #3219 (merge from trunk, r70029)
 }}}

--
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] #3219: wxnviz: encoding error when exporting image file with accent in name

[GRASS GIS]

#3219: wxnviz: encoding error when exporting image file with accent in name
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.0.6
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  3d image encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by martinl):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Candidate for backport?

--
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] #3219: wxnviz: encoding error when exporting image file with accent in name

[GRASS GIS]

#3219: wxnviz: encoding error when exporting image file with accent in name
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.6
 Component:  wxGUI|Version:  unspecified
Resolution:  fixed|   Keywords:  3d image encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by annakrat):

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


Comment:

 In [changeset:"70029" 70029]:
 {{{
 #!CommitTicketReference repository="" revision="70029"
 wxGUI/nviz: fix #3219
 }}}

--
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] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-
Changes (by hellik):

 * Attachment "test_points_encoding_errors.zip" added.

 zipped shapefile in wgs84 for testing

--
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] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by hellik):

 Replying to [comment:1 martinl]:
 > Import (`v.import/v.in.ogr`) with `encoding=cp1252` will not help?

 {{{
 v.import encoding=cp1252 input=D:\temp\test_points.shp layer=test_points
 output=testimportcp1252
 WARNING: All available OGR layers will be imported into vector map
 
 Check if OGR layer  contains polygons...
 Importing 9 features (OGR layer )...
 -
 Building topology for vector map ...
 Registering primitives...
 9 primitives registered
 9 vertices registered
 Building areas...
 0 areas built
 0 isles built
 Attaching islands...
 Attaching centroids...
 Number of nodes: 0
 Number of primitives: 9
 Number of points: 9
 Number of lines: 0
 Number of boundaries: 0
 Number of centroids: 0
 Number of areas: 0
 Number of isles: 0
 Input  successfully imported without reprojection
 }}}

 {{{
 v.report map=testimportcp1252@data2 option=coor
 cat|id|names|x|y|z
 1|1|ÄÖÅ|1.37409120951759|47.039352838731|0.0
 2||Æ|2.62326503635168|28.5515802015863|0.0
 3||Ø|44.095836087244|57.2825782187707|0.0
 4||Å,å,Æ,æ,Ø,ø|30.8545935228025|49.787535257766|0.0
 5||ø, Ø|10.1183079973563|51.0367090846001|0.0
 6||Þ|20.361533377396|52.0360481460674|0.0
 8||Ã…|15.1491119517375|60.3621017805262|0.0
 9||æ|-1.26290587954035|52.5879880709736|0.0

 Traceback (most recent call last):
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\gu
 i_core\goutput.py", line 473, in OnCmdOutput

 self.cmdOutput.AddStyledMessage(message, type)
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\gu
 i_core\goutput.py", line 772, in AddStyledMessage

 self.AddTextWrapped(message, wrap=None)
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\gu
 i_core\goutput.py", line 721, in AddTextWrapped

 txt = EncodeString(txt)
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\co
 re\gcmd.py", line 97, in EncodeString

 return string.encode(_enc)
   File "C:\OSGEO4~1\apps\Python27\lib\encodings\cp1252.py",
 line 12, in encode

 return codecs.charmap_encode(input,errors,encoding_table)
 UnicodeDecodeError
 :
 'ascii' codec can't decode byte 0xc3 in position 3: ordinal
 not in range(128)
 }}}

 it doesn't help.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by martinl):

 Import (`v.import/v.in.ogr`) with `encoding=cp1252` will not help?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment gives different results in G72 and G73

[Martin Landa]

Hi,

2016-12-07 12:11 GMT+01:00 Markus Metz :
> OK. Figuring out a reasonable threshold based on small sample regions is
> IMHO of general interest for i.segment, because you would expect similar
> results when you increase the region. Therefore I think the behaviour in G73
> is an improvement.

sorry for bothering you, but is it documented somewhere (in the
manual). Thanks, Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.segment gives different results in G72 and G73

[Markus Metz]

On Wed, Dec 7, 2016 at 11:27 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> On 05/12/16 21:06, Moritz Lennert wrote:
>>
>> On 05/12/16 14:52, Markus Metz wrote:
>>>
>>>
>>>
>>> On Mon, Dec 5, 2016 at 1:46 PM, Martin Landa >> > wrote:


 Hi,

 2016-12-05 9:09 GMT+01:00 Moritz Lennert >>
>>> >:

 > What colleagues here have also noticed is that between the versions
>>>
>>> (but I can't remember if it was 7.0 vs 7.3 or 7.2 vs 7.3) quite
>>> different thresholds were needed to reach similar segmentation results.
>>> In 7.3 reasonable thresholds are often an order of magnitude lower, i.e.
>>> 0.001 instead of 0.01...


 this wasn't my case.
>>>
>>>
>>> I am also getting very similar results with the same threshold. Can your
>>> colleagues provide an example where such different thresholds need to be
>>> used to obtain comparable results?
>
>
> Taïs has prepared an example and can send it by private mail, but he
reminded me of the cause of the difference he observed: in G73 the
threshold is calculated based on the entire image, whereas in G72 the
threshold is calculated based on only the current computational region. We
had asked for this for i.segment.uspo (parameter optimization) as this
module works on small sample subregions, but if the threshold is calculated
based on the region, then the "optimal" threshold values coming out of the
uspo procedure are not comparable between sample regions.

OK. Figuring out a reasonable threshold based on small sample regions is
IMHO of general interest for i.segment, because you would expect similar
results when you increase the region. Therefore I think the behaviour in
G73 is an improvement.

Markus M
>
> See some discussion here:
https://lists.osgeo.org/pipermail/grass-dev/2016-June/080592.html.
>
> Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

[GRASS GIS]

#3220: WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values
-+-
 Reporter:  hellik   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.0
Component:  Default  |Version:  svn-releasebranch72
 Keywords:   |CPU:  Unspecified
 Platform:  MSWindows 8  |
-+-
 taken from the user ML:

 https://lists.osgeo.org/pipermail/grass-user/2016-December/075682.html

 {{{
 I've got shape files with Swedish accented letters (ÄÖÅ) in the some of
 the attribute
 values. The Attributes are shwon as they should in the GUI. SQL
 statements, however,
 are not recognizing them. They're also messed up in the command output if
 another
 (not accented) values are queried.

 I sat GRASS_DB_ENCODING to cp1252 firstly and it didn't work. Then I
 converted the
 dbf file into utf-8 and sat it as the value of the variable, to no avail.
 I also
 tried using the 'encoding' parameter in v.in.ogr in both cases, didn't
 work.

 I tried it on windows 8.1 and windows 10. The same is happening in both,
 stable GRASS
 7.0.5 and GRASS 7.2.0RC1.

 The problem is only happening on Windows. Fedora and Mac OsX don't have
 this issue
 with the same shape files.
 }}}

 https://lists.osgeo.org/pipermail/grass-user/2016-December/075688.html

 {{{
 confirmed with

 GRASS version: 7.3.svn
 GRASS SVN revision: r70001
 Build date: 2016-12-06
 Build platform: x86_64-w64-mingw32
 GDAL: 2.1.2
 PROJ.4: 4.9.3
 GEOS: 3.5.0
 SQLite: 3.14.1
 Python: 2.7.5
 wxPython: 2.8.12.1
 Platform: Windows-8-6.2.9200 (OSGeo4W)
 }}}

 {{{
 and a test vector with following attributes

 v.db.select map=test_points at data file=D:\temp\test_point.txt

 cat|id|names
 1|1|ÄÖÅ
 2||Æ
 3||Ø
 4||Å,å,Æ,æ,Ø,ø
 5||ø, Ø
 6||Þ
 7||Ð
 8||Å
 9||æ
 }}}

 {{{
 d.vect map=test_points2 at data where="names = 'Å,å,Æ,æ,Ø,ø'" width=1
 icon=basic/point size=10

 doesn't show the selected point in the map display.
 }}}

 {{{
 v.report map=test_points at data option=coor
 cat|id|names|x|y|z
 1|1|ÄÖÅ|1.37409120951759|47.039352838731|0.0
 2||Æ|2.62326503635168|28.5515802015863|0.0
 3||Ø|44.095836087244|57.2825782187707|0.0
 4||Å,å,Æ,æ,Ø,ø|30.8545935228025|49.787535257766|0.0
 5||ø, Ø|10.1183079973563|51.0367090846001|0.0
 6||Þ|20.361533377396|52.0360481460674|0.0
 8||Ã…|15.1491119517375|60.3621017805262|0.0
 9||æ|-1.26290587954035|52.5879880709736|0.0

 Traceback (most recent call last):
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\gu
 i_core\goutput.py", line 473, in OnCmdOutput

 self.cmdOutput.AddStyledMessage(message, type)
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\gu
 i_core\goutput.py", line 772, in AddStyledMessage

 self.AddTextWrapped(message, wrap=None)
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\gu
 i_core\goutput.py", line 721, in AddTextWrapped

 txt = EncodeString(txt)
   File "C:\OSGEO4~1\apps\grass\grass-7.3.svn\gui\wxpython\co
 re\gcmd.py", line 97, in EncodeString

 return string.encode(_enc)
   File "C:\OSGEO4~1\apps\Python27\lib\encodings\cp1252.py",
 line 12, in encode

 return codecs.charmap_encode(input,errors,encoding_table)
 UnicodeDecodeError
 :
 'ascii' codec can't decode byte 0xc3 in position 3: ordinal
 not in range(128)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment gives different results in G72 and G73

[Moritz Lennert]

On 05/12/16 21:06, Moritz Lennert wrote:

On 05/12/16 14:52, Markus Metz wrote:



On Mon, Dec 5, 2016 at 1:46 PM, Martin Landa > wrote:


Hi,

2016-12-05 9:09 GMT+01:00 Moritz Lennert >:

> What colleagues here have also noticed is that between the versions

(but I can't remember if it was 7.0 vs 7.3 or 7.2 vs 7.3) quite
different thresholds were needed to reach similar segmentation results.
In 7.3 reasonable thresholds are often an order of magnitude lower, i.e.
0.001 instead of 0.01...


this wasn't my case.


I am also getting very similar results with the same threshold. Can your
colleagues provide an example where such different thresholds need to be
used to obtain comparable results?


Taïs has prepared an example and can send it by private mail, but he 
reminded me of the cause of the difference he observed: in G73 the 
threshold is calculated based on the entire image, whereas in G72 the 
threshold is calculated based on only the current computational region. 
We had asked for this for i.segment.uspo (parameter optimization) as 
this module works on small sample subregions, but if the threshold is 
calculated based on the region, then the "optimal" threshold values 
coming out of the uspo procedure are not comparable between sample regions.


See some discussion here: 
https://lists.osgeo.org/pipermail/grass-dev/2016-June/080592.html.


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

Re: [GRASS-dev] image export of wxgui creates tiff, not png

[Moritz Lennert]

On 06/12/16 19:17, Anna Petrášová wrote:

On Tue, Dec 6, 2016 at 12:26 PM, Moritz Lennert
 wrote:



Le 6 décembre 2016 18:22:09 GMT+01:00, Martin Landa  a 
écrit :

Hi,

2016-12-06 16:58 GMT+01:00 Moritz Lennert
:

I don't know if I missed a message about this, but is it normal that

the

wxgui image export function in the Map Display now exports tiff, not

png

files ?


tiff should be created only when running 3D view. Ma


Ah ok. I was In 3d. Why the différence ?


It is exported using different mechanisms. The 3D image is exported
using the OGSF library, where only tiff and ppm are supported.


Ok, thanks for the explanation. BTW, I found an encoding issue in the 
export:


https://trac.osgeo.org/grass/ticket/3219

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

[GRASS-dev] [GRASS GIS] #3219: wxnviz: encoding error when exporting image file with accent in name

[GRASS GIS]

#3219: wxnviz: encoding error when exporting image file with accent in name
---+-
 Reporter:  mlennert   |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:  7.0.6
Component:  wxGUI  |Version:  unspecified
 Keywords:  3d image encoding  |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 Trying to export a file named '3d_avec_décorations' from the 3D view in
 the wxDisplay, I get:


 {{{
 Traceback (most recent call last):
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-
 linux-gnu/gui/wxpython/mapdisp/frame.py", line 664, in
 SaveToFile

 width, height)
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-
 linux-gnu/gui/wxpython/nviz/mapwindow.py", line 2650, in
 SaveToFile

 self._display.SaveToFile(FileName, width, height, FileType)
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-
 linux-gnu/gui/wxpython/nviz/wxnviz.py", line 1842, in
 SaveToFile

 GS_write_tif(filename)
 ctypes
 .
 ArgumentError
 :
 argument 1: : 'ascii'
 codec can't encode character u'\xe9' in position 24: ordinal
 not in range(128)
 }}}

 Tested both in 7.0.5 and 7.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] python port of r.denoise (testing required)

[Helmut Kudrnovsky]

Carlos Grohmann-2 wrote
> Thanks for testing it Anna.
> 
> I commited some changes: EPSG code is not required in a projected location
> and null values are repected.
> 
> Carlos

just have also a look at

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/r.denoise.log

/addons/r.denoise/scripts/r.denoise.py --html-description < /dev/null | grep
-v '\|' > r.denoise.tmp.html ; fi
ERROR: pyproj not found, install it first: pip install pyproj
   (https://jswhit.github.io/pyproj)
/c/msys64/usr/src/grass_trunk/include/Make/Html.make:14: recipe for target
'r.denoise.tmp.html' failed
make: *** [r.denoise.tmp.html] Error 1
rm r.denoise.tmp.html

76  # pyproj
77  try:
78  import pyproj
79  except ImportError:
80  grass.fatal(_("pyproj not found, install it first: pip install 
pyproj
(https://jswhit.github.io/pyproj)"))

maybe this should go into 

143 def main():

that compiling works at least if pyproj isn't installed?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/python-port-of-r-denoise-testing-required-tp5298395p5299010.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] [GRASS-user] GRASS 7.2 install and Peals.A!cl

[Helmut Kudrnovsky]

Moritz Lennert wrote
> On 06/12/16 23:42, Martin Landa wrote:
>> Hi,
>>
>> 2016-12-06 23:28 GMT+01:00 john polo 

> jpolo@.usf

> :
>>> I downloaded GRASS 7.2 and installed. The download came from this link:
>>> https://grass.osgeo.org/news/65/15/GRASS-GIS-7-2-0RC2-released/
>>>
>>> As GRASS was installing, Microsoft Security Essentials said that it
>>> detected
>>> a trojan called Peals.A!cl. This trojan was found in GRASS GIS
>>> 7.2.0RC2\bin\v.in.dxf.exe, ...\v.net.iso.exe, and ... \v.out.dxf.exe.
>>> Can
>>
>> ah, these Windows. I tested binaries on build server with Esset
>> Endpoint Antivirus and nothing is found. So I hope it's mistake of
>> MSE...
>>
> 
> Could someone else using Windows check this ? It would be big issue if 
> we released with a trojan !


tested here with symantec, nothing found:  check.txt
  .

it's a false positive.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-GRASS-7-2-install-and-Peals-A-cl-tp5298995p5299003.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] [GRASS-user] GRASS 7.2 install and Peals.A!cl

[Moritz Lennert]

On 06/12/16 23:42, Martin Landa wrote:

Hi,

2016-12-06 23:28 GMT+01:00 john polo :

I downloaded GRASS 7.2 and installed. The download came from this link:
https://grass.osgeo.org/news/65/15/GRASS-GIS-7-2-0RC2-released/

As GRASS was installing, Microsoft Security Essentials said that it detected
a trojan called Peals.A!cl. This trojan was found in GRASS GIS
7.2.0RC2\bin\v.in.dxf.exe, ...\v.net.iso.exe, and ... \v.out.dxf.exe. Can


ah, these Windows. I tested binaries on build server with Esset
Endpoint Antivirus and nothing is found. So I hope it's mistake of
MSE...


anyone confirm if this is a legitimate threat or was M.S.E. just acting
buggy? Is there an MD5 or something to check the file?



On [1] I see:

"NOTE: On December 6, 2016, an incorrect detection for our cloud-based 
protection for Trojan:Win32/Peals.A!cl was identified and immediately 
fixed. To ensure that this issue is remediated, you can do a forced 
daily update to download your Microsoft antimalware and antispyware 
software. For details, see Updating your Microsoft antimalware and 
antispyware software."


John, could you try to update and then check again ?

Moritz

[1] 
https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan%3AWin32%2FPeals.A!plock=-2147276824



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

Re: [GRASS-dev] [GRASS-user] GRASS 7.2 install and Peals.A!cl

[Moritz Lennert]

On 06/12/16 23:42, Martin Landa wrote:

Hi,

2016-12-06 23:28 GMT+01:00 john polo :

I downloaded GRASS 7.2 and installed. The download came from this link:
https://grass.osgeo.org/news/65/15/GRASS-GIS-7-2-0RC2-released/

As GRASS was installing, Microsoft Security Essentials said that it detected
a trojan called Peals.A!cl. This trojan was found in GRASS GIS
7.2.0RC2\bin\v.in.dxf.exe, ...\v.net.iso.exe, and ... \v.out.dxf.exe. Can


ah, these Windows. I tested binaries on build server with Esset
Endpoint Antivirus and nothing is found. So I hope it's mistake of
MSE...



Could someone else using Windows check this ? It would be big issue if 
we released with a trojan !


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

Re: [GRASS-dev] [GRASS GIS] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---+-
  Reporter:  SCrommelinck  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Imagery   |Version:  unspecified
Resolution:|   Keywords:  SLIC image segmentation
   CPU:  Unspecified   |   Platform:  Unspecified
---+-

Comment (by mlennert):

 Ok, so we agree on option 2, i.e. a native GRASS implementation
 translating the original C++ code.

 And as Markus mentions it should include the SLICO version. Maybe as a
 flag ? Something like: i.superpixels.slic with a flag -o for SLICO ? Or
 i.slic -o ? Or i.segment.slic ? If we plan on implementing other
 superpixel approaches the i.superpixels.slic might be the way to go...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] t.rast.out.xyz not exporting all cells in the computational region

[Veronica Andreo]

Hi,

2016-12-06 23:24 GMT+01:00 Martin Landa :

> Hi,
>
> 2016-12-06 23:06 GMT+01:00 Markus Neteler :
> > I have submitted a new -i flag to include no data values (r70017).
> > This can be used for  t.rast.out.xyz and backported for 7.2.1.
>

IMHO, if we wait to backport this new flag in r.out.xyz until 7.2.1, then
t.rast.out.xyz could only be modified after that and this might happen in
~3-4 months from now according to a previous email from Martin. What I mean
is that the original problem that was regarding exporting time series
containing NULL values with t.rast.out.xyz, is then not solved, but
postponed some months. Otherwise, we would have an add-on (t.rast.out.xyz)
with features that only works along with trunk and that is not desirable,
right?

Sorry if I create more noise here, honestly, I am not aware of the
drawbacks of backporting right away :-(

best,
Vero


> recorded at [1]. Does it mean that we can go ahead and release 7.2.0? Ma
>
> [1] https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.2.1tobebackported
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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