Re: [GRASS-dev] [GRASS GIS] #947: g.version: new flag for citation info

2016-09-07 Thread GRASS GIS 
#947: g.version: new flag for citation info
--+-
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  major|  Milestone:  7.2.0
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:  g.version, citation
   CPU:  All  |   Platform:  All
--+-

Comment (by wenzeslaus):

 7.0.5 RC1 tested on MS Windows but I can't find binaries for 7.2 and 7.3
 which should be tested because of the GUI changes.

--
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] #3033: Cairo and PS drivers display only one raster or vector for SVG and PS

2016-09-07 Thread GRASS GIS 
#3033: Cairo and PS drivers display only one raster or vector for SVG and PS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.4.0
 Component:  Display |Version:  svn-trunk
Resolution:  |   Keywords:  d.mon, cairo, ps, SVG, vector
   CPU:  |  graphics
  Unspecified|   Platform:  Unspecified
-+-
Changes (by wenzeslaus):

 * milestone:  7.2.0 => 7.4.0


--
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] #3027: i.atcorr's create_iwave.py broken

2016-09-07 Thread GRASS GIS 
#3027: i.atcorr's create_iwave.py broken
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Imagery  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  i.atcorr
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by nikosa):

 We need another tester to nail this one down. It works for *all* sensors
 here. Below testing for QB2 and L8:

 {{{

 → rm create_iwave.py
 rm: remove regular file ‘create_iwave.py’? y

 → svn up
 Updating '.':
 Restored 'create_iwave.py'
 At revision 69402.

 → patch -p0 -i create_iwave_patch.diff
 patching file create_iwave.py

 → python create_iwave.py sensors_csv/quickbird2.csv

  > Getting sensor name from csv file: quickbird2
  > Number of bands found: 5
  > Filter functions exported to quickbird2_cpp_template.txt
  > Please check file for possible errors before inserting into IWave.cpp
  > Don't forget to add the necessary data to IWave.h

 → python create_iwave.py sensors_csv/landsat_8.csv

  > Getting sensor name from csv file: landsat_8
  > Number of bands found: 9
  > Filter functions exported to landsat_8_cpp_template.txt
  > Please check file for possible errors before inserting into IWave.cpp
  > Don't forget to add the necessary data to IWave.h
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Uploading files in trac

2016-09-07 Thread Nikos Alexandris 

* Markus Neteler  [2016-09-07 22:45:58 +0200]:


On Wed, Sep 7, 2016 at 8:26 PM, Nikos Alexandris
 wrote:

This is about trac and uploading attachements. I don't want to cause
another chain of e-mails, so, the question is: can't we really delete
old attachments from trac?

See: http://www.gossamer-threads.com/lists/trac/users/48349  and
https://trac.edgewall.org/ticket/765 for examples.


You can (I believe) replace an existing attachment with a new one when
keeping the name.

The admins (Martin, me, ...) can also delete attachments.


The last attached is actually a replacement (already).  Please, for the
sake of simplicity, delete the older attachement (... hmmm, ok already
deleted :-) ).

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

Re: [GRASS-dev] Fwd: MySQL support removed from GDAL & GRASS

2016-09-07 Thread Sebastiaan Couwenberg 
On 09/07/2016 11:31 PM, Martin Landa wrote:
> 2016-09-07 23:26 GMT+02:00 Markus Neteler :
>> The subject line is rather misleading: we are speaking only about Debian
>> packaging here, right?
> 
> yes, just Debian packaging. Ma

And since most GRASS users use the amd64 & i386 architectures, their
custom builds can still enable the MySQL support.

Reinstating the MySQL support in the gdal & grass packages after the
MariaDB packages have been fixed depends on user demand. If no users
speak up about their need for MySQL support, it won't be re-enabled.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: MySQL support removed from GDAL & GRASS

2016-09-07 Thread Martin Landa 
2016-09-07 23:26 GMT+02:00 Markus Neteler :
> The subject line is rather misleading: we are speaking only about Debian
> packaging here, right?

yes, just Debian packaging. 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 GIS] #3027: i.atcorr's create_iwave.py broken

2016-09-07 Thread GRASS GIS 
#3027: i.atcorr's create_iwave.py broken
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Imagery  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  i.atcorr
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by neteler):

 Using the latest patch I still get this error

 {{{
 python create_iwave.py sensors_csv/quickbird2.csv
  > Getting sensor name from csv file: quickbird2
  > Number of bands found: 5
 Traceback (most recent call last):
   File "create_iwave.py", line 281, in 
 main()
   File "create_iwave.py", line 267, in main
 write_cpp(bands, values, sensor, os.path.dirname(inputfile))
   File "create_iwave.py", line 185, in write_cpp
 fi, li = interpolate_band(values[:,[0,b+1]])
   File "create_iwave.py", line 119, in interpolate_band
 filter_f = f(np.arange(start, stop, step))
   File "/usr/lib64/python2.7/site-packages/scipy/interpolate/polyint.py",
 line 79, in __call__
 y = self._evaluate(x)
   File "/usr/lib64/python2.7/site-
 packages/scipy/interpolate/interpolate.py", line 497, in _evaluate
 out_of_bounds = self._check_bounds(x_new)
   File "/usr/lib64/python2.7/site-
 packages/scipy/interpolate/interpolate.py", line 527, in _check_bounds
 raise ValueError("A value in x_new is above the interpolation "
 ValueError: A value in x_new is above the interpolation range.
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Fwd: MySQL support removed from GDAL & GRASS

2016-09-07 Thread Markus Neteler 

On 09/07/2016 11:21 PM, Martin Landa wrote:

-- Forwarded message --
From: Sebastiaan Couwenberg 
Date: 2016-09-07 23:13 GMT+02:00
Subject: Re: MySQL support removed from GDAL & GRASS
To: debian-...@lists.debian.org


On 09/07/2016 10:58 PM, Martin Landa wrote:

2016-09-07 22:33 GMT+02:00 Sebastiaan Couwenberg :

Thanks to the lovely mess created by the MySQL/MariaDB maintainers,
MySQL support has been removed from GDAL & GRASS.

thanks for info. BTW, can you post details about broken mysql
packages? Thanks, Ma

The MySQL packages aren't broken, but MariaDB is not available on
mips64el which has become a release architecture for stretch.


The subject line is rather misleading: we are speaking only about Debian 
packaging here, right?

GRASS GIS has not been touched at all!

Just to avoid FUD.

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

[GRASS-dev] Fwd: MySQL support removed from GDAL & GRASS

2016-09-07 Thread Martin Landa 
FYI


-- Forwarded message --
From: Sebastiaan Couwenberg 
Date: 2016-09-07 23:13 GMT+02:00
Subject: Re: MySQL support removed from GDAL & GRASS
To: debian-...@lists.debian.org


On 09/07/2016 10:58 PM, Martin Landa wrote:
> 2016-09-07 22:33 GMT+02:00 Sebastiaan Couwenberg :
>> Thanks to the lovely mess created by the MySQL/MariaDB maintainers,
>> MySQL support has been removed from GDAL & GRASS.
>
> thanks for info. BTW, can you post details about broken mysql
> packages? Thanks, Ma

The MySQL packages aren't broken, but MariaDB is not available on
mips64el which has become a release architecture for stretch.

To support the transition from MySQL to MariaDB, new packages have been
introduced to select the default variant, see the recent announcement by
the MySQL/MariaDB maintainers:

 https://lists.debian.org/debian-devel-announce/2016/09/msg0.html

The gdal & grass packages used to depend on libmysqlclient-dev to build
the MySQL support, but these needed to be switched to
default-libmysqlclient-dev to fix the Release Critical bug in gdal:

 https://bugs.debian.org/836962

When default-libmysqlclient-dev is installed, it pulls in the
libmariadbclient-dev-compat package which conflicts with
libmysqlclient-dev ensuring it cannot be installed at the same time.

Because the MariaDB packages failed to build on mips64el, gdal and all
its reverse dependencies need to be removed from that architecture to
not block transition to testing due to the missing binary packages on
that release architecture. This is too much work to be worth the effort,
which made me decide to remove the MySQL support instead.

As said in my initial message in this thread, if there is sufficient
user demand for MySQL/MariaDB support in GDAL & GRASS I may be persuaded
to reinstate it after the MySQL/MariaDB maintainers have fixed their
packages on all release architectures.

I personally don't need MySQL support as I'm using PostgreSQL for all my
database needs, so I'm perfectly happy leaving out the MySQL support.
But I don't maintain the GIS packages only for my personal needs (I
wouldn't maintain so many packages if I did). In Debian the interest of
our users carry great weight as enshrined in our Social Contract after all.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



-- 
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] Uploading files in trac

2016-09-07 Thread Markus Neteler 
On Wed, Sep 7, 2016 at 8:26 PM, Nikos Alexandris
 wrote:
> This is about trac and uploading attachements. I don't want to cause
> another chain of e-mails, so, the question is: can't we really delete
> old attachments from trac?
>
> See: http://www.gossamer-threads.com/lists/trac/users/48349  and
> https://trac.edgewall.org/ticket/765 for examples.

You can (I believe) replace an existing attachment with a new one when
keeping the name.

The admins (Martin, me, ...) can also delete attachments.

HTH
Markus

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



-- 
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2902: i.segment.hierarchical: Execution of subprocesses was not successful

2016-09-07 Thread Moritz Lennert 

On 07/09/16 12:07, Markus Neteler wrote:

On Wed, Sep 7, 2016 at 11:36 AM, GRASS GIS > wrote:

#2902: i.segment.hierarchical: Execution of subprocesses was not

successful
...

 Setting this to True led me to a
 bug in pygrass which still had a call to type='rast' instead of
 type='raster'. Corrected in trunk in r69392.


There appear to be some more to be fixed but I cannot say which ones
are false positives in this sloppy grep search (sorry for the HTML
formatting to preserve line breaks):

find . -type f | xargs grep "'rast'" | grep -v svn/pristine
./scripts/r.shade/r.shade.py :
type='rast', name=maps)
./scripts/r.grow/r.grow.py
:  type='rast', name=map)
./gui/wxpython/psmap/dialogs.py:{'rast': self.currRaster,
'type': rasterType})
./gui/wxpython/psmap/dialogs.py:{'rast': currRaster, 'type':
str(rasterType)})
./gui/wxpython/lmgr/layertree.py:module = 'rast'
./lib/python/gunittest/gutils.py:if type == 'rast' or  type == 'raster':
./lib/python/pygrass/raster/abstract.py:utils.remove(self.name
, 'rast')
./lib/python/pygrass/raster/abstract.py:
utils.rename(self.name , newname, 'rast')
./lib/python/pygrass/modules/grid/grid.py: for r in
findmaps('rast', location=dst[1], gisdbase=dst[2])]
./lib/python/pygrass/modules/interface/testsuite/test_parameter.py:
param = Parameter(diz=dict(name='rast', required='yes',
./lib/python/pygrass/modules/interface/testsuite/test_parameter.py:
param = Parameter(diz=dict(name='rast', required='yes',
./lib/python/temporal/temporal_algebra.py:  maptype='rast',
mapclass=RasterDataset,
./lib/python/script/core.py:if element == 'raster' or element == 'rast':


find . -type f | xargs grep "'vect'" | grep -v svn/pristine
./scripts/v.db.reconnect.all/v.db.reconnect.all.py
:vectors =
gscript.list_grouped('vect')[mapset]
./scripts/v.build.all/v.build.all.py :vectors
= grass.list_grouped('vect')[mapset]
./gui/wxpython/lmgr/layertree.py:module = 'vect'
./lib/python/gunittest/gutils.py:elif type == 'vect':
./lib/python/pygrass/utils.py:>>> remove('test_vect_2','vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus', 'vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus', 'vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus', 'vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus','vect')
./lib/python/pygrass/vector/abstract.py:
utils.rename(self.name , newname, 'vect')
./lib/python/pygrass/vector/abstract.py:utils.remove(self.name
, 'vect')
./lib/python/pygrass/vector/__init__.py:>>>
copy(test_vector_name,'mytest_vect','vect')
./lib/python/pygrass/vector/__init__.py:>>>
remove('mytest_vect', 'vect')
./lib/python/script/core.py:>>> list_grouped('vect',
pattern='*roads*')['PERMANENT']
./lib/python/script/db.py:vects = list_strings('vect')


... anyone willing to go through and fix the few true Python issues?

Those should then also be backported to 7.2.svn.


I'd rather have some of the real pygrass and script library experts look 
at this, but AFAICS, none of these (except for grid.py call to findmaps 
(but which I already fixed in trunk) actually cause any trouble. I think 
it was the specfic findmaps function call that uses a ctypes call that 
caused the issue.


But maybe someone else could confirm or infirm this ?

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

Re: [GRASS-dev] grass 7.2 planning

2016-09-07 Thread Martin Landa 
Hi,

2016-07-01 0:42 GMT+02:00 Martin Landa :
> * soft freeze: ~ 15 July
> * hard freeze + RC1: ~ 15 August
> * bug squashing: FOSS4G Bonn
> * RC2: ~ 30 August
> * final: ~ 7 September

since 7.0.5 is still not out (should happen soon) I would suggest to
postpone also milestone for G72 - hardfreezing + RC1 ~ 25/9. Feel free
to update blockers [1] (currently no tickets marked as blockers and
critical). Thanks, Ma

[1] 
https://trac.osgeo.org/grass/query?priority=blocker=critical=assigned=new=reopened=7.2.0=type=priority

-- 
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] temporally aggregate a vector time series

2016-09-07 Thread Sören Gebbert 
Hi,
unfortunately, there is no vector aggregation available at the attribute
level. However you can transform your time series of vector point data into
coarse raster data time series, aggregate it and sample the result with the
point coordinates (t.vect.observe.strds). Make sure that vector points
belong to single pixels, hence one point per pixel.

Best regards
Soeren

2016-09-07 14:59 GMT+02:00 Veronica Andreo :
>
> Hello devs
>
> I'm wondering whether it is possible to aggregate space time vector data
sets (STVDS).
>
> I have a daily time series of vector maps (points) and I would like to
aggregate it weekly. Is that possible somehow with t.vect.algebra? I
blindly assumed there was something like t.rast.aggregate for vectors too,
but there's no... I think maybe it is possible with t.vect.algebra given
that the operation would be equivalent to v.overlay operator=or, but as
with t.rast.algebra, those manual pages are just a mistery to my limited
understanding... Can anyone give any hints? or hall I discard vector time
series approach completely?
>
> Thanks a lot in advance!
>
> Best,
> Vero
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3136: move v.krige to addons

2016-09-07 Thread GRASS GIS 
#3136: move v.krige to addons
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  closed
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Addons   |Version:  unspecified
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

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


Comment:

 `v.krige` and its GUI (`vkrige.py`) has been removed from trunk and
 relbr72. The module `v.krige` is now part of addons. Since removal from
 relbr70 is not planned, I am taking liberty to close this ticket. And,
 yes, would be nice to have native implementation in G74, probably based on
 `v.kriging`...

--
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] #3136: move v.krige to addons

2016-09-07 Thread GRASS GIS 
#3136: move v.krige to addons
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 In [changeset:"69399" 69399]:
 {{{
 #!CommitTicketReference repository="" revision="69399"
 v.krige moved to addons (see #3136 for details)
 }}}

--
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] #3136: move v.krige to addons

2016-09-07 Thread GRASS GIS 
#3136: move v.krige to addons
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 In [changeset:"69398" 69398]:
 {{{
 #!CommitTicketReference repository="" revision="69398"
 v.krige removed from core distribution (see #3136 for details)
 }}}

--
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] #3136: move v.krige to addons

2016-09-07 Thread GRASS GIS 
#3136: move v.krige to addons
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 In [changeset:"69397" 69397]:
 {{{
 #!CommitTicketReference repository="" revision="69397"
 v.krige remove from core distribution (see #3136 for details)
 }}}

--
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] #3135: Pressing Run button in GUI dialogs open a new dialog

2016-09-07 Thread GRASS GIS 
#3135: Pressing Run button in GUI dialogs open a new dialog
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  critical |  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-trunk
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

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


Comment:

 In [changeset:"69396" 69396]:
 {{{
 #!CommitTicketReference repository="" revision="69396"
 Pressing Run button in GUI dialogs open a new dialog (fixes #3135)
 }}}

--
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] #3135: Pressing Run button in GUI dialogs open a new dialog

2016-09-07 Thread GRASS GIS 
#3135: Pressing Run button in GUI dialogs open a new dialog
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 In [changeset:"69395" 69395]:
 {{{
 #!CommitTicketReference repository="" revision="69395"
 Pressing Run button in GUI dialogs open a new dialog (see #3135)
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Uploading files in trac

2016-09-07 Thread Nikos Alexandris 

This is about trac and uploading attachements. I don't want to cause
another chain of e-mails, so, the question is: can't we really delete
old attachments from trac?

See: http://www.gossamer-threads.com/lists/trac/users/48349  and
https://trac.edgewall.org/ticket/765 for examples.

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

[GRASS-dev] temporally aggregate a vector time series

2016-09-07 Thread Veronica Andreo 
Hello devs

I'm wondering whether it is possible to aggregate space time vector data
sets (STVDS).

I have a daily time series of vector maps (points) and I would like to
aggregate it weekly. Is that possible somehow with t.vect.algebra? I
blindly assumed there was something like t.rast.aggregate for vectors too,
but there's no... I think maybe it is possible with t.vect.algebra given
that the operation would be equivalent to *v.overlay operator=or, *but as
with t.rast.algebra, those manual pages are just a mistery to my limited
understanding... Can anyone give any hints? or hall I discard vector time
series approach completely?

Thanks a lot in advance!

Best,
Vero
___
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

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

Comment (by neteler):

 For the record - concerning NULL file compression:

 At time `cell_misc/null` is uncompressed by default.

 Using the environment variable `GRASS_COMPRESS_NULLS=1` NULL compression
 is activated for the session for newly created raster maps; and

 {{{
 export GRASS_COMPRESS_NULLS=1
 r.null -z raster_map
 }}}

 generates a new compressed file `cell_misc/nullcmpr` and removes the old
 uncompressed `cell_misc/null` file for existing maps.

 Note: At least GRASS GIS 7.2 is needed to read a raster map with
 compressed null file.

--
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] #2902: i.segment.hierarchical: Execution of subprocesses was not successful

2016-09-07 Thread Markus Neteler 
On Wed, Sep 7, 2016 at 11:36 AM, GRASS GIS  wrote:
> #2902: i.segment.hierarchical: Execution of subprocesses was not
successful
...
>  Setting this to True led me to a
>  bug in pygrass which still had a call to type='rast' instead of
>  type='raster'. Corrected in trunk in r69392.

There appear to be some more to be fixed but I cannot say which ones
are false positives in this sloppy grep search (sorry for the HTML
formatting to preserve line breaks):

find . -type f | xargs grep "'rast'" | grep -v svn/pristine
./scripts/r.shade/r.shade.py:  type='rast', name=maps)
./scripts/r.grow/r.grow.py:  type='rast',
name=map)
./gui/wxpython/psmap/dialogs.py:{'rast': self.currRaster,
'type': rasterType})
./gui/wxpython/psmap/dialogs.py:{'rast': currRaster, 'type':
str(rasterType)})
./gui/wxpython/lmgr/layertree.py:module = 'rast'
./lib/python/gunittest/gutils.py:if type == 'rast' or  type == 'raster':
./lib/python/pygrass/raster/abstract.py:utils.remove(self.name,
'rast')
./lib/python/pygrass/raster/abstract.py:utils.rename(self.name,
newname, 'rast')
./lib/python/pygrass/modules/grid/grid.py: for r in
findmaps('rast', location=dst[1], gisdbase=dst[2])]
./lib/python/pygrass/modules/interface/testsuite/test_parameter.py:
param = Parameter(diz=dict(name='rast', required='yes',
./lib/python/pygrass/modules/interface/testsuite/test_parameter.py:
param = Parameter(diz=dict(name='rast', required='yes',
./lib/python/temporal/temporal_algebra.py:  maptype='rast',
mapclass=RasterDataset,
./lib/python/script/core.py:if element == 'raster' or element == 'rast':


find . -type f | xargs grep "'vect'" | grep -v svn/pristine
./scripts/v.db.reconnect.all/v.db.reconnect.all.py:vectors =
gscript.list_grouped('vect')[mapset]
./scripts/v.build.all/v.build.all.py:vectors =
grass.list_grouped('vect')[mapset]
./gui/wxpython/lmgr/layertree.py:module = 'vect'
./lib/python/gunittest/gutils.py:elif type == 'vect':
./lib/python/pygrass/utils.py:>>> remove('test_vect_2','vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus', 'vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus', 'vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus', 'vect')
./lib/python/pygrass/vector/table.py:>>>
copy(test_vector_name,'mycensus','vect')
./lib/python/pygrass/vector/table.py:>>> remove('mycensus','vect')
./lib/python/pygrass/vector/abstract.py:utils.rename(
self.name, newname, 'vect')
./lib/python/pygrass/vector/abstract.py:utils.remove(self.name,
'vect')
./lib/python/pygrass/vector/__init__.py:>>>
copy(test_vector_name,'mytest_vect','vect')
./lib/python/pygrass/vector/__init__.py:>>> remove('mytest_vect',
'vect')
./lib/python/script/core.py:>>> list_grouped('vect',
pattern='*roads*')['PERMANENT']
./lib/python/script/db.py:vects = list_strings('vect')


... anyone willing to go through and fix the few true Python issues?

Those should then also be backported to 7.2.svn.

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

Re: [GRASS-dev] [GRASS GIS] #2902: i.segment.hierarchical: Execution of subprocesses was not successful

2016-09-07 Thread GRASS GIS 
#2902: i.segment.hierarchical: Execution of subprocesses was not successful
-+-
  Reporter:  mlennert|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.5
 Component:  Addons  |Version:  svn-trunk
Resolution:  |   Keywords:  i.segment.hierarchical GridModule
   CPU:  |  subprocesses
  Unspecified|   Platform:  Unspecified
-+-

Comment (by mlennert):

 Replying to [comment:3 annakrat]:
 > I remember GridModule had a debug parameter, which switched off the
 parallelization, so you start there.

 Yes ! And Pietro actually put a nice big DEBUG=False at the beginning of
 the code. Blind me just didn't see it. Setting this to True led me to a
 bug in pygrass which still had a call to type='rast' instead of
 type='raster'. Corrected in trunk in r69392. But I get new errors so I'll
 work on that before I backport to the other grass7 branches.

 Thanks for the pointer !

 Moritz

--
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] #3057: Problems with Numpy and matplotlib after updating through OSGeo4W

2016-09-07 Thread GRASS GIS 
#3057: Problems with Numpy and matplotlib after updating through OSGeo4W
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by hellik):

 Replying to [comment:7 veroandreo]:
 > Tested again in a brand new 64-bit Windows 10 laptop.
 >
 > Same issue, both in grass73 (r69169) and 7.0.4 installed with 64-bit
 osgeo4w installer.
 > However, no such problem in wingrass73 standalone installer.

 tested again with OSGeo4W-winGRASS; still an issue.

 outside grass session

 {{{
 C:\>python -c "import sys; print(sys.path)"
 ['', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\matplotlib-1.3.1-py2.7-win-amd64.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\nose-1.3.3-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\tornado-4.0.1-py2.7
 -win-amd64.egg', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\backports.ssl_match_hostname-3.4.0.2-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\certifi-14.05.14-py2.7.egg', 'c:\\osgeo4~1\\apps\\python27\\lib
 \\site-packages\\python_dateutil-2.1-py2.7.egg',
 'C:\\OSGEO4~1\\bin\\python27.zip', 'C:\\OSGEO4~1\\apps\\Python27\\DLLs',
 'C:\\OSGEO4~1\\apps\\Python27\\lib', 'C:\\OSGEO4~1\\apps\\Python27\\lib
 \\plat-win', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\lib-tk',
 'C:\\OSGEO4~1\\bin', 'C:\\OSGEO4~1\\apps\\Python27',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\PIL',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\jinja2-2.7.2-py2.7.egg', 'C:\\OSGEO4~1\\apps\\Python27\\lib
 \\site-packages\\markupsafe-0.23-py2.7-win-amd64.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\pytz-2012j-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\win32',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\win32\\lib',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\Pythonwin',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\Shapely-1.2.18-py2.7
 -win-amd64.egg', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\wx-2.8
 -msw-unicode']
 }}}

 {{{
 C:\>python -c "import numpy"
 }}}

 no problem.

 now tested within a OSGeo4W-winGRASS session:

 {{{
 C:\>echo %GRASS_PYTHON%
 C:\OSGEO4~1\bin\python.exe
 }}}

 {{{
 C:\>python -c "import sys; print(sys.path)"
 ['', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\matplotlib-1.3.1-py2.7-win-amd64.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\nose-1.3.3-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\tornado-4.0.1-py2.7
 -win-amd64.egg', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\backports.ssl_match_hostname-3.4.0.2-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\certifi-14.05.14-py2.7.egg', 'c:\\osgeo4~1\\apps\\python27\\lib
 \\site-packages\\python_dateutil-2.1-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\grass\\grass-7.3.svn\\etc\\python',
 'C:\\OSGEO4~1\\bin\\python27.zip', 'C:\\OSGEO4~1\\apps\\Python27\\DLLs',
 'C:\\OSGEO4~1\\apps\\Python27\\lib', 'C:\\OSGEO4~1\\apps\\Python27\\lib
 \\plat-win', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\lib-tk',
 'C:\\OSGEO4~1\\bin', 'C:\\OSGEO4~1\\apps\\Python27',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\PIL',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-
 packages\\jinja2-2.7.2-py2.7.egg', 'C:\\OSGEO4~1\\apps\\Python27\\lib
 \\site-packages\\markupsafe-0.23-py2.7-win-amd64.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\pytz-2012j-py2.7.egg',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\win32',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\win32\\lib',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\Pythonwin',
 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\Shapely-1.2.18-py2.7
 -win-amd64.egg', 'C:\\OSGEO4~1\\apps\\Python27\\lib\\site-packages\\wx-2.8
 -msw-unicode']
 }}}

 {{{
 C:\>python -c "import numpy"
 }}}

 it seems it's the same python used.

 any idea?

--
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] #3027: i.atcorr's create_iwave.py broken

2016-09-07 Thread GRASS GIS 
#3027: i.atcorr's create_iwave.py broken
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Imagery  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  i.atcorr
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by neteler):

 Sorry, I'm lost with the attachments. Yesterday I already fixed PRISM*.csv
 in r69384 (backports: r69385, r69386).

 Please *replace* patches if a new version is attached rather than
 accumulating them.

 > Attached a new diff (replaced the 1st patch, please see timeline)

 ... it is unclear to me what to pick now.

--
Ticket URL: 
GRASS GIS 

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