Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

[Glynn Clements]

Vaclav Petras wrote:

> I was not able to determine from svn why gmath.h contains la.h.

AFAICT, it's because the functions are in lib/gmath. Of course, that
then brings up the question why they're there, rather than in a
separate library ...

Incidentally, the whole of lib/gmath/la.c is conditionalised upon

#if defined(HAVE_LIBLAPACK) && defined(HAVE_LIBBLAS)

but individual functions (and even sections of functions) are
conditionalised as necessary.

And there are a few functions for which we could reasonably supply our
own implementation if BLAS/LAPACK aren't available. E.g. 
G_matrix_product() and G_vector_norm_euclid() should be
straightforward.

AFAICT, G_matrix_LU_solve() is the only function that's moderately
complex.

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

Re: [GRASS-dev] wx.metadata ready for testing

[Blumentrath, Stefan]

Hi Martin,

Thanks for your patience.

Here is my shell output:

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GIS
GISRC=/tmp/grass7-stefan-19203/gisrc
GISBASE=/usr/local/grass-7.1.svn
GIS_LOCK=19203

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GRASS
GRASS_PYTHON=python
GRASS_GNUPLOT=gnuplot -persist
GRASS_PAGER=more
GRASS_ADDON_PATH=/home/stefan/grass-addons/
GRASS_PROJSHARE=/usr/local/share/proj
GRASS_VERSION=7.1.svn
GRASS_SKIP_MAPSET_OWNER_CHECK=1
GRASS_HTML_BROWSER=xdg-open
GRASS_ADDON_BASE=/home/stefan/.grass7/addons

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > export 
GRASS_ADDON_PATH=/home/stefan/.grass7/addons/

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GRASS
GRASS_PYTHON=python
GRASS_GNUPLOT=gnuplot -persist
GRASS_PAGER=more
GRASS_ADDON_PATH=/home/stefan/.grass7/addons/
GRASS_PROJSHARE=/usr/local/share/proj
GRASS_VERSION=7.1.svn
GRASS_SKIP_MAPSET_OWNER_CHECK=1
GRASS_HTML_BROWSER=xdg-open
GRASS_ADDON_BASE=/home/stefan/.grass7/addons

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > g.extension wx.metadata
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/tmp/grass7-stefan-19203/tmpQpQIQ7/wx.metadata/scripts/db.csw.admin", 
line 127, in 
from cswutil import *
ImportError: No module named cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
/bin/sh: 1: cannot create /usr/local/grass-7.1.svn/error.log: Permission denied
make: *** [db.csw.admin] Error 2
ERROR: Compilation failed, sorry. Please check above error messages.

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > g.version -g
version=7.1.svn
date=2015
revision=66426M
build_date=2015-10-07
build_platform=x86_64-unknown-linux-gnu
build_off_t_size=8

Cheers
Stefan

-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Martin Landa
Sent: 7. oktober 2015 22:30
To: Paulo van Breugel 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] wx.metadata ready for testing

Hi,

2015-10-07 12:30 GMT+02:00 Paulo van Breugel :

I tried fresh installation (trunk) in installed to /usr/local. I cannot 
reproduce any of reported errors. Please send me related environmental 
variables:

env | grep GIS

env | grep GRASS

?

Ma

> ware/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
>> >>> /usr/local/grass7/grass-7.1.svn/error.log
>> >
>> > make[1]: Entering directory
>> >
>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>> >
>> > if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" 
>> > ] ; then
>> > GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
>> > GISBASE=/usr/local/grass7/grass-7.1.svn
>> >
>> > PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
>> >
>> > PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
>> >
>> > LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
>> > LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
>> > --html-description < /dev/null | grep -v '\|' > 
>> > g.gui.metadata.tmp.html ; fi
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", 
>> > line 35, in 
>> >
>> > import mdgrass
>> >
>> > ImportError: No module named mdgrass
>> >
>> > make[1]: *** [g.gui.metadata.tmp.html] Error 1
>> >
>> > rm g.gui.metadata.tmp.html
>> >
>> > make[1]: Leaving directory
>> >
>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>> >
>> >
>> >
>> >>
>> >
>>
>>
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>
>



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

Re: [GRASS-dev] wx.metadata ready for testing

[Martin Landa]

Hi,

2015-10-07 12:30 GMT+02:00 Paulo van Breugel :

I tried fresh installation (trunk) in installed to /usr/local. I
cannot reproduce any of reported errors. Please send me related
environmental variables:

env | grep GIS

env | grep GRASS

?

Ma

> ware/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
>> >>> /usr/local/grass7/grass-7.1.svn/error.log
>> >
>> > make[1]: Entering directory
>> >
>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>> >
>> > if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" ] ;
>> > then
>> > GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
>> > GISBASE=/usr/local/grass7/grass-7.1.svn
>> >
>> > PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
>> >
>> > PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
>> >
>> > LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
>> > LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
>> > --html-description < /dev/null | grep -v '\|' >
>> > g.gui.metadata.tmp.html ; fi
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", line
>> > 35, in
>> > 
>> >
>> > import mdgrass
>> >
>> > ImportError: No module named mdgrass
>> >
>> > make[1]: *** [g.gui.metadata.tmp.html] Error 1
>> >
>> > rm g.gui.metadata.tmp.html
>> >
>> > make[1]: Leaving directory
>> >
>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>> >
>> >
>> >
>> >>
>> >
>>
>>
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>
>



-- 
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] Grass Data Explorer QGIS Plugin

[Sören Gebbert]

Dear all,
just for your information:

I have implemented a simple QGIS Plugin to browse and visualize GRASS
GIS raster, vector and time series data in a fast way. It is not
designed to run any GRASS GIS processing modules or to create, remove
or modify GRASS GIS map layers.

The Plugin is implemented in Python and makes use of PyGRASS and the
GRASS GIS Temporal Framework. The use of the PyGRASS RPC interface
should avoid any G_fatal_error crashes. However, it introduces instead
stalled pipes, hanging processes and forever waiting RPC calls.

It allows IMHO fast visualization of raster map layers directly from a
GRASS GIS database, without conversion or export.

Vector maps are converted into QGIS memory layers, to allow all the
great and fancy QGIS vector layer visualization features.

