Re: [GRASS-dev] Parsing output of r.category which includes labels

[Stefan Blumentrath]

Dear Nikos,

Can you give us a bit more context?
What is it you want to achieve? How are you using r.stats and what is it you 
want to do with the output?

Personally, I am not too familiar with performance implications of NumPy vs. 
plain Python, but rather use NumPy for convenience in matrix/table operations 
(avoiding pandas)...

Cheers
Stefan

-Original Message-
From: Nikos Alexandris  
Sent: onsdag 22. august 2018 17:57
To: Stefan Blumentrath 
Cc: GRASS-GIS development mailing list 
Subject: Re: [GRASS-dev] Parsing output of r.category which includes labels

Stefan,

a somewhat irrelevant question to the original subject:

do you think the NumPy way is worth to collage a series of `r.stats` outputs?

Imagine administrative boundaries and one `r.stats` call for each. They may be 
tenths, or hundreds, or thousands as the script is meant to cover European wide 
extents.

Or should I just work this out using native Python?

Thank you for any thoughts,
Nikos

* Stefan Blumentrath  [2018-08-20 10:48:34 +]:

>Hi Nikos,
>
>You could use numpy and genfromtxt() to parse the output string...
>genfromtxt() requires an StringIO object (or file) and StringIO (from io) 
>requires unicode()...
>
>So you could do:
>
>from io import StringIO
>import numpy as np
>output = 
>np.genfromtxt(StringIO(unicode(grass.read_command('r.category', 
>map=base))) , delimiter='\t', dtype=None, names=['cat', 'label'])
>
>That causes however some overhead [1]. So if it makes sense depends on what 
>you want to do with the data in the further processing chain...
>
>Cheers
>Stefan
>
>1: https://docs.scipy.org/doc/numpy/user/basics.io.genfromtxt.html

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

Re: [GRASS-dev] On post-processing a raster map's mapcalc related history string

[Nikos Alexandris]

* Nikos Alexandris  [2018-08-21 12:55:49 +0200]:


* Moritz Lennert  [2018-08-21 09:53:21 +0200]:


On 21/08/18 01:50, Nikos Alexandris wrote:

* Nikos Alexandris  [2018-08-20 20:11:57 +0200]:

2) Look back some time, r.cross has had problems with zeroes and NULLs.


At least this one is True!, see also:

https://trac.osgeo.org/grass/ticket/3080
https://lists.osgeo.org/pipermail/grass-dev/2017-September/086090.html
and this thread, finally:
https://lists.osgeo.org/pipermail/grass-user/2018-February/077931.html



But this seems to have been solved, now, or ?


Right, need to revisit this part of the script.


There might be a problem in using `r.cross` in scripting:

"reclass(ifi)ed" maps that derive out of a "cross" map
(in which case, the "cross" is the "base" map)
have to be removed first. This will cost an extra `g.copy`
of the `reclassed` map.

I.e., last step of the following will fail:
```
a x b = crossmap
r.stats.zonal -r in=crossmap out=reclassed
g.remove raster name=crossmap
```

The `crossmap` serves only as an intermediate map. It is meant to be removed.
Removal of the `crossmap` will fail because the `reclassed` map
depends on it. Removing the `reclassed` map is not desired, since it is an
output.


An extra `g.copy` will solve this, i.e.
```
g.copy raster=reclassed,output
```
then force removal of both:
```
g.remove -f -b type=raster name=crossmap
```
This will still leave, in my system, a trace of the `reclassed` map:
```
g.list raster
```
will still print the `reclassed` map as a result, although `r.info
reclassed` will fail.

Is there an elegant alternative?

Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3627: i.group: file= parameter for input desired

[GRASS GIS]

#3627: i.group: file= parameter for input desired
-+-
 Reporter:  neteler  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.6.0
Component:  Imagery  |Version:  7.4.0
 Keywords:  i.group  |CPU:  Unspecified
 Platform:  All  |
-+-
 To enter the input to i.group can reach a significant number of map names.

 On Unix like systems backticks can be used to feed in g.list output with
 regex/wildcard search. However, this fails on Windows. Here the file
 parameter would be handy:

 {{{
 # r.series example, also works on Windows as no backticks involved
 g.list rast pattern="tmean.1981_2010.*.avg"
 output=list_tmean_1981_2010.csv
 r.series file=list_tmean_1981_2010.csv ...
 }}}

 Wish: add a "file" parameter to i.group is it exists for r.series and
 other commands.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Parsing output of r.category which includes labels

