On Wed, Nov 26, 2014 at 2:48 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 26/11/14 14:33, Markus Neteler wrote:
On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Backport done in r62858 - r62867.
I hope everything works fine.
Great, thanks
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
On 26 November 2014 at 20:22, Anna Petrášová kratocha...@gmail.com wrote:
I agree.
Maybe we should add daily temperature far a year, (they are usefull
for t.rast.accumulate) do you have these data?
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
I dowloaded the scene the Landsat5 MSS scene LM50160351987287AAA03.
After importing in a utm_z17n based Location, the bands are listed as
B1, B2, B3 and B4.
Running i.landsat.toar fails:
i.landsat.toar -r input_prefix=B output_prefix=Rad.
metfile=LM50160351987287AAA03_MTL.txt
Writing
#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
Hi,
it looks like the problem is the function decorator @mdebug. I am
not a Python expert, but IMHO this problem occurs because:
1.) Windows sucks ;)
2.) The function decorator code is analysed at import time, which is a
bad idea, since the messaging server process get started at import
time.
Hi devs,
I'm working on temporal documentation replacing the example with the
future temporal dataset that I'm working on, so I'm testing more or
less all the command.
I'm not able to run t.rast.neighbors for this problem
t.rast.neighbors input=tempmean_monthly output=smooth_tempmean_monthly
2014-11-26 21:15 GMT+01:00 Anna Petrášová kratocha...@gmail.com:
I just realized temporal framework doesn't work with recent GRASS 70 version
on Windows:
t.list or t.create give me:
[...]
File C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py, line 258,
in __init__
Hi Luca,
thanks for the report. Your solution is correct, the bug should be
fixed in r63184/trunk.
I will backport the changes to grass70 as well.
Best regards
Soeren
2014-11-27 11:41 GMT+01:00 Luca Delucchi lucadel...@gmail.com:
Hi devs,
I'm working on temporal documentation replacing the
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
These are binaries and needed for testing purposes. They are called by
gunittest Python scripts, so they need to be in the module path. They
are build by default, but surely can be removed from Windows or Linux
package/distributions.
An other approach would be to add test build to the Makefile
Hi,
thats a nice idea indeed.
However, such auto-generated tests can only verify if the called
modules can be executed and if they return 0.
They can not replace tests that verify the result of the processing or
correct error handling.
The next problem is how to distinguish between a
Hi,
2014-11-26 14:33 GMT+01:00 Markus Neteler nete...@osgeo.org:
On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Backport done in r62858 - r62867.
I hope everything works fine.
Great, thanks for your efforts!
Actually, all the work, including writing the
On Thu, Nov 27, 2014 at 4:21 AM, Luca Delucchi lucadel...@gmail.com wrote:
On 26 November 2014 at 20:22, Anna Petrášová kratocha...@gmail.com
wrote:
I agree.
Maybe we should add daily temperature far a year, (they are usefull
for t.rast.accumulate) do you have these data?
No, there
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
On Thu, Nov 27, 2014 at 8:19 AM, Sören Gebbert soerengebb...@googlemail.com
wrote:
The next problem is how to distinguish between a module/shell-command
and the generated output in the manual page? I have plenty of examples
in the temporal module manual pages that provide the stdout/stderr
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
On Wed, Nov 26, 2014 at 12:30 PM, Moskovitz, Bob@DOC
bob.moskov...@conservation.ca.gov wrote:
This almost sound like the PostGIS Garden Test:
http://trac.osgeo.org/postgis/wiki/DevWikiGardenTest
Thanks for the link. This is also a good idea, although I'm not sure how
much it is applicable to
#2454: wxgui: list of db columns only becomes available after entering layer
number by hand
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: new
#2454: wxgui: list of db columns only becomes available after entering layer
number by hand
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: new
Hi Sören,
On Thu, Nov 27, 2014 at 11:38 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
My solution would be to remove the function decorator code using the
most simple approach to add debug messages to the module interface:
Instead of a function decorator we place this code snippet in
On Thu, Nov 27, 2014 at 11:38 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
The function decorator code is analysed at import time, which is a
bad idea, since the messaging server process get started at import
time. This should be avoided on any OS.
I would like to better understand,
#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
Unfortunately i have no idea. I did not found good information about
when and how exactly these decorators are processed.
So my guess was that (because of the backtrace) the decorator function
is somehow analyzed at import time and the messenger process gets
started.
So maybe the difference is
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
On Fri, Nov 21, 2014 at 4:15 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On Fri, Nov 21, 2014 at 4:09 AM, Markus Neteler nete...@osgeo.org wrote:
Hi,
On Fri, Nov 21, 2014 at 5:00 AM, svn_gr...@osgeo.org wrote:
Author: wenzeslaus
Date: 2014-11-20 20:00:29 -0800 (Thu, 20 Nov 2014)
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
2014-11-27 18:12 GMT+01:00 Markus Neteler nete...@osgeo.org:
Then it should be renamed.
We cannot add continuously new scripts with similar names...
+1
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2272: Improve consistency in random generator usage
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: major|
Markus Neteler wrote:
Author: glynn
Date: 2014-09-17 15:43:22 -0700 (Wed, 17 Sep 2014)
New Revision: 62026
Modified:
grass/trunk/display/d.info/main.c
grass/trunk/include/defs/display.h
grass/trunk/lib/display/r_raster.c
grass/trunk/lib/display/setup.c
Log:
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
Michael Barton wrote:
Why do we need to do this?
Because getting developers to agree to maintaining a stable ABI (then
ensuring that actually happens) appears to be beyond our capabilities.
Probably the most common (and certainly the most obvious) example of
incompatible changes (and the
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
Sören Gebbert wrote:
I would like to better understand, this point...
Why the decorator must_be_open it seems to work so far?
which is the difference between @must_be_open[0] and @mdebug[1]?
Any Ideas?
Unfortunately i have no idea. I did not found good information about
when and how
#2454: wxgui: list of db columns only becomes available after entering layer
number by hand
---+
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: closed
#2439: g.gui.iclass crashes
---+
Reporter: madi | Owner: grass-dev@…
Type: defect | Status: new
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2439: g.gui.iclass crashes
---+
Reporter: madi | Owner: grass-dev@…
Type: defect | Status: new
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2439: g.gui.iclass crashes
---+
Reporter: madi | Owner: grass-dev@…
Type: defect | Status: new
#2482: g.gui.iclass: temp maps are not erased when tool is closed
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
On Thu, Nov 27, 2014 at 12:15 PM, Martin Landa landa.mar...@gmail.com
wrote:
2014-11-27 18:12 GMT+01:00 Markus Neteler nete...@osgeo.org:
Then it should be renamed.
We cannot add continuously new scripts with similar names...
+1
You mean r.shaded.relief versus [dr].shadedmap?
On Wed, Nov 26, 2014 at 2:13 PM, Michael Barton michael.bar...@asu.edu
wrote:
Why do we need to do this?
From my experience it it good to have it. The risk of getting some cryptic
errors is pretty high. This will tell you exactly what's happening before
anything cryptic actually happens.
#2272: Improve consistency in random generator usage
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: major|
55 matches
Mail list logo