A specific feature is the analysis of space time raster datasets
(STRDS), which are visualized as a specific layer in QGIS. The
corresponding raster
map layers can be switched directly in the STRDS layer settings. In
addition some basic statistical analysis can be performed on the
selected temporal raster map layer and the whole time series. SQL
WHERE statements can be used to select specific raster layer subsets
in the STRDS layer settings.

The Plugin is available here:
https://bitbucket.org/huhabla/grass-data-explorer/wiki/Home

I will not put it into the official QGIS Plugin repository, since it
is too experimental and will be modified a lot.

Be aware that this plugin only works with a very recent GRASS GIS 7.1
svn version.

To run the plugin, QGIS must be started from within an active GRASS
GIS session. Switching mapsets or locations is not supported.

The plugin is highly experimental and has a lot of bugs. Hence, after
closing QGIS, run "killall -9 qgis" to kill all the RPC processes,
that are spawned to enable parallel data access.

Use it on your own risk!! However, for me it is already very useful. :)

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

Re: [GRASS-dev] [GRASS GIS] #2419: v.distance: hole considered as nearest area

[GRASS GIS]

#2419: v.distance: hole considered as nearest area
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  6.4.6
 Component:  Vector   |Version:  svn-releasebranch64
Resolution:   |   Keywords:  v.distance holes
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [comment:1 mmetz]:
 > Fixed in r61987,8.

 Can the ticket be closed?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.rast.stats: NULL values for very small areas

[Maris Nartiss]

2015-10-06 19:26 GMT+03:00 Moritz Lennert :
>> I just wonder how to implement within Python script.
>
>
> Get areas of all polygons (or lenghts of lines) with v.to.db and then divide
> the features into those with areas above pixel size and those with areas
> below. Treat each set differently (i.e. the former as before, the latter by
> using v.what.rast - with the -p flag - to get the pixel value). As the
> updating of the table is done feature by feature anyhow, all you lose in
> terms of performance is the additional step of calculating areas/lengths of
> features.
>

First of all - v.rast.stats is not affected by the size of polygon but
by its shape/location. It uses v.to.rast thus data will be provided if
raster cell centre falls into vector polygon (no matter how small it
could be). Thus theoretically it is possible to construct a large
polygon that still gets NULL value.
Thus the discussion should be - should statistics be collected also
for cells that only partially lie within the polygon. Raster cell is
the smallest unit and it is homogeneous thus interpretation "collect
data on all cells even if polygon just touches it" might seem to be a
valid idea. Proposed solution with v.what.rast is not a solution as it
will sample raster map at the location of centroid thus in case of
polygon covering more than one cell, a value of one of cells will be
provided.

Personally I tend to favour current behaviour. It could be a bit
better documented as current documentation states: "The vector map
will be rasterized according to the raster map resolution." It is
correct but an extra explanation would be helpful like: "Stats are
provided only for polygons covering raster cell centres (or whole
raster cell area)."

Just my 0.02c,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.rast.stats: NULL values for very small areas

[Blumentrath, Stefan]

Hi,

What about a flag for checking if all polygon categories are present in the 
raster version of the vector map, and giving a warning if that is not the case.

That will take more time but makes output more reliable.

Maybe one can - in case of non-rasterized polygons/lines - edit the raster map 
by writing cats to cells containing centroids (or midpoints for lines)

However, also then - in case of significant mismatch between map scale and 
resolution of the region - can cats be not present in the raster (if more than 
one centroid falls into a cell). That only indicates that the user either has 
to rethink settings, choose another approach (repeat the command for only the 
non-rasterized polygons) or ignore the issues...

Cheers
Stefan

-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Maris Nartiss
Sent: 7. oktober 2015 10:23
To: Moritz Lennert 
Cc: Martin Landa ; GRASS developers list 

Subject: Re: [GRASS-dev] v.rast.stats: NULL values for very small areas

2015-10-06 19:26 GMT+03:00 Moritz Lennert :
>> I just wonder how to implement within Python script.
>
>
> Get areas of all polygons (or lenghts of lines) with v.to.db and then 
> divide the features into those with areas above pixel size and those 
> with areas below. Treat each set differently (i.e. the former as 
> before, the latter by using v.what.rast - with the -p flag - to get 
> the pixel value). As the updating of the table is done feature by 
> feature anyhow, all you lose in terms of performance is the additional 
> step of calculating areas/lengths of features.
>

First of all - v.rast.stats is not affected by the size of polygon but by its 
shape/location. It uses v.to.rast thus data will be provided if raster cell 
centre falls into vector polygon (no matter how small it could be). Thus 
theoretically it is possible to construct a large polygon that still gets NULL 
value.
Thus the discussion should be - should statistics be collected also for cells 
that only partially lie within the polygon. Raster cell is the smallest unit 
and it is homogeneous thus interpretation "collect data on all cells even if 
polygon just touches it" might seem to be a valid idea. Proposed solution with 
v.what.rast is not a solution as it will sample raster map at the location of 
centroid thus in case of polygon covering more than one cell, a value of one of 
cells will be provided.

Personally I tend to favour current behaviour. It could be a bit better 
documented as current documentation states: "The vector map will be rasterized 
according to the raster map resolution." It is correct but an extra explanation 
would be helpful like: "Stats are provided only for polygons covering raster 
cell centres (or whole raster cell area)."

Just my 0.02c,
Māris.
___
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] v.rast.stats disables MASK

[Martin Landa]

Hi,

2015-10-07 7:05 GMT+02:00 Maris Nartiss :
> This definitely needs a flag + explanation in documentation.
>
> Taking into account philosophy behind GRASS raster processing, I would
> say - default should be to apply MASK, as MASK affects all raster
> reading operations (unless stated otherwise or requested by user).

+1 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] GRASS and Mac OS X El Capitan

[Rainer M Krug]

Michael Barton  writes:

> But it was never clear what was and was not working. We have this
> working fine in Yosemite. So far, you are the only ones to report a
> problem with Yosemite. The problem we are reporting now is that it was
> running on Yosemite and not running on El Capitan. Maybe that is the
> same thing, but maybe not. That said, I plan on a recompile, but have
> been stuck on the laslib problem. I hope to have time to get that
> compiled on Thursday. I haven’t had much input so it has been a lot of
> trial and error. Once it is working with current gdal, I can recompile
> new binaries.

Just to add an (unrelated?) datapoint: I installed grass 70 and 71 under
Yosemite using homebrew and tried just now unde El Capitan, and both
still run the gui.

