On 03-07-14 03:43, Vaclav Petras wrote:
On Wed, Jul 2, 2014 at 8:15 PM, Glynn Clements
mailto:gl...@gclements.plus.com>> wrote:
> Shouldn't the seed not be generated on e.g, OS time,
> which would ensure that each run would give a different result?
No. The reason is to provide r
>There shouldn't be any practial limitation on the length of an
>expression in r60662 and later.
there are similar steps in the script
[1]
http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.valley.bottom/r.valley.bottom.py#L205
[2]
http://trac.osgeo.org/grass/browser/grass-addons/g
Helmut Kudrnovsky wrote
>
> Glynn Clements wrote
>> Helmut Kudrnovsky wrote:
>>
>> There shouldn't be any practial limitation on the length of an
>> expression in r60662 and later.
>>
>> [Previously, there may have been OS-imposed limitations on the length
>> of a command line, but r60662 change
Glynn Clements wrote
> Helmut Kudrnovsky wrote:
>
>> by running the python script, a r.mapcalc-error pops up that the
>> expression
>> line is to long.
>
> Can you provide the exact message?
>
> There shouldn't be any practial limitation on the length of an
> expression in r60662 and later.
>
>
On Wed, Jul 2, 2014 at 8:15 PM, Glynn Clements
wrote:
> > Shouldn't the seed not be generated on e.g, OS time,
> > which would ensure that each run would give a different result?
>
> No. The reason is to provide reproducibility. Anyone running the same
> command with the same data should obtain t
On Wed, Jul 2, 2014 at 7:35 PM, Glynn Clements
wrote:
> kwargs['shell'] = True
> args = [self._escape_for_shell(arg) for arg in args]
>
Considering security issues connected to shell=True* and uncertainty of
escaping for MS Windows**, wouldn't be better to avoid shell=True and try
to use the rig
On Wed, Jul 2, 2014 at 7:40 AM, Helmut Kudrnovsky wrote:
>
> maybe let's spend some money to fix some crucial OS-depending issues...
>
I think that this a very good idea. Do you have a concrete idea how to do
that?
___
grass-dev mailing list
grass-dev@li
Moritz Lennert wrote:
> > But in the longer term, should we be claiming to support a platform
> > for which we appear to have no active developers?
>
> I think that the question merits discussion. In my teaching experience
> it has been very helpful to have a MS Windows version to allow student
Martin Landa wrote:
> > Personally, I don't favour duplicating information which is stored
> > elsewhere (e.g. which files are affected).
>
> we know, btw r60590 (G_fatal_longjmp()) lacks _any_ documentation, at
> least minimal info in doxygen format would be nice...
/* You probably sho
Helmut Kudrnovsky wrote:
> by running the python script, a r.mapcalc-error pops up that the expression
> line is to long.
Can you provide the exact message?
There shouldn't be any practial limitation on the length of an
expression in r60662 and later.
[Previously, there may have been OS-impose
Paulo van Breugel wrote:
> When I run several times e.g., r.mapcalc "a = rand(0,100)"
>
> I am always getting exactly the same layer. In the help file it reads:
>
> "The environment variable GRASS_RND_SEED is read to initialize the random
> number generator"
>
> But what does it mean.
The val
Anna Petrášová wrote:
> Running this command in gui console works but r.info gives incorrect result:
> r.support map=scanned title="|@#$%^&*()"
> and r.info gives ^^^|@#$%^^^&*()
That implies that the GUI is escaping for the shell but then either
not using the shell or overdoing the escaping
Anna Petrášová wrote:
> > It's because it can't find v.in.gps. I suggest to add to the patch
> something like this:
>
> +def __init__(self, args, **kwargs):
> +if ( sys.platform == 'win32'
> + and isinstance(args, list)
> + and not kwargs.get('shell', False)
>
Hi,
2014-06-29 14:05 GMT+02:00 Glynn Clements :
> Personally, I don't favour duplicating information which is stored
> elsewhere (e.g. which files are affected).
we know, btw r60590 (G_fatal_longjmp()) lacks _any_ documentation, at
least minimal info in doxygen format would be nice...
Martin
-
Hi,
2014-06-27 17:10 GMT+02:00 Martin Landa :
>> http://trac.osgeo.org/grass/wiki/Submitting/General#Commitmessages
>
> thanks for this initiative!
an idea which could really help to a person who goes through svn logs
and collects items for the news on trac. The commits which should go
to the ne
Hi Stefan,
> 2014-07-02 9:35 GMT+02:00 Blumentrath, Stefan :
>
> Hi Matej,
> I was wondering, did you consider storing keyword lists, points of
contacts, and > so on in a central (SQLite) database (comparable to what
the t.*-modules do with > time series)? For organizations it would be
useful to h
Helmut Kudrnovsky wrote
> hi,
>
> given in a pynthon script:
>
>
> offsets3 = [d
> for j in xrange(1,6+1)
> for i in [j,-j]
> for d in
> [(i,0),(i,1),(i,2),(i,3),(i,4),(i,5),(i,6),(i,-1),(i,-2),(i,-3),(i,-4),(i,-5),(i,-6)]]
>
>
When I run several times e.g., r.mapcalc "a = rand(0,100)"
I am always getting exactly the same layer. In the help file it reads:
"The environment variable GRASS_RND_SEED is read to initialize the random
number generator"
But what does it mean. Shouldn't the seed not be generated on e.g, OS time
Hi,
2014-07-02 17:19 GMT+02:00 Anna Petrášová :
> It's because it can't find v.in.gps. I suggest to add to the patch something
> like this:
thanks, I included modified patch to the next build n1011. Martin
___
grass-dev mailing list
grass-dev@lists.os
Hi, I am trying to compile grass7 (revision 61123) on Ubuntu 14.04, but the
configuring fails with:
...
checking whether to use GDAL... yes
checking for gdal-config... /usr/bin/gdal/bin/gdal-config
configure: error: *** Unable to locate GDAL library.
The path /usr/bin/gdal/bin/gdal-config is corr
hi,
given in a pynthon script:
offsets3 = [d
for j in xrange(1,6+1)
for i in [j,-j]
for d in
[(i,0),(i,1),(i,2),(i,3),(i,4),(i,5),(i,6),(i,-1),(i,-2),(i,-3),(i,-4),(i,-5),(i,-6)]]
terms3 = ["(DEM_smoothed_step3_coarsed[%
Hi,
Apparently, for unprojected reference systems, r.proj doesn't accept the
parameter resolution expressed in DD:MM:SS, but only in decimal degrees (at
least for me, any other experience?), while for example g.region does
accept this format. The type of the parameter resolution is float for
r.pro
On Wed, Jul 2, 2014 at 11:19 AM, Anna Petrášová
wrote:
>
>
>
> On Wed, Jul 2, 2014 at 10:59 AM, Vaclav Petras
> wrote:
>
>>
>> On Wed, Jul 2, 2014 at 10:39 AM, Martin Landa
>> wrote:
>>
>>> The reason is empty XML wxGUI menu file (menudata.xml) produced by
>>> building system, see [2].
>>>
>>>
On Wed, Jul 2, 2014 at 10:59 AM, Vaclav Petras wrote:
>
> On Wed, Jul 2, 2014 at 10:39 AM, Martin Landa
> wrote:
>
>> The reason is empty XML wxGUI menu file (menudata.xml) produced by
>> building system, see [2].
>>
>> Traceback (most recent call last):
>> File "core/toolboxes.py", line 759,
On Wed, Jul 2, 2014 at 10:39 AM, Martin Landa
wrote:
> The reason is empty XML wxGUI menu file (menudata.xml) produced by
> building system, see [2].
>
> Traceback (most recent call last):
> File "core/toolboxes.py", line 759, in
> sys.exit(main())
> File "core/toolboxes.py", line 745, i
2014-07-02 1:10 GMT+02:00 Glynn Clements :
> Does anyone want to test the attached patch?
I have locally applied the patch on the build server, result is
`r61114M-1010` [1], GRASS starts (welcome screen), unfortunately wxGUI
fails with
File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\wxg
I agree with Martin and Helmut.
In my experience, the bulk of the existing GIS users are using Windows and
those using GIS professionally are often in work environments where the use
of virtual machines or installation of other OS's is prohibited.
The unfortunate fact is that many GIS users have
Martin Landa wrote
> Hi,
>
> 2014-07-02 13:22 GMT+02:00 Moritz Lennert <
> mlennert@.worldonline
> >:
>> [Starting a new thread as this is an important point on its own. Original
>> mail is [1].]
>>
>> On 02/07/14 01:10, Glynn Clements wrote:> But in the longer term, should
>> we
>> be claiming
Hi,
2014-07-02 13:22 GMT+02:00 Moritz Lennert :
> [Starting a new thread as this is an important point on its own. Original
> mail is [1].]
>
> On 02/07/14 01:10, Glynn Clements wrote:> But in the longer term, should we
> be claiming to support a platform
>> for which we appear to have no active d
[Starting a new thread as this is an important point on its own.
Original mail is [1].]
On 02/07/14 01:10, Glynn Clements wrote:> But in the longer term, should
we be claiming to support a platform
> for which we appear to have no active developers?
I think that the question merits discussion
#2337: t.list hangs on newly created temporal DB
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Hi Matej,
Thanks for working on metadata support in GRASS!
I am very much looking forward to having the modules you are developing in
core. The documentation about your work which you have on the Wiki looks very,
very promising!
I was wondering, did you consider storing keyword lists, points of
32 matches
Mail list logo