[Nikos Alexandris]

* Stefan Blumentrath  [2018-08-23 07:23:12 +]:


Dear Nikos,

Can you give us a bit more context?  What is it you want to achieve?
How are you using r.stats and what is it you want to do with the
output?

Personally, I am not too familiar with performance implications of
NumPy vs. plain Python, but rather use NumPy for convenience in
matrix/table operations (avoiding pandas)...


```
for category in categories:
   statistics_filename = prefix + '_' + category
   r.stats(input=(base,reclassified),
   output=statistics_filename,
   flags='ncapl',
   separator=',',
   quiet=True)
```

Instead, I want to (modify the above so as to) collect/direct all
iterations in one output file.

The question, finally, seems to be: use Python's 'csv' library or prefer
NumPy? The number of records might reach tens of thousands (or more).

Nikos



signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2631: Future winGRASS needs python-ply package

[GRASS GIS]

#2631: Future winGRASS needs python-ply package
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.4
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  OSGeo4W, winGRASS, decencies,
   CPU:  |  requirements
  Unspecified|   Platform:  MSWindows 8
-+-

Comment (by neteler):

 We just got hit by this problem at GeoSTAT 2018 teaching - any solution?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Parsing output of r.category which includes labels

[Moritz Lennert]

On 23/08/18 11:52, Nikos Alexandris wrote:

* Stefan Blumentrath  [2018-08-23 07:23:12 +]:


Dear Nikos,

Can you give us a bit more context?  What is it you want to achieve?
How are you using r.stats and what is it you want to do with the
output?

Personally, I am not too familiar with performance implications of
NumPy vs. plain Python, but rather use NumPy for convenience in
matrix/table operations (avoiding pandas)...


```
for category in categories:
 statistics_filename = prefix + '_' + category
 r.stats(input=(base,reclassified),
 output=statistics_filename,
 flags='ncapl',
 separator=',',
 quiet=True)
```

Instead, I want to (modify the above so as to) collect/direct all
iterations in one output file.


You can check the r.neighborhoodmatrix addon for one solution which I 
shamelessly took from a SE answer:


https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.neighborhoodmatrix/r.neighborhoodmatrix.py#L152

The code takes a list of filenames and the merges these files.

I've been confronted with a similar problem using v.db.select these days 
and I've been thinking about adding a flag / parameter to relevant 
modules allowing to append an existing file, instead of overwriting it. 
Should just be a case of using mode "a" instead of "w", so shouldn't be 
too complicated.


If you want to, try it with r.stats, by applying this change:

Index: raster/r.stats/main.c
===
--- raster/r.stats/main.c   (révision 72717)
+++ raster/r.stats/main.c   (copie de travail)
@@ -223,7 +223,7 @@

 name = option.output->answer;
 if (name != NULL && strcmp(name, "-") != 0) {
-   if (NULL == freopen(name, "w", stdout)) {
+   if (NULL == freopen(name, "a", stdout)) {
G_fatal_error(_("Unable to open file <%s> for writing"), name);
}
 }

and report back if it works as expected...

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

Re: [GRASS-dev] Parsing output of r.category which includes labels

[Nikos Alexandris]

* Moritz Lennert  [2018-08-23 13:02:03 +0200]:


On 23/08/18 11:52, Nikos Alexandris wrote:

* Stefan Blumentrath  [2018-08-23 07:23:12 +]:


Dear Nikos,

Can you give us a bit more context?  What is it you want to achieve?
How are you using r.stats and what is it you want to do with the
output?

Personally, I am not too familiar with performance implications of
NumPy vs. plain Python, but rather use NumPy for convenience in
matrix/table operations (avoiding pandas)...


```
for category in categories:
statistics_filename = prefix + '_' + category
r.stats(input=(base,reclassified),
output=statistics_filename,
flags='ncapl',
separator=',',
quiet=True)
```

Instead, I want to (modify the above so as to) collect/direct all
iterations in one output file.


You can check the r.neighborhoodmatrix addon for one solution which I 
shamelessly took from a SE answer:


https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.neighborhoodmatrix/r.neighborhoodmatrix.py#L152

The code takes a list of filenames and the merges these files.

I've been confronted with a similar problem using v.db.select these 
days and I've been thinking about adding a flag / parameter to 
relevant modules allowing to append an existing file, instead of 
overwriting it. Should just be a case of using mode "a" instead of 
"w", so shouldn't be too complicated.


If you want to, try it with r.stats, by applying this change:

Index: raster/r.stats/main.c
===
--- raster/r.stats/main.c   (révision 72717)
+++ raster/r.stats/main.c   (copie de travail)
@@ -223,7 +223,7 @@

name = option.output->answer;
if (name != NULL && strcmp(name, "-") != 0) {
-   if (NULL == freopen(name, "w", stdout)) {
+   if (NULL == freopen(name, "a", stdout)) {
G_fatal_error(_("Unable to open file <%s> for writing"), name);
}
}

and report back if it works as expected...

Moritz


I am sneaking in your scripts a lot lately. Just didn't see this, nor
did my greps/ags hit it.

The modification to r.stats works fine. So, it's a matter of an extra
flag then. Yet, I guess, this is to be explained with a proper warning (?).

Thank you Moritz, Nikos

ps- Some of my e-mails fail to deliver to your mailbox.


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

[Stefan Blumentrath]

Hi Marcus,

I am not too familiar with C and the like so I might confuse some things here...

I noticed that using .buffer() in PyGRASS gives a lot of "using native format" 
output.

So I looked it up and it seems to be using native buffering (Vect_area_buffer2):
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/geometry.py#L1654

And Vect_area_buffer2 is the non-geos buffering, right?
https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.buffer/main.c#L564

So, should then PyGRASS be changed/fixed to use geos buffering too?
Shall I open a ticket?

Cheers,
Stefan


-Original Message-
From: grass-dev  On Behalf Of GRASS GIS
Sent: onsdag 22. august 2018 22:07
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

#3448: v.buffer native failures
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.6.0
 Component:  Vector   |Version:  unspecified
Resolution:  wontfix  |   Keywords:  v.buffer v.parallel
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mmetz):

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


Comment:

 This is a long known issue and the reason why v.buffer uses GEOS  buffering. 
GRASS native buffering will probably not be fixed because GEOS  buffering is 
working, thus closing as won't fix.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-user] Fwd: [Projects] OSGeo Annual General Meeting - projects please join and report (August 30 2018)

[Markus Neteler]

On Thu, Aug 16, 2018 at 5:12 PM Markus Neteler  wrote:
>
> On Mon, Aug 6, 2018 at 12:46 AM Vaclav Petras  wrote:
> > I have created a page for 2017 based on the two slides from AGM 2017:
> > https://trac.osgeo.org/grass/wiki/AnnualReport/2017
> >
> > The page for 2018 is here (please, contribute):
> > https://trac.osgeo.org/grass/wiki/AnnualReport/2018
>
> Thanks for creating the pages. I have added some content but a few
> more items may be needed (and some nice screenshots)

Does anyone volunteer to update accordingly

https://docs.google.com/presentation/d/1imiG7x09ry7lGvmS15FCVq2Z7yaICY00fcpXBK27TXY/edit?usp=sharing
?

Markus

/me at GeoSTAT 2018 at time
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3564: Inconsistent results from qsort callback in g.mkfontcap

[GRASS GIS]

#3564: Inconsistent results from qsort callback in g.mkfontcap
--+
  Reporter:  yugr |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.4.2
 Component:  Default  |Version:  7.4.0
Resolution:  fixed|   Keywords:  qsort callback
   CPU:  All  |   Platform:  All
--+
Changes (by mmetz):

 * status:  reopened => closed
 * resolution:   => fixed
 * milestone:  7.6.0 => 7.4.2


Comment:

 Replying to [comment:12 neteler]:
 > Do(n't) we want a bulk backport? If yes, I can do that

 Backported to relbr74 with r73145.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

[Markus Metz]

On Thu, Aug 23, 2018 at 1:39 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:
>
> Hi Marcus,
>
> I am not too familiar with C and the like so I might confuse some things
here...
>
> I noticed that using .buffer() in PyGRASS gives a lot of "using native
format" output.

this "using native format" refers to the format of newly created vector
maps (could also be OGR via v.external.out)
>
> So I looked it up and it seems to be using native buffering
(Vect_area_buffer2):
>
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/geometry.py#L1654
>
> And Vect_area_buffer2 is the non-geos buffering, right?
>
https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.buffer/main.c#L564
>
> So, should then PyGRASS be changed/fixed to use geos buffering too?

all vector buffering functions in the vector libs are GRASS native
functions, only the module v.buffer uses GEOS buffering. That means you
should use v.buffer instead of vector library functions.

> Shall I open a ticket?

yes please, pygrass should use the module v.buffer, or GEOS functions

Markus M
>
> Cheers,
> Stefan
>
>
> -Original Message-
> From: grass-dev  On Behalf Of GRASS GIS
> Sent: onsdag 22. august 2018 22:07
> Cc: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures
>
> #3448: v.buffer native failures
> --+-
>   Reporter:  marisn   |  Owner:  grass-dev@…
>   Type:  defect   | Status:  closed
>   Priority:  normal   |  Milestone:  7.6.0
>  Component:  Vector   |Version:  unspecified
> Resolution:  wontfix  |   Keywords:  v.buffer v.parallel
>CPU:  Unspecified  |   Platform:  Unspecified
> --+-
> Changes (by mmetz):
>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  This is a long known issue and the reason why v.buffer uses GEOS
 buffering. GRASS native buffering will probably not be fixed because GEOS
 buffering is working, thus closing as won't fix.
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3628: PyGRASS: Use GEOS buffering

[GRASS GIS]

#3628: PyGRASS: Use GEOS buffering
-+-
 Reporter:  sbl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.4.2
Component:  PyGRASS  |Version:  svn-trunk
 Keywords:  buffer   |CPU:  All
 Platform:  All  |
-+-
 Currently, PyGRASS uses native buffering functions (Vect_area_buffer2):
 
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/geometry.py#L1654
 This is known to have issues, which are not planned to be fixed (see:
 #3448).

 Thus PyGRASS should use GEOS-based buffering (as in v.buffer):
 https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.buffer/main.c#L564

 For discussion ML see:
 https://lists.osgeo.org/pipermail/grass-dev/2018-August/089382.html

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

[Stefan Blumentrath]

Thanks for the explanation.
Ticket created…

From: Markus Metz 
Sent: torsdag 23. august 2018 17:20
To: Stefan Blumentrath 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures



On Thu, Aug 23, 2018 at 1:39 PM Stefan Blumentrath 
mailto:stefan.blumentr...@nina.no>> wrote:
>
> Hi Marcus,
>
> I am not too familiar with C and the like so I might confuse some things 
> here...
>
> I noticed that using .buffer() in PyGRASS gives a lot of "using native 
> format" output.

this "using native format" refers to the format of newly created vector maps 
(could also be OGR via v.external.out)
>
> So I looked it up and it seems to be using native buffering 
> (Vect_area_buffer2):
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/geometry.py#L1654
>
> And Vect_area_buffer2 is the non-geos buffering, right?
> https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.buffer/main.c#L564
>
> So, should then PyGRASS be changed/fixed to use geos buffering too?

all vector buffering functions in the vector libs are GRASS native functions, 
only the module v.buffer uses GEOS buffering. That means you should use 
v.buffer instead of vector library functions.

> Shall I open a ticket?

yes please, pygrass should use the module v.buffer, or GEOS functions

Markus M
>
> Cheers,
> Stefan
>
>
> -Original Message-
> From: grass-dev 
> mailto:grass-dev-boun...@lists.osgeo.org>> 
> On Behalf Of GRASS GIS
> Sent: onsdag 22. august 2018 22:07
> Cc: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures
>
> #3448: v.buffer native failures
> --+-
>   Reporter:  marisn   |  Owner:  grass-dev@…
>   Type:  defect   | Status:  closed
>   Priority:  normal   |  Milestone:  7.6.0
>  Component:  Vector   |Version:  unspecified
> Resolution:  wontfix  |   Keywords:  v.buffer v.parallel
>CPU:  Unspecified  |   Platform:  Unspecified
> --+-
> Changes (by mmetz):
>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  This is a long known issue and the reason why v.buffer uses GEOS  buffering. 
> GRASS native buffering will probably not be fixed because GEOS  buffering is 
> working, thus closing as won't fix.
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #831: v.category options sum, del, and add do nothing

[GRASS GIS]

#831: v.category options sum, del, and add do nothing
--+--
  Reporter:  isaacullah   |  Owner:  martinl
  Type:  enhancement  | Status:  new
  Priority:  major|  Milestone:  7.4.2
 Component:  Vector   |Version:  svn-develbranch6
Resolution:   |   Keywords:  v.category
   CPU:  All  |   Platform:  All
--+--

Comment (by mmetz):

 Replying to [comment:12 mlennert]:
 > In the light of this discussion, I would actually rather plead for
 v.category not creating any attribute table than changing the contents of
 that table. And I would agree that the v.category man page could be more
 explicit about some of these issues.

 I agree that not creating any attribute table is probably the safest
 solution: it will not overload the module and at the same time makes it
 more explicit that category values have been changed, thus the old
 attribute tables have become meaningless.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3627: i.group: file= parameter for input desired

[GRASS GIS]

#3627: i.group: file= parameter for input desired
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.6.0
 Component:  Imagery  |Version:  7.4.0
Resolution:   |   Keywords:  i.group
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by mmetz):

 Please try trunk r73147

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] New addon v.rast.bufferstats

[Stefan Blumentrath]

Dear all,

I just uploaded a new addon "v.rast.bufferstats" [1] that extracts different 
raster statistics in multiple buffers around vector geometries.
It is looping over input geometries and thus not very performant with lots of 
input geometries. But it can be convenient for e.g. characterizing the 
surrounding of study sites...

Testing and feedback is very welcome.

Kind regards,
Stefan

1: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.rast.bufferstats

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

Re: [GRASS-dev] On post-processing a raster map's mapcalc related history string

[Vaclav Petras]

On Thu, Aug 23, 2018 at 5:40 AM Nikos Alexandris 
wrote:
>
> Is there an elegant alternative?

As for your script design/coding approach:

You were concerned about nice history at one point. You can wrap it, not
just in a plain script, but in a module. Then you can hide any particulars
of the implementation and write proper history in the module. This avoids
changing history which would lead to history not being representative of
what actually happened (provenance is the keyword here).

If you actually publish the module or not that's a different question. Your
script/code is needed to reproduce the data in anyway since you want to
change history and additionally it would be reasonable to use your
script/code to actually reproduce, so then the only difference is number of
files and interface of the scripts (some custom solution versus module).

Splitting your code would also make sense because you are saying it is
quite long.

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

Re: [GRASS-dev] [GRASS GIS] #3537: Add functionalities –tmp-location and –no-clean

[GRASS GIS]

#3537: Add functionalities –tmp-location and –no-clean
-+--
  Reporter:  radeknovotny94  |  Owner:  grass-dev@…
  Type:  enhancement | Status:  closed
  Priority:  normal  |  Milestone:  7.6.0
 Component:  Startup |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  tmp-location, no-clean, exec
   CPU:  All |   Platform:  All
-+--

Comment (by wenzeslaus):

 Hi Nikos, I'm looking at this now and:

 1) I can't reproduce the "if the file does not exist, the process hangs"
 behavior from your [https://lists.osgeo.org/pipermail/grass-
 user/2018-August/078970.html email]. I get `ERROR: ... xxx.xxx: No such
 file or directory`.

 2) This should be really a separate ticket because it is/would be a bug
 (this is a closed enhancement ticket).

 3) It is unrelated to `--tmp-location` unless you can show that it does
 not happen with `-c` (important only for testing and reporting).

 4) Your considerations about what to report based on what are the right
 thing to do, let's discuss it in a new ticket of you can reproduce the
 hanging or you have some other issues (like the message).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3537: Add functionalities –tmp-location and –no-clean

[GRASS GIS]

#3537: Add functionalities –tmp-location and –no-clean
-+--
  Reporter:  radeknovotny94  |  Owner:  grass-dev@…
  Type:  enhancement | Status:  closed
  Priority:  normal  |  Milestone:  7.6.0
 Component:  Startup |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  tmp-location, no-clean, exec
   CPU:  All |   Platform:  All
-+--

Comment (by Nikos Alexandris):

 I didn't open a new ticket for this because I (wrongly) thought it to be
 part of the implementation of --tmp-location. Will open one--though the
 problem might reside on my OS/File-System side.

-- 
Ticket URL: 
GRASS GIS 

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