Rainer


>
> 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 Oct 6, 2015, at 2:11 PM, Anna Petrášová 
> > wrote:
>
>
>
> On Tue, Oct 6, 2015 at 4:56 PM, Michael Barton 
> > wrote:
> This is a binary I created and posted to my web site not too long
> ago. It worked fine before upgrading and works fine on people’s
> machines that have not upgraded. So this worries me.
>
> I informed you couple of weeks ago when you posted them that they are
> not working on my and Helena's Mac with the exact same problem (we
> have Yosemite). As I said before couple of times and as Markus said
> now, this error suggests that fresh recompilation could help.
>
> BTW I fixed import order couple of weeks ago, so this shouldn't happen again.
>
>
>
> I’m hoping soon to have time to complete the complicated effort to
> recompile laslib so I can make new binaries before I think about
> upgrading to the new OS X. But I will be compiling them on the
> penultimate version of the OS (prior to El Capitan, released a few
> days ago).
>
>  We are able to compile GRASS on Mac, although we haven't tried to compile 
> liblas.
>
> Anna
>
> 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 Oct 6, 2015, at 12:02 PM, Markus Neteler 
>> > wrote:
>>
>> On Tue, Oct 6, 2015 at 8:56 PM, Michael Barton 
>> > wrote:
>>> A couple of my students upgraded to the new Mac OS, El Capitan, and can no
>>> longer run GRASS.
>>>
>>> We tried a work around that disabled one of the new security settings. This
>>> got the launch process further, but it still bombed. Has anyone had any luck
>>> with this yet?
>>>
>>> Here is the error:
>>>
>>> Launching  GUI in the background, please wait...
>>>
>>> GRASS 7.0.1 (MedLambertA):~ > Traceback (most recent call last):
>> ...
>>>  File
>>> "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py",
>>> line 30, in 
>>>from iclass.digit   import IClassVDigit
>>>
>>>  File
>>> "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py",
>>> line 23, in 
>>>from vdigit.wxdisplay import DisplayDriver, TYPE_AREA
>>>
>>> ImportError: cannot import name TYPE_AREA
>>
>> There is a (closed) ticket:
>> https://trac.osgeo.org/grass/ticket/2538
>>
>> and an email
>> https://lists.osgeo.org/pipermail/grass-dev/2013-September/065580.html
>>
>> ... both indicating the same solution:
>> * "Ok. Don't know what happened to my source tree, but with a fresh
>> checkout I can start the GUI again. False alarm. Sorry for the noise.
>> "
>> * "fixed by rebuilding svn tree from scratch and compiling from it"
>>
>> Perhaps this will also help today?
>>
>> Markus
>
> ___
> 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

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___

Re: [GRASS-dev] wx.metadata ready for testing

[Paulo van Breugel]

On 06-10-15 11:40, Martin Landa wrote:

Hi,

2015-10-05 10:39 GMT+02:00 Matej Krejci :

  I just checked .grass7/addons/etc/wx.metadata and installation deployed
only /mdlib dir but no /configure and /profiles dirs. It is the same issue
like r.green[1]. Correctly placed directories should looks like:

should be fixed in r66417. Testing welcome. Martin


Hi, just tried to install wx.metadata, using g.extension and by 
compiling directly. As far as I know all dependencies are installed. The 
full output when compiling from source:


make -C mdlib || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib >> 
/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib'

make[1]: Nothing to be done for `first'.

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib'

make -C profiles || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/profiles >> 
/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/profiles'

make[1]: Nothing to be done for `first'.

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/profiles'

make -C config || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/config >> 
/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/config'

