date:20130726

>
>
>Note that Python 3 includes a launcher utility for Windows:
>
>   http://docs.python.org/3/using/windows.html#launcher
>
>The idea is that the .py extension can be associated with the
>launcher, which can be configured to use a specific version of Python
>in a specific context.
>
>I don't know whether it's possible to make use of this without
>installing the rest of Python 3, though.

just a quick test done:

- downloaded Python 3.3.2 Windows x86 MSI Installer
- Python 3.3.2 extracted but _nothing_ installed (no registry entry)
- opened a windows console and change into the extracted folder: cd
C:\dl\python-3.3.2\pythonXYZ 

- C:\dl\python-3.3.2\pythonXYZ>py --version
Python 2.7.2

it finds the system wide python installation of ArcGIS here on my box

- quick script test listed here:
http://docs.python.org/3/using/windows.html#from-a-script

#! python
import sys
sys.stdout.write("hello from Python %s\n" % (sys.version,))

>From the directory in which hello.py lives, execute the command:

py hello.py

C:\dl\python-3.3.2\pythonXYZ>py hello.py
hello from Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit
(Intel)]


so for the first quick test it seems it works without installing the rest of
Python 3.

further testing needed...






-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5069037.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory

#2045: r.to.vect: use less memory
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.to.vect memory  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by mmetz):

 Replying to [comment:3 mlennert]:
 > Replying to [comment:2 mlennert]:
 > > Replying to [comment:1 mmetz]:
 > > > Replying to [ticket:2045 mlennert]:
 > > > > Trying to convert a raster file to vector areas on a machine with
 10GB, the process was killed after having used up all memory and swap.
 > > >
 > > > There was a memory leak in r.to.vect, fixed in trunk r57281.
 > >
 > > (and r57281)
 > >
 > > Thanks ! I now get through the "Extracting areas..." part without the
 process being killed. I still see continuous increase in memory usage,
 though, up to 88,5% at the end of the extraction stage. Is this normal ?
 > >
 > > Now it's busy writing areas...
 > >
 >
 > And memory usage continued to increase. The process was killed during
 the "Registering primitives..." step.

 You can try to set the environment variable GRASS_VECTOR_LOWMEM before
 running r.to.vect. GRASS_VECTOR_LOWMEM reduces the amount of memory used
 by vector topology structures (the spatial index is built on disk).

 IOW, r.to.vect might use quite a bit of memory which is difficult to
 change, and the vector topology structures also need memory (in g7 much
 less than in g6).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] compilation error GRASS 7.0

2013-07-26 Thread Hamish

Paulo wrote:

>>  Hi, in the last few revisions (including the latest, v57276), I am
>>  getting an error when compiling from source. The error seems to lie in
>>  the v.krige script, running make gives the following error:
..
>>  Running make in the v.krige folder and then rerun make on the main
>>  folder solves the problem but I though I report it anyway.

Moritz:
> I can confirm this. I'll run the build process again to get a log.

Hi,

the trouble is known, the reason is that gui/wxpython/scripts/vkridge.py gets
run at build time (either to get translation strings or check syntax, I'm not
sure which), and it includes $GISBASE/etc/gui/wxpython into the PYTHONPATH.
But it gets run before that exists and you get an error. Run it again later
after that exists and it's fine. I think the solution is just a minor tweak
to the parent Makefile so that it knows what dependency needs to be built
first. Or migrate it into gui/wxpython/modules/ with the others, vkridge.py
is alone in scripts/. Another approach would be to add another try,except
into the python script and sys.exit() if it fails, as is done a few lines away.

[the above is from memory & educated guessing from when I first saw it in the
ubuntu ppa failed nightly build report; may not be entirely accurate]

Hamish

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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-26 Thread Glynn Clements

Moritz Lennert wrote:

> Would it be a possible option to implement only a) and document the fact 
> that the user has to take care of creating a working Python installation 
> herself if they want b) ?

In order to be able to "execute" scripts via the command prompt,
batch files, system(), subprocess.Popen() or similar, the extension
must be associated with an interpreter in the registry. This cannot be
overridden via environment variables.

Note that Python 3 includes a launcher utility for Windows:

http://docs.python.org/3/using/windows.html#launcher

The idea is that the .py extension can be associated with the
launcher, which can be configured to use a specific version of Python
in a specific context.

I don't know whether it's possible to make use of this without
installing the rest of Python 3, though.

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

[GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

2013-07-26 Thread Glynn Clements


Moritz Lennert wrote:

> - Another issue is how to make it possible in windows to launch modules 
> that are Python scripts by simply calling their module name, without .py 
> extension. At this stage, in a fresh installation of GRASS7 on WinXP, I 
> can launch (and successfully execute) python scripts from the wxGUI menu 
> or the wxGUI command console, but not from the windows terminal. 
> However, calling a script from a script (e.g. v.db.dropcolumn called 
> from v.db.renamecolumn) does not work.

To execute scripts without providing an extension, PATHEXT must
include ".PY".

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

Re: [GRASS-dev] [GRASS GIS] #1941: wxGUI fails with Japanese locale

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by glynn):

 Replying to [comment:4 mlennert]:
 > Could this be related to #2021 ?

 That seems unlikely, as this relates to Windows which doesn't use
 environment variables for locale settings.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]


On 26/07/13 17:10, Helmut Kudrnovsky wrote:

IMHO the question is/will be: is there a robust mechanism for calling a

script from a script and making>addons easily callable by the embedded
python interpreter working on WinXp, WinVista, Win7 and Win8?


if this is working robustely, I think we are on a good way for a nice

(python) usable WinGrass6/7... :o)

maybe there could be some hints to solve this?:

Python launcher for Windows
http://www.python.org/dev/peps/pep-0397/


This refers to the Python launcher that Glynn mentioned half a year ago:

http://lists.osgeo.org/pipermail/grass-dev/2013-January/061466.html

The launcher is explained here:

http://docs.python.org/3/using/windows.html#launcher

It actually allows the use of shebang lines:

http://docs.python.org/3/using/windows.html#shebang-lines

And it allows to create a py.ini file to customize the way Python is 
called. A version of that file in the "Application data" directory 
overrides systemwide settings, so I guess we could use something like 
that to customise if shebangs are not enough:


http://docs.python.org/3/using/windows.html#customization

In my limited understanding this actually sounds like a very promising 
solution which avoids having to treat Windows in a very different way. 
shebangs with '/usr/bin/env python' might allow us to solve the issue.


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

[GRASS-dev] GSoC - GRASS GIS - T-Algebra - Weekly report

2013-07-26 Thread Thomas Leppelt

Hi all,

here is the report for the last week. I finished the TGRASS module t.select
and created the corresponding manual page. Furthermore I started to
integrate vector operations into the temporal algebra. In the next week I
will continue to implement the vector operations into the algebra and write
some more examples for the temporal algebra.

Greetings

Thomas

Link to project wiki page:
http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS

Link to project repository:
https://code.google.com/p/grass-gis-temporal-algebra/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #995: WxGUI startup screen fails if GISDBASE path contains non-latin characters

#995: WxGUI startup screen fails if GISDBASE path contains non-latin characters
+---
 Reporter:  marisn  |   Owner:  martinl
 Type:  defect  |  Status:  assigned   
 Priority:  critical|   Milestone:  7.0.0  
Component:  wxGUI   | Version:  svn-releasebranch64
 Keywords:  wingrass, i18n  |Platform:  MSWindows Vista
  Cpu:  Unspecified |  
+---

Comment(by mlennert):

 Replying to [comment:19 mlennert]:
 > Any news on this issue, at least for GRASS 7 ?

 I've just tested in WinXP and can reproduce the startup error when the
 path to GISDBASE contains special characters (in this case latin1
 accents).

 If I follow Maris' comment:18 then the only solution would be to call
 grass.py directly from a python script, and not from a .bat. Is that
 correct ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

>IMHO the question is/will be: is there a robust mechanism for calling a
script from a script and making >addons easily callable by the embedded
python interpreter working on WinXp, WinVista, Win7 and Win8?
>
>if this is working robustely, I think we are on a good way for a nice
(python) usable WinGrass6/7... :o) 

maybe there could be some hints to solve this?:

Python launcher for Windows 
http://www.python.org/dev/peps/pep-0397/

Vienna 36°C ... too much tropical conditions here to follow all the infos in
this link ... ;o)



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068992.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory

#2045: r.to.vect: use less memory
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.to.vect memory  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:2 mlennert]:
 > Replying to [comment:1 mmetz]:
 > > Replying to [ticket:2045 mlennert]:
 > > > Trying to convert a raster file to vector areas on a machine with
 10GB, the process was killed after having used up all memory and swap.
 > >
 > > There was a memory leak in r.to.vect, fixed in trunk r57281.
 >
 > (and r57281)
 >
 > Thanks ! I now get through the "Extracting areas..." part without the
 process being killed. I still see continuous increase in memory usage,
 though, up to 88,5% at the end of the extraction stage. Is this normal ?
 >
 > Now it's busy writing areas...
 >

 And memory usage continued to increase. The process was killed during the
 "Registering primitives..." step.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]


[...]

>Yes, so this should be reformulated as "keep the current option of 
>bundling an embedded python".

yes

>However, again within the limits of my understanding, aren't the issues of
>
>- calling a script from a script
>
>and
>
>- making addons easily callable
>
>linked to the question of system-wide vs embedded Python ?

#!/usr/bin/env python isn't working in windows, so you need other mechanism
to run a python-script with a (specific) python interpreter. 

http://docs.python.org/2/using/windows.html
http://www.python.org/dev/peps/pep-0397/

if python is system wide installed with entries in the registry, then two
jobs mentioned above are worked out by the system wide python.

if python is not system wide installed with entries in the registry, then
you need e.g. a explicit script-invoking by the embedded python interpreter
or a file extension association to the embedded python interpreter. 

at this point calling a script from a script and making addons easily
callable comes in with the known issues. 

nevertheless the wingrass6/7-wxgui itself is working.

>
>IIUC, in order to solve (at least) the first issue, you have to make 
>python code callable and executable without the .py extension, using
>
>assoc .py=Python.File
>and
>ftype Python.File=C:\Path\to\pythonw.exe "%1" %*
>
>but as the ftype setting is system wide, you can't just hijack all 
>python scripts on a machine to use the Python interpreter embedded in
GRASS;

that's another quirks and I'm not in favour of it...

>I'm really not expert enough on these issues, so some input from the 
>gurus would help, here.

the same here...

>
> some more issues related to WinGRASS and python are mentioned also in
>
> http://trac.osgeo.org/grass/ticket/2015
>
>I didn't see this yesterday while experimenting with a fresh install on 
>WinXP without system-wide Python installed. I'll try again with a 
>system-wide Python installed to see if that makes any difference.

in my experience - unfortunately - there seems to be also different
behaviour between WinXp, WinVista, Win7 and Win8...ggg

IMHO the question is/will be: is there a robust mechanism for calling a
script from a script and making addons easily callable by the embedded
python interpreter working on WinXp, WinVista, Win7 and Win8? 

if this is working robustely, I think we are on a good way for a nice
(python) usable WinGrass6/7... :o)

>b) use Python also for command line scripting in the general environment 
>and so install Python system wide (e.g. ArcGIS). In the idea that 
>scripts that call GRASS functions should run also when called from 
>outside a running GRASS "session", this would be the preferable way for us.

this would be a 'nice to have', but IMHO it's more a operating system flaw
than a WinGrass-issue ...








-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068984.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1941: wxGUI fails with Japanese locale

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by mlennert):

 Could this be related to #2021 ?

-- 
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] #2021: encoding information in locale gets lost

#2021: encoding information in locale gets lost
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Startup  | Version:  svn-trunk
 Keywords:  locale encoding  |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [ticket:2021 mlennert]:
 > My locale settings before launching GRASS 7:
 >
 >
 > {{{
 > $ locale
 > LANG=fr_BE.UTF-8
 > LANGUAGE=fr_BE:fr
 > LC_CTYPE="fr_BE.UTF-8"
 > LC_NUMERIC="fr_BE.UTF-8"
 > LC_TIME="fr_BE.UTF-8"
 > LC_COLLATE="fr_BE.UTF-8"
 > LC_MONETARY="fr_BE.UTF-8"
 > LC_MESSAGES="fr_BE.UTF-8"
 > LC_PAPER="fr_BE.UTF-8"
 > LC_NAME="fr_BE.UTF-8"
 > LC_ADDRESS="fr_BE.UTF-8"
 > LC_TELEPHONE="fr_BE.UTF-8"
 > LC_MEASUREMENT="fr_BE.UTF-8"
 > LC_IDENTIFICATION="fr_BE.UTF-8"
 > LC_ALL=
 > }}}
 >
 >
 > locale settings after launching GRASS 7:
 >
 >
 > {{{
 > > locale
 > LANG=fr_BE
 > LANGUAGE=fr_BE
 > LC_CTYPE=fr_BE
 > LC_NUMERIC=C
 > LC_TIME=fr_BE
 > LC_COLLATE=fr_BE
 > LC_MONETARY=fr_BE
 > LC_MESSAGES=fr_BE
 > LC_PAPER=fr_BE
 > LC_NAME=fr_BE
 > LC_ADDRESS=fr_BE
 > LC_TELEPHONE=fr_BE
 > LC_MEASUREMENT=fr_BE
 > LC_IDENTIFICATION=fr_BE
 > LC_ALL=
 > }}}
 >
 >
 > Thus the special characters in translated messages are not displayed
 correctly.
 >
 > This is with svn revision 56918.

 The culprit seems to be r52517 which includes the following line in
 lib/init.grass.py:


 {{{
 language = language.split('.')[0] # Split off ignored .encoding part if
 present
 }}}

 Why should the encoding part be split off, especially since it is _not_
 ignored as implied by the comment. Module messages that have been
 translated (in my case into French) and include special characters are not
 displayed correctly.

 When I comment out this line, I get messages in the correct encoding.

 Maris, could you explain the reason for taking away the encoding info ?
 I'm tempted to comment out the line for now and see if anyone reports
 negative consequences, but I'll wait a few days to see if there is a
 reason for it.

-- 
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] #2045: r.to.vect: use less memory

#2045: r.to.vect: use less memory
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.to.vect memory  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:2045 mlennert]:
 > > Trying to convert a raster file to vector areas on a machine with
 10GB, the process was killed after having used up all memory and swap.
 >
 > There was a memory leak in r.to.vect, fixed in trunk r57281.

 (and r57281)

 Thanks ! I now get through the "Extracting areas..." part without the
 process being killed. I still see continuous increase in memory usage,
 though, up to 88,5% at the end of the extraction stage. Is this normal ?

 Now it's busy writing areas...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment: invalid region id 0


On 26/07/13 15:17, Nikos Alexandris wrote:

On Wednesday 17 of July 2013 12:56:58 Nikos Alexandris wrote:

In any case, if wanted, I will try during the weekend to replicate a Huge
region, as the one Moritz tested with a "rational" threshold (close to
zero).


I couldn't make it -- my machine was under some sort of heavy reconstruction
during the last weekend.  Is this still of interest?  Let a machine to chew-up
a big region with i.segment?



Markus and I have been busy testing in the last weeks and thanks to 
Markus' rapid reaction in correcting some bugs, we've been able to 
segment an image with 555,727,911 non-null cells in a region with 
2,617,375,744 total cells. Markus' machine did this in just 15 hours ! 
On mine it took much longer, but this is probably in large parts due to 
a software raid 5 that makes disk io really slow.


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

Re: [GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory

#2045: r.to.vect: use less memory
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.to.vect memory  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by mmetz):

 Replying to [ticket:2045 mlennert]:
 > Trying to convert a raster file to vector areas on a machine with 10GB,
 the process was killed after having used up all memory and swap.

 There was a memory leak in r.to.vect, fixed in trunk r57281.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment: invalid region id 0

2013-07-26 Thread Nikos Alexandris

On Wednesday 17 of July 2013 12:56:58 Nikos Alexandris wrote:
> In any case, if wanted, I will try during the weekend to replicate a Huge 
> region, as the one Moritz tested with a "rational" threshold (close to
> zero).

I couldn't make it -- my machine was under some sort of heavy reconstruction 
during the last weekend.  Is this still of interest?  Let a machine to chew-up 
a big region with i.segment?

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

[GRASS-dev] [GRASS GIS] #2046: radius limitation option on v.voroni

#2046: radius limitation option on v.voroni
-+--
 Reporter:  dnewcomb |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 In the calculation of foraging areas for different bird species, the
 foraging areas can change based on the location of adjacent nests.  I
 would like to run v.voroni to calculate polygons out to a maximum radius
 as a command line option.  The end result would be similar to running
 v.voroni on a set of points , running v.buffer on each point individually
 create a series of polygon layers of individual circles ( that may
 overlap), then intersecting the geometry of each v.voroni polygon with
 each buffer individually to generate a series of polygon layers that are
 then merged to a single polygon layer.

 The bird species that I have in mind has an 800 m maximum foraging range.
 The preferred out put in this case would be the standard v.voroni polygons
 in areas where nests are closer then 800m.  In areas where there are no
 other nests within 800m the polygon would be an 800m radius circle.  The
 maximum distance from the origin point of the v.voroni polygon to any edge
 of the output polygon would be no greater than the distance given in the
 command line option ( in this case 800m)

-- 
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] #1866: broken db driver communication in winGRASS 7

#1866: broken db driver communication in winGRASS 7
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Database  | Version:  unspecified  
 Keywords:  sqlite, wingrass  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:47 neteler]:
 > Replying to [comment:46 mlennert]:
 > > Can we close this ticket, then ?
 >
 > Shouldn't all relevant db.* be updated accordingly?

 MM enhanced db.columns db.copy db.select in r57274.

 Now backported to devel_branch6 in r57274.
 Relbranch TODO

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory

#2045: r.to.vect: use less memory
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.to.vect memory  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
 Trying to convert a raster file to vector areas on a machine with 10GB,
 the process was killed after having used up all memory and swap.

 The CELL raster in question is an output of i.segment, is quite large and
 has many small segments, i.e. many different raster values:

 {{{

 Rows: 53216
 Columns: 49184
 Total Cells:  2617375744

 Although many of these cells are null:

 total null cells: 2061717280
 non-null cells: 555658464
 }}}

 It would be nice if r.to.vect could handle such large files without using
 up so much memory.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] wingrass7 nightly builds

Any idea when wingrass7 nightly builds will be available again ? As many 
of the current critical issues for grass7 are windows specific, it would 
be great to have the nightly builds to help in testing.


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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]


On 26/07/13 11:40, Helmut Kudrnovsky wrote:

hi,


On 26/07/13 00:04, Helmut Kudrnovsky wrote:
[...]

Would it be a possible option to implement only a)


there is already a bundled/embedded python in standalone WinGRASS6/7 and
OSGeo4w-WinGRASS6/7.


Yes, so this should be reformulated as "keep the current option of 
bundling an embedded python".


However, again within the limits of my understanding, aren't the issues of

- calling a script from a script

and

- making addons easily callable

linked to the question of system-wide vs embedded Python ?

IIUC, in order to solve (at least) the first issue, you have to make 
python code callable and executable without the .py extension, using


assoc .py=Python.File
and
ftype Python.File=C:\Path\to\pythonw.exe "%1" %*

but as the ftype setting is system wide, you can't just hijack all 
python scripts on a machine to use the Python interpreter embedded in GRASS;


I'm really not expert enough on these issues, so some input from the 
gurus would help, here.




some more issues related to WinGRASS and python are mentioned also in

http://trac.osgeo.org/grass/ticket/2015


I didn't see this yesterday while experimenting with a fresh install on 
WinXP without system-wide Python installed. I'll try again with a 
system-wide Python installed to see if that makes any difference.



Moritz

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

Re: [GRASS-dev] compilation error GRASS 7.0


On 26/07/13 11:00, Paulo van Breugel wrote:

Hi, in the last few revisions (including the latest, v57276), I am
getting an error when compiling from source. The error seems to lie in
the v.krige script, running make gives the following error:

Errors in:
/home/paulo/Software/spatial/grass7_trunk/scripts/v.krige
--

Running make in the v.krige folder and then rerun make on the main
folder solves the problem but I though I report it anyway.


I can confirm this. I'll run the build process again to get a log.

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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

hi,

On 26/07/13 00:04, Helmut Kudrnovsky wrote:
[...]
> Would it be a possible option to implement only a)

there is already a bundled/embedded python in standalone WinGRASS6/7 and
OSGeo4w-WinGRASS6/7.

some more issues related to WinGRASS and python are mentioned also in

http://trac.osgeo.org/grass/ticket/2015

>and document the fact
>that the user has to take care of creating a working Python installation
>herself if they want b) ?

I would vote for this.

Windows users may be less used to prepare their system for their own
purposes than Linux users. they are used to get a system out of the box. so
a lot of software applications tends to do things all for their own...

IMHO it is some kind of operating system design flaw made by MS ;o) which
can't be easily solved by an user application.

example case:

application software X wants to install a system wide python installation in
C:\Python27\X and application software Y wants to install a system wide
python installation in C:\Python27\Y (I know such cases), both to work
properly and both maybe with some slightly modifications to python.

but the user wants to work with both applications.

who should decide which one is the 'right' system wide python installation?

-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068898.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.3 release planning


On 26/07/13 09:47, Markus Neteler wrote:

On Wed, Jul 24, 2013 at 12:13 AM, Luca Delucchi  wrote:

On 23 July 2013 12:30, Hamish  wrote:



screenshots for that?


Yes, please provide some catchy screenshots!



Some already existing candidates I see as fitting:

http://grasswiki.osgeo.org/wiki/File:Georectifier_berlin.png
http://grasswiki.osgeo.org/wiki/File:CartographicComposer.png + 
http://grasswiki.osgeo.org/wiki/File:CCPreview.png

http://grasswiki.osgeo.org/wiki/File:WxGUI-modeler-if-else-0.png
http://grasswiki.osgeo.org/wiki/File:Wxgui-location-wizard.png

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

Re: [GRASS-dev] compilation error GRASS 7.0

On Fri, Jul 26, 2013 at 11:00 AM, Paulo van Breugel
 wrote:
> Hi, in the last few revisions (including the latest, v57276), I am getting
> an error when compiling from source. The error seems to lie in the v.krige
> script, running make gives the following error:
>
> Errors in:
> /home/paulo/Software/spatial/grass7_trunk/scripts/v.krige
> --
>
> Running make in the v.krige folder and then rerun make on the main folder
> solves the problem but I though I report it anyway.

Scrolling up in the log of the initial compilation, it shows the bug:

python /storage/1/grass70/dist.x86_64-unknown-linux-gnu/tools/mkhtml.py
wxpyimgview > 
/storage/1/grass70/dist.x86_64-unknown-linux-gnu/docs/html/wxpyimgview.html
Traceback (most recent call last):
  File "/storage/1/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.krige",
line 100, in 
from core import globalvar
ImportError: No module named core
make[3]: *** [v.krige.tmp.html] Error 1
rm v.krige.tmp.html

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

Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]


On 26/07/13 00:04, Helmut Kudrnovsky wrote:

- One of the issues is whether and how to install Python. As Python is
needed both for the wxgui and for scripting, and scripting is something
for which you cannot assume an embedded Python interpreter, the
preferred solution would be to install Python system-wide using the
official Python installer (i.e. possibly having the GRASS installer test
for Python installation and if not present, propose to launch the
download and execution of the official Python installer).


unfortunately and in contrast to Linux/(Mac?), there is 'normally' no
'unique' (system-wide) python 2.x/3.x installation in MS windows OS.

windows user software may/may not bring their own embedded/system wide
installed python versions.

examples for software with embedded python without system wide registry
entries:

e.g.
C:\Program Files (x86)\LibreOffice 4.0\program\python-core-3.3.0
C:\Program Files (x86)\Inkscape\python
[...]

examples for software with a system wide python installation _and_ with
registry entries:

e.g.
C:\Python26\ArcGIS10.0
C:\Python27\ArcGIS10.1
[...]


Yes, and AFAIU, especially via the explanations Glynn gave (notably in 
[1]), the difference between the two options is whether you want to


a) use Python only from within the application, i.e. for internal 
scripts (IIUC, in GRASS this would translate to scripted modules and the 
wxGUI), which is the case for Inkscape and LibreOffice


or

b) use Python also for command line scripting in the general environment 
and so install Python system wide (e.g. ArcGIS). In the idea that 
scripts that call GRASS functions should run also when called from 
outside a running GRASS "session", this would be the preferable way for us.


However, again IIUC, a) is much easier to implement via an embedded 
Python interpreter, while b) causes the issues you mention concerning 
library incompatibilities and the need to install missing necessary 
Python packages.


So the big question is whether we think we can solve the issues related 
to b) with a reasonable effort.


Would it be a possible option to implement only a) and document the fact 
that the user has to take care of creating a working Python installation 
herself if they want b) ?


Moritz



[1] https://trac.osgeo.org/grass/ticket/580#comment:53
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] compilation error GRASS 7.0

2013-07-26 Thread Paulo van Breugel

Hi, in the last few revisions (including the latest, v57276), I am 
getting an error when compiling from source. The error seems to lie in 
the v.krige  script, running make gives the following error:


Errors in:
/home/paulo/Software/spatial/grass7_trunk/scripts/v.krige
--

Running make in the v.krige folder and then rerun make on the main 
folder solves the problem but I though I report it anyway.


Cheers,

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

Re: [GRASS-dev] g.extension error with r.in.redwg and r.fuzzy (GRASS 7)

On Thu, Jul 25, 2013 at 11:22 AM, Johannes Radinger
 wrote:
> Hi,
>
> I tried to install two add-ons (r.in.redwg and r.fuzzy) for GRASS7 on Ubuntu
> (latest revision 57266) but g.extension produces following errors:
>
> g.extension -s extension=v.in.redwg
> svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
> Fetching  from GRASS-Addons SVN (be patient)...
> Compiling...
> entity.c:39:17: fatal error: dwg.h: No such file or
> directory
> compilation terminated.
> make: *** [OBJ.i686-pc-linux-gnu/entity.o] Error 1
> ERROR: Compilation failed, sorry. Please check above error messages.

You need the LibreDWG to be installed, see
http://svn.osgeo.org/grass/grass-addons/grass7/vector/v.in.redwg/v.in.redwg.html


> g.extension -s extension=r.fuzzy
> svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
> Fetching  from GRASS-Addons SVN (be patient)...
> Compiling...
> In file included from logic.c:3:0:
> local_proto.h:21:0: warning: "MAX" redefined [enabled by
> default]
...
> Installing...
> make: *** No rule to make target `install'.  Stop.
> WARNING: Installation failed, sorry. Please check above error messages.
> (Thu Jul 25 11:18:53 2013) Command finished (10 sec)

Fixed in r57277 (G7) and r57278 (G6),

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

On Wed, Jul 24, 2013 at 12:13 AM, Luca Delucchi  wrote:
> On 23 July 2013 12:30, Hamish  wrote:
>> Markus Neteler wrote:
 Today could be a great rlease-6.4.3-day :)
>>
>> since on the 24th we are +2 weeks since RC4 without any major bugs being
>> reported I think we are ok to release any time now. I don't know about
>> anyone else but I can't say I've really tested rc4 very much beyond
>> making sure the debian package building still works. too busy :-/
>>
>>
>> Luca:
>>> we are so close to 30 July that we could wait a week and release
>>> in the same day of his born :-)

ok.
however, we need to internally release before to get the
binaries ready (a strategy adopted since some releases).

>> It would be a nice little something for the release announcement too. :)
...
> please Hamish start it you could use some pad

He did in SVN.

>> Also MarkusN's "visual changelog" idea is nice, the trac news items for
>> the earlier RCs should give some ideas. anyone like to start on

I have merged all RC news into the final (draft) announcement.
Please check in trac.

>> screenshots for that?

Yes, please provide some catchy screenshots!

>> maybe host/compose in the more thumbnail-
>> friendly/prettier grass mediawiki?

Not surwe what that means? Please explain...

> markus we could also create a video like this
> http://www.youtube.com/watch?feature=player_embedded&v=suyDqmGXoWk

Done. I have recalculated the entire thing with camera tracking and
more It is a 11GB MP$ file, 10min duration. It looks pretty nice. I
have uploaded it to youtube, yet hidden, though.
Audio (free music) would be great but I have no competence/time to add that.

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

[GRASS-dev] Significant Community Sprint donation by FOSSGIS, de e.V.