make[1]: Nothing to be done for `first'.

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/config'

make -C r.info.iso || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/r.info.iso 
>> /usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/r.info.iso'

GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71 GISBASE=/usr/local/grass7/grass-7.1.svn 
PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH" 
PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH" 
LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
 LC_ALL=C g.parser -t r.info.iso.py | sed s/\"/\"/g | sed 's/.*/_("&")/' > 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/r.info.iso_to_translate.c

/bin/sh: 1: cannot create 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/r.info.iso_to_translate.c: 
Directory nonexistent

make[1]: 
[/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/r.info.iso_to_translate.c]
 Error 2 (ignored)

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/r.info.iso'

make -C v.info.iso || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/v.info.iso 
>> /usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/v.info.iso'

GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71 GISBASE=/usr/local/grass7/grass-7.1.svn 
PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH" 
PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH" 
LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
 LC_ALL=C g.parser -t v.info.iso.py | sed s/\"/\"/g | sed 's/.*/_("&")/' > 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/v.info.iso_to_translate.c

/bin/sh: 1: cannot create 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/v.info.iso_to_translate.c: 
Directory nonexistent

make[1]: 
[/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/v.info.iso_to_translate.c]
 Error 2 (ignored)

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/v.info.iso'

make -C t.info.iso || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/t.info.iso 
>> /usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/t.info.iso'

GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71 GISBASE=/usr/local/grass7/grass-7.1.svn 
PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH" 

Re: [GRASS-dev] [GRASS GIS] #2735: t.rast.mapcalc input problem

[GRASS GIS]

#2735: t.rast.mapcalc input problem
--+
  Reporter:  leohardtke   |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.0.1
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.rast.mapcalc
   CPU:  Unspecified  |   Platform:  Linux
--+
Changes (by huhabla):

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


Comment:

 This bug was not fixed in t.rast.mapcalc. A similar bug was fixed in
 t.rast.extract.

 However, fixing the bug in t.rast.mapcalc is more difficult since it uses
 a simple search and replace approach to substitute the input STRDS with
 map names and is not aware of what a space time dataset is. If the names
 of input and output space time datasets are include each other, then the
 module does not work properly. Choosing a specific order of the input
 STRDS in the input parameter (i.e: input=ndvi_smooth,QA_mask,ndvi) may
 reduce the risk of wrong substitution.

 However, please use t.rast.algebra instead. This module has other issues
 but is able to correctly identify space time datasets.

--
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 and Mac OS X El Capitan

[Agustin Diez Castillo]

After updating,
wxpython not working here but tcltk still works (grass 6.4 from kyngchaos), see 
below for results with 7.1
Launching 'wxpython' GUI in the background, please wait ...
Traceback (most recent call last):
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line 
27, in 
from core import globalvar
  File 
"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py", 
line 76, in 
import wx
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 
from wx._core import *
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 
import _core_
ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: /Users/Shared/unix/wxpython-snow/lib/libwx_macud-2.8.0.dylib
  Referenced from: 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
  Reason: image not found

grass 7.1 not working here
 '/Applications/GRASS/GRASS-7.1.app/Contents/MacOS/grass.sh'; exit
Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
Python 2.7.10 found.
Traceback (most recent call last):
  File "/Applications/GRASS/GRASS-7.1.app/Contents/MacOS/grass71", line 1380, 
in 
set_language()
  File "/Applications/GRASS/GRASS-7.1.app/Contents/MacOS/grass71", line 821, in 
set_language
language, encoding = locale.getdefaultlocale()
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
 line 543, in getdefaultlocale
return _parse_localename(localename)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
 line 475, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

> El Oct 7, 2015, a las 01:15, Michael Barton  escribió:
> 
> But it was never clear what was and was not working. We have this working 
> fine in Yosemite. So far, you are the only ones to report a problem with 
> Yosemite. The problem we are reporting now is that it was running on Yosemite 
> and not running on El Capitan. Maybe that is the same thing, but maybe not. 
> That said, I plan on a recompile, but have been stuck on the laslib problem. 
> I hope to have time to get that compiled on Thursday. I haven’t had much 
> input so it has been a lot of trial and error. Once it is working with 
> current gdal, I can recompile new binaries.
> 
> 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 Oct 6, 2015, at 2:11 PM, Anna Petrášová > > wrote:
>> 
>> 
>> 
>> On Tue, Oct 6, 2015 at 4:56 PM, Michael Barton > > wrote:
>> This is a binary I created and posted to my web site not too long ago. It 
>> worked fine before upgrading and works fine on people’s machines that have 
>> not upgraded. So this worries me.
>> 
>> I informed you couple of weeks ago when you posted them that they are not 
>> working on my and Helena's Mac with the exact same problem (we have 
>> Yosemite). As I said before couple of times and as Markus said now, this 
>> error suggests that fresh recompilation could help. 
>> 
>> BTW I fixed import order couple of weeks ago, so this shouldn't happen again.
>> 
>> 
>> 
>> I’m hoping soon to have time to complete the complicated effort to recompile 
>> laslib so I can make new binaries before I think about upgrading to the new 
>> OS X. But I will be compiling them on the penultimate version of the OS 
>> (prior to El Capitan, released a few days ago).
>> 
>>  We are able to compile GRASS on Mac, although we haven't tried to compile 
>> liblas. 
>> 
>> Anna
>> 
>> 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 Oct 6, 2015, at 

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Vaclav Petras]

On Wed, Oct 7, 2015 at 8:45 PM, Seth Price  wrote:

> I figured it out. I had to `make clean && make && sudo make install` to
> get unit tests working as expected.
>

Makes sense. I should have suggested that. I was doing make distclean
automatically out of a habit since the change is in the library.


>
> I just uploaded a new version of the code that shouldn't fail any
> additional unit tests, and I've added unit tests to r.compress that test
> reading/writing the different compression schemes.
>

Glad to hear that. Replied to the ticket (copy goes to grass-dev):

https://trac.osgeo.org/grass/ticket/2750#comment:6

~Seth
>
> On Tue, Oct 6, 2015 at 5:54 AM, Vaclav Petras 
> wrote:
>
>>
>> On Tue, Oct 6, 2015 at 1:42 AM, Seth Price  wrote:
>>
>>> Sorry for derailing my own thread, but here we go again...
>>> I'm having a hard time reproducing anything with the unit tests. There
>>> seems to be some state that exists between unit test runs.
>>>
>>
>> What are the actual errors in the HTML report?
>>
>>
>>> I ran it with my updated code, and I got 30% failed. Then I ran the new
>>> code with the tests, and I'm getting 30% failed. So I deleted the basic
>>> location directory and re-decompressed it. Now I'm getting 31% failed in
>>> both directories.
>>>
>>
>>
>>> Using these commands, as shown above, resulted in 21% failed. I'm
>>> running `make && sudo make install` when I switch directories. Then I
>>> delete & refresh the location files. Then I run the unit tests as `python
>>> -m grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc`.
>>> What's wrong with my test procedure?
>>>
>>
>> Sorry, I don't understand what is the difference between new code and
>> updated code. When you get 30, 31 21%? What are the actual commands you are
>> running?
>>
>> If you are concerned about reproducibility, use VM or Docker, e.g. with
>> Ubuntu [1]. In this way, we can see if it is a local or Mac issue or not.
>>
>> [1] https://github.com/wenzeslaus/grass-gis-docker
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

I figured it out. I had to `make clean && make && sudo make install` to get
unit tests working as expected.

I just uploaded a new version of the code that shouldn't fail any
additional unit tests, and I've added unit tests to r.compress that test
reading/writing the different compression schemes.
~Seth

On Tue, Oct 6, 2015 at 5:54 AM, Vaclav Petras  wrote:

>
> On Tue, Oct 6, 2015 at 1:42 AM, Seth Price  wrote:
>
>> Sorry for derailing my own thread, but here we go again...
>> I'm having a hard time reproducing anything with the unit tests. There
>> seems to be some state that exists between unit test runs.
>>
>
> What are the actual errors in the HTML report?
>
>
>> I ran it with my updated code, and I got 30% failed. Then I ran the new
>> code with the tests, and I'm getting 30% failed. So I deleted the basic
>> location directory and re-decompressed it. Now I'm getting 31% failed in
>> both directories.
>>
>
>
>> Using these commands, as shown above, resulted in 21% failed. I'm running
>> `make && sudo make install` when I switch directories. Then I delete &
>> refresh the location files. Then I run the unit tests as `python -m
>> grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc`.
>> What's wrong with my test procedure?
>>
>
> Sorry, I don't understand what is the difference between new code and
> updated code. When you get 30, 31 21%? What are the actual commands you are
> running?
>
> If you are concerned about reproducibility, use VM or Docker, e.g. with
> Ubuntu [1]. In this way, we can see if it is a local or Mac issue or not.
>
> [1] https://github.com/wenzeslaus/grass-gis-docker
>
___
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

[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 wenzeslaus):

 Replying to [comment:5 sprice]:
 > I just uploaded a new version of the code that shouldn't fail any
 additional unit tests, and I've added unit tests to r.compress that test
 reading/writing the different compression schemes.

 Nice. Runs for me as well. Test is well written, but to be sure, please
 improve setting of the environmental variables. When you do
 `os.environ[env_var] = '1'`, `env_var` stays in the environment, so next
 time it might be picked up (to be honest, right now I don't understand why
 it is not picked up). You can run a module in an isolated environment by
 something like this:

 {{{
 env = os.environ.copy()
 env[env_var] = '1'
 ...Module(..., env_=env)
 }}}

 I haven't tried that but in theory it should work with all `*Module`
 functions as well as classes (all is based on
 
[https://grass.osgeo.org/grass70/manuals/libpython/pygrass.modules.interface.html
 #module-pygrass.modules.interface.module PyGRASS Module]).

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

[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
--+---
Changes (by sprice):

 * Attachment "lz4_zstd3.tgz" 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] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

[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):

 I just uploaded a new version of the code that shouldn't fail any
 additional unit tests, and I've added unit tests to r.compress that test
 reading/writing the different compression schemes.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] wx.metadata ready for testing

[Martin Landa]

Hi,

2015-10-07 10:14 GMT+02:00 Paulo van Breugel :
> make -C mdlib || echo
> /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib >>
> /usr/local/grass7/grass-7.1.svn/error.log

it seems to me that `g.extension` is trying to install addons to
/usr/local. Are you sure that you are not using `-s` flag or
GRASS_ADDON_BASE which points to /usr/local/grass7 ... ?

Martin

>
> rm g.gui.cswbrowser.tmp.html
>
> make[1]: Leaving directory
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.cswbrowser'
>
> make -C g.gui.metadata || echo
> /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
>>> /usr/local/grass7/grass-7.1.svn/error.log
>
> make[1]: Entering directory
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>
> if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" ] ; then
> GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
> GISBASE=/usr/local/grass7/grass-7.1.svn
> PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
> PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
> LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
> LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
> --html-description < /dev/null | grep -v '\|' >
> g.gui.metadata.tmp.html ; fi
>
> Traceback (most recent call last):
>
>   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", line 35, in
> 
>
> import mdgrass
>
> ImportError: No module named mdgrass
>
> make[1]: *** [g.gui.metadata.tmp.html] Error 1
>
> rm g.gui.metadata.tmp.html
>
> make[1]: Leaving directory
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>
>
>
>>
>



-- 
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] wx.metadata ready for testing

[Paulo van Breugel]

On Wed, Oct 7, 2015 at 11:48 AM, Martin Landa 
wrote:

> Hi,
>
> 2015-10-07 10:14 GMT+02:00 Paulo van Breugel :
> > make -C mdlib || echo
> > /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib
> >>
> > /usr/local/grass7/grass-7.1.svn/error.log
>
> it seems to me that `g.extension` is trying to install addons to
> /usr/local. Are you sure that you are not using `-s` flag or
> GRASS_ADDON_BASE which points to /usr/local/grass7 ... ?
>

Not that I know. Also, all other addons install fine. I tried it again,
after removing the folder .grass7 first (i.e., clean start). Using
g.extention, the output was:

Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/tmp/grass7-paulo-27306/tmpqqEFqa/wx.metadata/script
s/db.csw.admin", line 127, in 
from cswutil import *
ImportError: No module named cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-27306/tmpqqEFqa/wx.metadata/script
s/g.gui.cswbrowser", line 22, in 
from cswlib import CSWBrowserPanel, CSWConnectionPanel
ImportError: No module named cswlib
make[1]: *** [g.gui.cswbrowser.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-27306/tmpqqEFqa/wx.metadata/script
s/g.gui.metadata", line 35, in 
import mdgrass
ImportError: No module named mdgrass
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-27306/tmp
qqEFqa/wx.metadata/docs/html/db.csw.admin.html’: No such
file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-27306/tmp
qqEFqa/wx.metadata/docs/html/g.gui.cswbrowser.html’: No
such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-27306/tmp
qqEFqa/wx.metadata/docs/html/g.gui.metadata.html’: No such
file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
WARNING: Installation failed, sorry. Please check above error messages.



>
> Martin
>
> >
> > rm g.gui.cswbrowser.tmp.html
> >
> > make[1]: Leaving directory
> >
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.cswbrowser'
> >
> > make -C g.gui.metadata || echo
> >
> /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
> >>> /usr/local/grass7/grass-7.1.svn/error.log
> >
> > make[1]: Entering directory
> >
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
> >
> > if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" ] ;
> then
> > GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
> > GISBASE=/usr/local/grass7/grass-7.1.svn
> >
> PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
> >
> PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
> >
> LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
> > LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
> > --html-description < /dev/null | grep -v '\|' >
> > g.gui.metadata.tmp.html ; fi
> >
> > Traceback (most recent call last):
> >
> >   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", line
> 35, in
> > 
> >
> > import mdgrass
> >
> > ImportError: No module named mdgrass
> >
> > make[1]: *** [g.gui.metadata.tmp.html] Error 1
> >
> > rm g.gui.metadata.tmp.html
> >
> > make[1]: Leaving directory
> >
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
> >
> >
> >
> >>
> >
>
>
>
> --
> 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] [GRASS GIS] #2734: v.distance: 3d point inside area is classified as outside

[GRASS GIS]

#2734: v.distance: 3d point inside area is classified as outside
---+-
  Reporter:  annakrat  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.0.2
 Component:  Vector|Version:  svn-trunk
Resolution:|   Keywords:  v.distance, box
   CPU:  All   |   Platform:  All
---+-

Comment (by wenzeslaus):

 On Wed, Oct 7, 2015 at 4:32 AM, Moritz Lennert wrote at
 [https://lists.osgeo.org/pipermail/grass-user/2015-October/073089.html
 grass-user]:
 > I have the feeling that the second proposed solution, i.e. "introduce a
 2D version of the Vect_point_in_box function which checks x and y only" is
 the better long-run solution.

 Good idea. I could use this, e.g. in
 [source:grass/trunk/vector/v.decimate/main.c?rev=66387#L86 v.decimate]
 where I have now `point_in_region_2d()` and `point_in_region_3d`. I'm
 using `Cell_head` as the region/bbox, but it doesn't contain any info
 whether it is 2D or 3D, if something like `depths=0` (perhaps wrapped in
 `G_is_cell_head_3d()`) would tell if it is 3D, then I could have just
 `point_in_region()`.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.rast.stats disables MASK

[Anna Petrášová]

Hi,

sorry I jumped so late into this discussion, but I think we can just remove
any mask related code in v.rast.stats - it's apparently leftover from
https://trac.osgeo.org/grass/changeset/4/

It used mask in the past, but now it uses r.univar zones instead.

Anna

On Wed, Oct 7, 2015 at 8:47 AM, Newcomb, Doug  wrote:

> +1 Agree.  I've run into this before
>
> Doug
>
> On Wed, Oct 7, 2015 at 1:05 AM, Maris Nartiss  wrote:
>
>> This definitely needs a flag + explanation in documentation.
>>
>> Taking into account philosophy behind GRASS raster processing, I would
>> say - default should be to apply MASK, as MASK affects all raster
>> reading operations (unless stated otherwise or requested by user).
>>
>> Maris.
>>
>>
>> 2015-10-06 19:15 GMT+03:00 Martin Landa :
>> > 2015-10-06 18:13 GMT+02:00 Moritz Lennert > >:
>> >> But this was a bug that you fixed in r66421, or ?
>> >
>> > yes, it was. I was just wondering why the module should ignore the
>> > mask. It was answered. Martin
>> >
>> > --
>> > 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
>>
>
>
>
> --
> Doug Newcomb
> USFWS
> Raleigh, NC
> 919-856-4520 ext. 14 doug_newc...@fws.gov
>
> -
> The opinions I express are my own and are not representative of the
> official policy of the U.S.Fish and Wildlife Service or Dept. of the
> Interior.   Life is too short for undocumented, proprietary data formats.
> As a federal employee, my email may be subject to FOIA request.
>
> ___
> 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] v.rast.stats disables MASK

[Newcomb, Doug]

+1 Agree.  I've run into this before

Doug

On Wed, Oct 7, 2015 at 1:05 AM, Maris Nartiss  wrote:

> This definitely needs a flag + explanation in documentation.
>
> Taking into account philosophy behind GRASS raster processing, I would
> say - default should be to apply MASK, as MASK affects all raster
> reading operations (unless stated otherwise or requested by user).
>
> Maris.
>
>
> 2015-10-06 19:15 GMT+03:00 Martin Landa :
> > 2015-10-06 18:13 GMT+02:00 Moritz Lennert  >:
> >> But this was a bug that you fixed in r66421, or ?
> >
> > yes, it was. I was just wondering why the module should ignore the
> > mask. It was answered. Martin
> >
> > --
> > 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
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
As a federal employee, my email may be subject to FOIA request.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [Qgis-developer] New GRASS plugin: a test drive

[Vaclav Petras]

On Tue, Oct 6, 2015 at 7:29 AM, Radim Blazek  wrote:

> On Mon, Oct 5, 2015 at 11:16 PM, Vaclav Petras 
> wrote:
> >
> > On Mon, Oct 5, 2015 at 1:16 PM, Radim Blazek 
> wrote:
> >>
> >> >> There is v.build.all in modules.
> >> >
> >> > yes, but the user has no hint about its necessity; further steps:
> >> > db.connect -d
> >> > v.db.reconnect.all -cd
> >> > are not available among modules (BTW, maybe these options could be
> added
> >> > to existing modules?).
> >>
> >> Building broken topology from browser can be always useful, but I
> >> don't think that browser/plugin must have UI for upgrading GRASS data
> >> from 6 to 7, something which has to be rarely done and which should be
> >> done with understanding (upgrade from dbf to sqlite).
> >
> > Perhaps a special plugin. Do you think it would be a good idea to have
> > plugins based on the GRASS plugin? (They would probably just call modules
> > but in the way GRASS plugin does.)
>
> I have added qgis.v.upgrade.py which runs
>   v.build.all
>   db.connect -d
>   v.db.reconnect.all -cd
>
> but v.db.reconnect.all fails with -d even from GRASS shell:
>
> Reconnecting vector map  (1 of 3)...
>
> 
> Copying table  to target database...
> Traceback (most recent call last):
>   File "grass-7.1.svn/scripts/db.droptable", line 99, in 
> main()
>   File "grass-7.1.svn/scripts/db.droptable", line 77, in main
> used = grass.db.db_table_in_vector(table)
>   File "grass-7.1.svn/etc/python/grass/script/db.py", line 189, in
> db_table_in_vector
> for f in vector_db(vect, stderr=nuldev).itervalues():
>   File "grass-7.1.svn/etc/python/grass/script/vector.py", line 46, in
> vector_db
> **args)
>   File "/grass-7.1.svn/etc/python/grass/script/core.py", line 460, in
> read_command
> return handle_errors(returncode, stdout, args, kwargs)
>   File "grass-7.1.svn/etc/python/grass/script/core.py", line 328, in
> handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run None ['v.db.connect',
> '--q', '-g', 'map=edit@PERMANENT', 'sep=;'] ended with error
> Process ended with non-zero return code 1. See errors in the (error)
> output.
> ERROR: Unable to drop table 


Hi Radim,

it works for me with NC sample Location for G6 [1]. So, the same as for
Paolo [2]. How can I reproduce it? I've tried vector map without a table,
but it also worked well. Tested with latest 7.0 release branch code.

Vaclav

[1] http://grass.osgeo.org/download/sample-data/
[2] https://lists.osgeo.org/pipermail/grass-dev/2015-October/076648.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66334 - in grass-addons/grass7: . temporal temporal/t.rast.whatcsv temporal/t.rast.whatcsv/testsuite

[Vaclav Petras]

On Fri, Sep 25, 2015 at 11:39 AM,  wrote:
>
> Author: neteler
> New Revision: 66334
>
> Added:
>grass-addons/grass7/temporal/t.rast.whatcsv/t.rast.whatcsv.py
>
> Log:
> t.rast.whatcsv Addon: new prototype module by Soeren Gebbert
>
> +from grass.gunittest.gmodules import SimpleModule
>
> +
> +r_what = SimpleModule("r.what", map="dummy",
> +output="-",
> +separator=separator,
> +quiet=True)
> +

Soeren and Markus,

What is the reason for using SimpleModule from gunittest? In gunittest it
is used to preset defaults which are needed everywhere in the gunittest. If
it is advantageous perhaps we should move it to the same place where
pygrass's Module currently* is. In this case, we need to rethink the
defaults and naming.

Vaclav

* I'm saying currently because it seems that we might move it somewhere
else.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66422 - grass/trunk/vector/v.mkgrid

[Vaclav Petras]

On Tue, Oct 6, 2015 at 10:30 AM,  wrote:
>
> Author: martinl
> New Revision: 66422
>
> v.mkgrid: finish progress (G_percent) info, be less verbose about progress
>
> Modified: grass/trunk/vector/v.mkgrid/main.c
>
> /* Create a grid of label points at the centres of the grid cells
*/
> -   G_verbose_message(_("Creating centroids..."));
> +   G_message(_("Creating centroids..."));

Hi Martin,

isn't G_verbose_message -> G_message making it in fact more verbose and not
"less verbose" as the commit message says or is my logic completely
confused?

Thanks,
Vaclav

https://trac.osgeo.org/grass/changeset/66422
https://trac.osgeo.org/grass/changeset/66423
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66422 - grass/trunk/vector/v.mkgrid

[Martin Landa]

Hi,

2015-10-07 17:10 GMT+02:00 Vaclav Petras :
> isn't G_verbose_message -> G_message making it in fact more verbose and not
> "less verbose" as the commit message says or is my logic completely
> confused?

no your logic is correct. I just wrote "less" and meant "more" ;-) Sorry. 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] GRASS and Mac OS X El Capitan

[Michael Barton]

It is especially good news that GRASS compiles in El Capitan. I cannot use 
HomeBrew for binaries for distributions, but this means that I should be able 
to compile it after upgrading. Nonetheless, I’ll do at least one more binary 
compiled under Yosemite.

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 Oct 7, 2015, at 1:26 AM, Rainer M Krug  wrote:
> 
> Michael Barton  writes:
> 
>> But it was never clear what was and was not working. We have this
>> working fine in Yosemite. So far, you are the only ones to report a
>> problem with Yosemite. The problem we are reporting now is that it was
>> running on Yosemite and not running on El Capitan. Maybe that is the
>> same thing, but maybe not. That said, I plan on a recompile, but have
>> been stuck on the laslib problem. I hope to have time to get that
>> compiled on Thursday. I haven’t had much input so it has been a lot of
>> trial and error. Once it is working with current gdal, I can recompile
>> new binaries.
> 
> Just to add an (unrelated?) datapoint: I installed grass 70 and 71 under
> Yosemite using homebrew and tried just now unde El Capitan, and both
> still run the gui.
> 
> Rainer
> 
> 
>> 
>> 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 Oct 6, 2015, at 2:11 PM, Anna Petrášová 
>> > wrote:
>> 
>> 
>> 
>> On Tue, Oct 6, 2015 at 4:56 PM, Michael Barton 
>> > wrote:
>> This is a binary I created and posted to my web site not too long
>> ago. It worked fine before upgrading and works fine on people’s
>> machines that have not upgraded. So this worries me.
>> 
>> I informed you couple of weeks ago when you posted them that they are
>> not working on my and Helena's Mac with the exact same problem (we
>> have Yosemite). As I said before couple of times and as Markus said
>> now, this error suggests that fresh recompilation could help.
>> 
>> BTW I fixed import order couple of weeks ago, so this shouldn't happen again.
>> 
>> 
>> 
>> I’m hoping soon to have time to complete the complicated effort to
>> recompile laslib so I can make new binaries before I think about
>> upgrading to the new OS X. But I will be compiling them on the
>> penultimate version of the OS (prior to El Capitan, released a few
>> days ago).
>> 
>> We are able to compile GRASS on Mac, although we haven't tried to compile 
>> liblas.
>> 
>> Anna
>> 
>> 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 Oct 6, 2015, at 12:02 PM, Markus Neteler 
>>> > wrote:
>>> 
>>> On Tue, Oct 6, 2015 at 8:56 PM, Michael Barton 
>>> > wrote:
 A couple of my students upgraded to the new Mac OS, El Capitan, and can no
 longer run GRASS.
 
 We tried a work around that disabled one of the new security settings. This
 got the launch process further, but it still bombed. Has anyone had any 
 luck
 with this yet?
 
 Here is the error:
 
 Launching  GUI in the background, please wait...
 
 GRASS 7.0.1 (MedLambertA):~ > Traceback (most recent call last):
>>> ...
 File
 "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py",
 line 30, in 
   from iclass.digit   import IClassVDigit
 
 File
 "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py",
 line 23, in 
   from vdigit.wxdisplay import DisplayDriver, TYPE_AREA
 
 ImportError: cannot import name TYPE_AREA
>>> 
>>> There is a (closed) 

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

[Maris Nartiss]

Second error indicates on a misconfigured system.
Add to ~/.bash_profile:
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

https://coderwall.com/p/-k_93g/mac-os-x-valueerror-unknown-locale-utf-8-in-python


2015-10-07 11:49 GMT+03:00 Agustin Diez Castillo :
> After updating,
> wxpython not working here but tcltk still works (grass 6.4 from kyngchaos),
> see below for results with 7.1
> Launching 'wxpython' GUI in the background, please wait ...
> Traceback (most recent call last):
>   File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py",
> line 27, in 
> from core import globalvar
>   File
> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py",
> line 76, in 
> import wx
>   File
> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py", line
> 45, in 
> from wx._core import *
>   File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
> line 4, in 
> import _core_
> ImportError:
> dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
> 2): Library not loaded:
> /Users/Shared/unix/wxpython-snow/lib/libwx_macud-2.8.0.dylib
>   Referenced from:
> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>   Reason: image not found
>
> grass 7.1 not working here
>  '/Applications/GRASS/GRASS-7.1.app/Contents/MacOS/grass.sh'; exit
> Rebuilding Addon HTML manual pages index...
> Rebuilding Addon menu...
> Python 2.7.10 found.
> Traceback (most recent call last):
>   File "/Applications/GRASS/GRASS-7.1.app/Contents/MacOS/grass71", line
> 1380, in 
> set_language()
>   File "/Applications/GRASS/GRASS-7.1.app/Contents/MacOS/grass71", line 821,
> in set_language
> language, encoding = locale.getdefaultlocale()
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
> line 543, in getdefaultlocale
> return _parse_localename(localename)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
> line 475, in _parse_localename
> raise ValueError, 'unknown locale: %s' % localename
> ValueError: unknown locale: UTF-8
> logout
> Saving session...
> ...copying shared history...
> ...saving history...truncating history files...
> ...completed.
>
> El Oct 7, 2015, a las 01:15, Michael Barton 
> escribió:
>
> But it was never clear what was and was not working. We have this working
> fine in Yosemite. So far, you are the only ones to report a problem with
> Yosemite. The problem we are reporting now is that it was running on
> Yosemite and not running on El Capitan. Maybe that is the same thing, but
> maybe not. That said, I plan on a recompile, but have been stuck on the
> laslib problem. I hope to have time to get that compiled on Thursday. I
> haven’t had much input so it has been a lot of trial and error. Once it is
> working with current gdal, I can recompile new binaries.
>
> 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 Oct 6, 2015, at 2:11 PM, Anna Petrášová  wrote:
>
>
>
> On Tue, Oct 6, 2015 at 4:56 PM, Michael Barton 
> wrote:
>>
>> This is a binary I created and posted to my web site not too long ago. It
>> worked fine before upgrading and works fine on people’s machines that have
>> not upgraded. So this worries me.
>
>
> I informed you couple of weeks ago when you posted them that they are not
> working on my and Helena's Mac with the exact same problem (we have
> Yosemite). As I said before couple of times and as Markus said now, this
> error suggests that fresh recompilation could help.
>
> BTW I fixed import order couple of weeks ago, so this shouldn't happen
> again.
>
>
>>
>> I’m hoping soon to have time to complete the complicated effort to
>> recompile laslib so I can make new binaries before I think about upgrading
>> to the new OS X. But I will be compiling them on the penultimate version of
>> the OS (prior to El Capitan, released a few days ago).
>
>
>  We are able to compile GRASS on Mac, although we haven't tried to compile
> liblas.
>
> Anna
>>
>>
>> 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, 

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

[Markus Neteler]

On Wed, Oct 7, 2015 at 8:17 PM, Maris Nartiss  wrote:
> Second error indicates on a misconfigured system.
> Add to ~/.bash_profile:
> export LC_ALL=en_US.UTF-8
> export LANG=en_US.UTF-8
>
> https://coderwall.com/p/-k_93g/mac-os-x-valueerror-unknown-locale-utf-8-in-python

It is also here:

https://grasswiki.osgeo.org/wiki/MacOSX_GRASS_errors#Starting_GRASS_GIS_on_MacOSX.2C_I_get_.22ERROR:_unknown_locale:_UTF-8.22

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

[GRASS-dev] Fwd: [OSGeo-Discuss] [Notice] Email List Maintenance

[Markus Neteler]

FYI


-- Forwarded message --
From: Alex M 
Date: Wed, Oct 7, 2015 at 6:32 PM
Subject: [OSGeo-Discuss] [Notice] Email List Maintenance
To: "disc...@lists.osgeo.org" 


All of OSGeo email lists and aliases, will be migrated
to the new "osgeo6" machine on Thursday evening UTC (~
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2015=10=8=18=0=0=224=179).
 Expected downtime
required for syncing everything over plus testing will be 1 to 2
hours.


Thanks,
Alex
OSGeo System Administration Committee
___
Discuss mailing list
disc...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66334 - in grass-addons/grass7: . temporal temporal/t.rast.whatcsv temporal/t.rast.whatcsv/testsuite

[Sören Gebbert]

Hi,

2015-10-07 17:25 GMT+02:00 Vaclav Petras :
>
> On Fri, Sep 25, 2015 at 11:39 AM,  wrote:
>>
>> Author: neteler
>> New Revision: 66334
>>
>> Added:
>>grass-addons/grass7/temporal/t.rast.whatcsv/t.rast.whatcsv.py
>>
>> Log:
>> t.rast.whatcsv Addon: new prototype module by Soeren Gebbert
>>
>> +from grass.gunittest.gmodules import SimpleModule
>>
>> +
>> +r_what = SimpleModule("r.what", map="dummy",
>> +output="-",
>> +separator=separator,
>> +quiet=True)
>> +
>
> Soeren and Markus,
>
> What is the reason for using SimpleModule from gunittest? In gunittest it is
> used to preset defaults which are needed everywhere in the gunittest. If it
> is advantageous perhaps we should move it to the same place where pygrass's
> Module currently* is. In this case, we need to rethink the defaults and
> naming.

The reason was:
t.rast.whatcsv was a fast hack and i did not take the time to
configure pygrass.modules.Module to do the same as SimpleModule does.
So laziness was the reason.

I think moving SimpleModule to pygrass.modules is a good idea, but
with a better name. Unfortunately i have no better name in mind for
SimpleModule ... .

Best regards
Soeren

>
> Vaclav
>
> * I'm saying currently because it seems that we might move it somewhere
> else.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66334 - in grass-addons/grass7: . temporal temporal/t.rast.whatcsv temporal/t.rast.whatcsv/testsuite

[Vaclav Petras]

On Wed, Oct 7, 2015 at 1:05 PM, Sören Gebbert 
wrote:
>
> > What is the reason for using SimpleModule from gunittest? In gunittest
it is
> > used to preset defaults which are needed everywhere in the gunittest.
If it
> > is advantageous perhaps we should move it to the same place where
pygrass's
> > Module currently* is. In this case, we need to rethink the defaults and
> > naming.
>
> The reason was:
> t.rast.whatcsv was a fast hack and i did not take the time to
> configure pygrass.modules.Module to do the same as SimpleModule does.
> So laziness was the reason.
>
> I think moving SimpleModule to pygrass.modules is a good idea, but
> with a better name. Unfortunately i have no better name in mind for
> SimpleModule ... .

Thanks for the answer Soeren. This is reasonable. I was not yet able to
come up with better name either. Even bigger challenge is name and place
for the new package/module which would separate/take out pygrass Module
from the ctypes-based part of pygrass package. But that's another story.
For now we just need to figure out the SimpleModule rename and whether the
parameters needs to be adjusted and what are the suggested usages. Low
priority, but should be solved before 7.1.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev