Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library

[Anna Petrášová]

On Thu, Nov 20, 2014 at 9:55 PM, GRASS GIS  wrote:

> #2496: r.random.surface error from RAN C library
>
> --+-
>  Reporter:  cmbarton  |   Owner:  grass-dev@…
>  Type:  defect|  Status:  new
>  Priority:  normal|   Milestone:  7.0.0
> Component:  Raster| Version:  svn-trunk
>  Keywords:  r.random.surface  |Platform:  MacOSX
>   Cpu:  Unspecified   |
>
> --+-
>
> Comment(by cmbarton):
>
>  Unfortunately, no one here is a C programmer. We do Python, Java, and
>  other things. But not C.  :-(
>
>  Otherwise we might have figured it out and fixed it already.
>
>  Michael
>

Well, Python and Java are C-based languages:
http://en.wikipedia.org/wiki/List_of_C-based_programming_languages

I am merely trying to suggest that since you know what is wrong and how to
fix it, it probably won't be a big problem for anyone in your group who is
able to program in any language and able to compile grass. Of course, some
other grass developer could fix it faster, but from my experience, it's
better to try to fix things on your own if you need them to be fixed soon
enough, especially if the bug is not bothering other developers at that
time.



>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> 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] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by cmbarton):

 Unfortunately, no one here is a C programmer. We do Python, Java, and
 other things. But not C.  :-(

 Otherwise we might have figured it out and fixed it already.

 Michael

-- 
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] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Replying to [comment:4 cmbarton]:
 > If this is an easy fix, can someone let us know when it gets fixed? We
 need this for landscape modeling experiments we are trying to run.
 >

 It would be most welcome if somebody from your group would submit a patch
 which can be reviewed and eventually submitted.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] planning grass 7.0.0beta4

[Vaclav Petras]

On Thu, Nov 20, 2014 at 5:40 PM, Sören Gebbert  wrote:

> since most of
> them are tested using the test suite.
>

There are three tests failing. One of them is slightly mystified by strange
r3.univar output (none in fact). The other is shell script.

http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-11-20-08-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.to.rast3/test_strds_to_rast3/index.html
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-11-20-08-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.algebra/test_raster_algebra_granularity/index.html
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-11-20-08-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.accumulate/test.t.rast.accumulate/index.html

But anyway, temporal framework is probably the most (automatic) test
covered part of GRASS.

I'm still not sure about the backport. I was not able to work on some
things such as Python 2.6 support yet. Perhaps target for RC1 rather than
beta4?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] planning grass 7.0.0beta4

[Sören Gebbert]

2014-11-20 23:18 GMT+01:00 Markus Neteler :
> Hi,
>
> On Fri, Nov 14, 2014 at 4:31 PM, Markus Neteler  wrote:
>> Hi all,
>>
>> http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
>>
>> the only (?) remaining outstanding missing backport is the temporal 
>> framework...
>> What do you plan, Soeren?

Oh, uh, no, i missed that. So the testsuite has been backported as well?

>
> for the time being I have updated the temporal manual with a selective
> sync to trunk in r62842.
>
> Probably that's it for beta4? Time flies..

I will start backporting tomorrow, probably all changes, since most of
them are tested using the test suite.

Best regards
Soeren

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

Re: [GRASS-dev] planning grass 7.0.0beta4

[Markus Neteler]

Hi,

On Fri, Nov 14, 2014 at 4:31 PM, Markus Neteler  wrote:
> Hi all,
>
> http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
>
> the only (?) remaining outstanding missing backport is the temporal 
> framework...
> What do you plan, Soeren?

for the time being I have updated the temporal manual with a selective
sync to trunk in r62842.

Probably that's it for beta4? Time flies..

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

Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by cmbarton):

 If this is an easy fix, can someone let us know when it gets fixed? We
 need this for landscape modeling experiments we are trying to run.

 thanks
 Michael

-- 
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] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 That appears to be a conversion of
 [http://burro.astr.cwru.edu/Academics/Astr327/HW/HW2/ran1.f this Fortran
 function].

 That's supposed to generate uniform random numbers in the [0,1) interval,
 and so can be replaced by G_drand48().

-- 
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-user] wxGUI raster digitizer available

[Anna Petrášová]

On Thu, Nov 20, 2014 at 3:03 PM, Paulo van Breugel 
wrote:

> While trying to replicate the steps, I found out it worked this time.
> Difference was that last time I edited a very large map so the process got
> probably stuck. Sorry for the false alarm. And again, a great new feature!!
>

Just let me know if it happens again, it will probably take some time until
we find and fix the bugs.

>
> On Thu, Nov 20, 2014 at 7:31 PM, Anna Petrášová 
> wrote:
>
>>
>>
>> On Thu, Nov 20, 2014 at 4:37 AM, Paulo van Breugel <
>> p.vanbreu...@gmail.com> wrote:
>>
>>> Hi Anna
>>>
>>> This is great, thanks! This is going to be a real time saver.
>>>
>>> I am having trouble however running it. I seems to work fine except that
>>> I can't save the edits. To leave the editing session, I have to select no
>>> when asked to save the work.
>>>
>>> Not sure if the below helps, but in the terminal I get the message:
>>> GRASS_INFO_ERROR(30864,1): Raster map 
>>> not found
>>> GRASS_INFO_END(30864,1)
>>>
>>> From the command console:
>>>
>>> Exception in thread Thread-8:
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/threading.py", line 810, in
>>> __bootstrap_inner
>>> self.run()
>>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
>>> hread.py", line 94, in run
>>> ret = vars()['callable'](*args, **kwds)
>>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
>>> controller.py", line 467, in _exportRaster
>>> output=self._editedRaster, overwrite=True, quiet=True)
>>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>>> ipt/core.py", line 373, in run_command
>>> return handle_errors(returncode, returncode, args,
>>> kwargs)
>>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>>> ipt/core.py", line 308, in handle_errors
>>> returncode=returncode)
>>> CalledModuleError: Module run None ['r.patch', '--o', '--q',
>>> u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
>>> u'output=pnv_malawi2_ag2@vegetation'] ended with error
>>> Process ended with non-zero return code 1. See errors in the
>>> (error) output.
>>>
>>
>> Strange, could you describe the exact steps?
>>
>>
>>
>>>
>>>
>>>
>>> On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová 
>>> wrote:
>>>


 On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler 
 wrote:

> Hi Anna,
>
> On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová 
> wrote:
> > Hi all,
> >
> > I added raster digitizer in r62792 in trunk.
>
> what a great job!
>
> If you didn't find it: it is in the "Map Display" windows, then
> selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
>

 Once everything works, I will probably make a short video tutorial.

>
> > You are welcome to test it and
> > report bugs/enhancements.
> > It currently allows to draw areas, lines and points and specify
> width to
> > buffer individual features. We can discuss some changes in gui
> interface and
> > behavior if you find the current one intuitive.  There is still a
> lot to
> > improve especially in the drawing part (needs some refactoring of
> the old
> > drawing code).
>
> One general thing I found (also valid for the vector digitizer): I
> wonder where to put a message what the mouse buttons mean.
> Maybe in the status bar at bottom of the display/digitizer window?
>
> > Features:
> > - draw area, line, point
>
> ... works.
>
> > - specify buffer width for individual features to create for example
> > circles, roads of certain width...
>
> ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
> confused with the drawing line width.
>

 There is not much space in toolbar..., especially if we in the future
 add more items (settings, label editing for example). What about just
 'Buffer'? Currently the width is the width of the buffered line/diameter of
 the point (circle), which means 2 x buffer distance, so if we change it to
 buffer, then the value should be half of the line width?

>
> > - specify background map
>
> ... works (maybe have a button to optionally take computational region
> from that map?)
>

 Yes possibly, I am not sure about the region in general, if there
 should be any special handling.

>
> > - simple undo
> > - save button to save results during drawing
>
> here I got an issue somewhere:
>
> Exception in thread Thread-4:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/threading.py", line 811, in
> __bootstrap_inner
> self.run()
>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
> linux-gnu/gui/wxpython/core/gthread.py", line 94, in run
> ret = vars()['callable'](*args, **kwds)
>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
> l

Re: [GRASS-dev] [GRASS-user] wxGUI raster digitizer available

[Paulo van Breugel]

While trying to replicate the steps, I found out it worked this time.
Difference was that last time I edited a very large map so the process got
probably stuck. Sorry for the false alarm. And again, a great new feature!!

On Thu, Nov 20, 2014 at 7:31 PM, Anna Petrášová 
wrote:

>
>
> On Thu, Nov 20, 2014 at 4:37 AM, Paulo van Breugel  > wrote:
>
>> Hi Anna
>>
>> This is great, thanks! This is going to be a real time saver.
>>
>> I am having trouble however running it. I seems to work fine except that
>> I can't save the edits. To leave the editing session, I have to select no
>> when asked to save the work.
>>
>> Not sure if the below helps, but in the terminal I get the message:
>> GRASS_INFO_ERROR(30864,1): Raster map 
>> not found
>> GRASS_INFO_END(30864,1)
>>
>> From the command console:
>>
>> Exception in thread Thread-8:
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/threading.py", line 810, in
>> __bootstrap_inner
>> self.run()
>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
>> hread.py", line 94, in run
>> ret = vars()['callable'](*args, **kwds)
>>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
>> controller.py", line 467, in _exportRaster
>> output=self._editedRaster, overwrite=True, quiet=True)
>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>> ipt/core.py", line 373, in run_command
>> return handle_errors(returncode, returncode, args,
>> kwargs)
>>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
>> ipt/core.py", line 308, in handle_errors
>> returncode=returncode)
>> CalledModuleError: Module run None ['r.patch', '--o', '--q',
>> u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
>> u'output=pnv_malawi2_ag2@vegetation'] ended with error
>> Process ended with non-zero return code 1. See errors in the
>> (error) output.
>>
>
> Strange, could you describe the exact steps?
>
>
>
>>
>>
>>
>> On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová 
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler 
>>> wrote:
>>>
 Hi Anna,

 On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová 
 wrote:
 > Hi all,
 >
 > I added raster digitizer in r62792 in trunk.

 what a great job!

 If you didn't find it: it is in the "Map Display" windows, then
 selector on the right side (2D/3D/Vector digitizer/Raster digitizer).

>>>
>>> Once everything works, I will probably make a short video tutorial.
>>>

 > You are welcome to test it and
 > report bugs/enhancements.
 > It currently allows to draw areas, lines and points and specify width
 to
 > buffer individual features. We can discuss some changes in gui
 interface and
 > behavior if you find the current one intuitive.  There is still a lot
 to
 > improve especially in the drawing part (needs some refactoring of the
 old
 > drawing code).

 One general thing I found (also valid for the vector digitizer): I
 wonder where to put a message what the mouse buttons mean.
 Maybe in the status bar at bottom of the display/digitizer window?

 > Features:
 > - draw area, line, point

 ... works.

 > - specify buffer width for individual features to create for example
 > circles, roads of certain width...

 ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
 confused with the drawing line width.

>>>
>>> There is not much space in toolbar..., especially if we in the future
>>> add more items (settings, label editing for example). What about just
>>> 'Buffer'? Currently the width is the width of the buffered line/diameter of
>>> the point (circle), which means 2 x buffer distance, so if we change it to
>>> buffer, then the value should be half of the line width?
>>>

 > - specify background map

 ... works (maybe have a button to optionally take computational region
 from that map?)

>>>
>>> Yes possibly, I am not sure about the region in general, if there should
>>> be any special handling.
>>>

 > - simple undo
 > - save button to save results during drawing

 here I got an issue somewhere:

 Exception in thread Thread-4:
 Traceback (most recent call last):
   File "/usr/lib64/python2.7/threading.py", line 811, in
 __bootstrap_inner
 self.run()
   File "/home/neteler/software/grass71/dist.x86_64-unknown-
 linux-gnu/gui/wxpython/core/gthread.py", line 94, in run
 ret = vars()['callable'](*args, **kwds)
   File "/home/neteler/software/grass71/dist.x86_64-unknown-
 linux-gnu/gui/wxpython/rdigit/controller.py", line 432, in
 _exportRaster
 if item.GetPropertyVal('widthValue') and \
   File "/home/neteler/software/grass71/dist.x86_64-unknown-
 linux-gnu/gui/wxpython/mapwin/graphics.py", line 439, in
 GetPropertyVal
 raise KeyError(_("Property does not exist: %s") %
 

Re: [GRASS-dev] [GRASS-user] wxGUI raster digitizer available

[Anna Petrášová]

On Thu, Nov 20, 2014 at 4:37 AM, Paulo van Breugel 
wrote:

> Hi Anna
>
> This is great, thanks! This is going to be a real time saver.
>
> I am having trouble however running it. I seems to work fine except that I
> can't save the edits. To leave the editing session, I have to select no
> when asked to save the work.
>
> Not sure if the below helps, but in the terminal I get the message:
> GRASS_INFO_ERROR(30864,1): Raster map 
> not found
> GRASS_INFO_END(30864,1)
>
> From the command console:
>
> Exception in thread Thread-8:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/threading.py", line 810, in
> __bootstrap_inner
> self.run()
>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
> hread.py", line 94, in run
> ret = vars()['callable'](*args, **kwds)
>   File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
> controller.py", line 467, in _exportRaster
> output=self._editedRaster, overwrite=True, quiet=True)
>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
> ipt/core.py", line 373, in run_command
> return handle_errors(returncode, returncode, args,
> kwargs)
>   File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
> ipt/core.py", line 308, in handle_errors
> returncode=returncode)
> CalledModuleError: Module run None ['r.patch', '--o', '--q',
> u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
> u'output=pnv_malawi2_ag2@vegetation'] ended with error
> Process ended with non-zero return code 1. See errors in the
> (error) output.
>

Strange, could you describe the exact steps?



>
>
>
> On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová 
> wrote:
>
>>
>>
>> On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler 
>> wrote:
>>
>>> Hi Anna,
>>>
>>> On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová 
>>> wrote:
>>> > Hi all,
>>> >
>>> > I added raster digitizer in r62792 in trunk.
>>>
>>> what a great job!
>>>
>>> If you didn't find it: it is in the "Map Display" windows, then
>>> selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
>>>
>>
>> Once everything works, I will probably make a short video tutorial.
>>
>>>
>>> > You are welcome to test it and
>>> > report bugs/enhancements.
>>> > It currently allows to draw areas, lines and points and specify width
>>> to
>>> > buffer individual features. We can discuss some changes in gui
>>> interface and
>>> > behavior if you find the current one intuitive.  There is still a lot
>>> to
>>> > improve especially in the drawing part (needs some refactoring of the
>>> old
>>> > drawing code).
>>>
>>> One general thing I found (also valid for the vector digitizer): I
>>> wonder where to put a message what the mouse buttons mean.
>>> Maybe in the status bar at bottom of the display/digitizer window?
>>>
>>> > Features:
>>> > - draw area, line, point
>>>
>>> ... works.
>>>
>>> > - specify buffer width for individual features to create for example
>>> > circles, roads of certain width...
>>>
>>> ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
>>> confused with the drawing line width.
>>>
>>
>> There is not much space in toolbar..., especially if we in the future add
>> more items (settings, label editing for example). What about just 'Buffer'?
>> Currently the width is the width of the buffered line/diameter of the point
>> (circle), which means 2 x buffer distance, so if we change it to buffer,
>> then the value should be half of the line width?
>>
>>>
>>> > - specify background map
>>>
>>> ... works (maybe have a button to optionally take computational region
>>> from that map?)
>>>
>>
>> Yes possibly, I am not sure about the region in general, if there should
>> be any special handling.
>>
>>>
>>> > - simple undo
>>> > - save button to save results during drawing
>>>
>>> here I got an issue somewhere:
>>>
>>> Exception in thread Thread-4:
>>> Traceback (most recent call last):
>>>   File "/usr/lib64/python2.7/threading.py", line 811, in
>>> __bootstrap_inner
>>> self.run()
>>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>>> linux-gnu/gui/wxpython/core/gthread.py", line 94, in run
>>> ret = vars()['callable'](*args, **kwds)
>>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>>> linux-gnu/gui/wxpython/rdigit/controller.py", line 432, in
>>> _exportRaster
>>> if item.GetPropertyVal('widthValue') and \
>>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>>> linux-gnu/gui/wxpython/mapwin/graphics.py", line 439, in
>>> GetPropertyVal
>>> raise KeyError(_("Property does not exist: %s") %
>>> (propName))
>>> KeyError: 'Property does not exist: widthValue'
>>>
>>>
>>>
>> it normally works... Does this happen every time?
>>
>>
>>> > - keeps drawing order in the output raster map
>>> > - change color of drawing
>>> > - doesn't block gui when exporting raster (which can take some time)
>>>
>>> Nice!
>>>
>>> > Does not support (yet?):
>>> > - adding labels
>>> > - interactive setting color of raster cells (not planned

Re: [GRASS-dev] Issues installing GRASS 7.0 from Ubuntu PPA

[Markus Neteler]

On Thu, Nov 20, 2014 at 5:37 PM, Isaac Ullah  wrote:
> So my current options
> are to roll back to an earlier version, compile the current version from
> source,

Yes, this is the most efficient ways I suppose, see:

http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu

Should be doable in < 10 min :-)

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

Re: [GRASS-dev] Issues installing GRASS 7.0 from Ubuntu PPA

[Isaac Ullah]

Vaclav,

   Thank you for your response, it is very helpful! So, the upshot is that
the current version packaged for Ubuntu in the PPA has the broken
g.version, which somehow prevents the GUI from rendering. This is just in
the PPA version, but the compiled version *should* be fine. So my current
options are to roll back to an earlier version, compile the current version
from source, or to run GRASS headless for the moment (no issue for me)
until the problem is fixed (I assume at least by when 7.0 stable is
released?).

Also, thanks for letting me know about g.mremove. I didn't know about that!
I am currently porting some of my addon modules to 7, so I will change
their map clean up routines to use the new functionality of g.remove. Goes
to show that I ought to pay more attention to the roadmap!

~Isaac

On Wed, Nov 19, 2014 at 7:52 PM, Vaclav Petras  wrote:

>
>
> On Wed, Nov 19, 2014 at 7:36 PM, Isaac Ullah  wrote:
>
>> Sorry, premature send! Here's the error message:
>>
>> Launching  GUI in the background, please wait...
>> [Raster MASK present]
>> GRASS 7.0.0 (Exp3):~ > Traceback (most recent call last):
>>   File "/usr/lib/grass70/gui/wxpython/wxgui.py", line 140, in 
>> sys.exit(main())
>>   File "/usr/lib/grass70/gui/wxpython/wxgui.py", line 133, in main
>> app = GMApp(workspaceFile)
>>   File "/usr/lib/grass70/gui/wxpython/wxgui.py", line 48, in __init__
>> wx.App.__init__(self, False)
>>   File
>> "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line
>> 7981, in __init__
>> self._BootstrapApp()
>>   File
>> "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line
>> 7555, in _BootstrapApp
>> return _core_.PyApp__BootstrapApp(*args, **kwargs)
>>   File "/usr/lib/grass70/gui/wxpython/wxgui.py", line 82, in OnInit
>> workspace = self.workspaceFile)
>>   File "/usr/lib/grass70/gui/wxpython/lmgr/frame.py", line 93, in __init__
>> grassVersion = grass.version()['version']
>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 1467, in
>> version
>> data = parse_command('g.version', flags='rge')
>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 465, in
>> parse_command
>> res = read_command(*args, **kwargs)
>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 425, in
>> read_command
>> return handle_errors(returncode, stdout, args, kwargs)
>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 308, in
>> handle_errors
>> returncode=returncode)
>> grass.exceptions.CalledModuleError: Module run None ['g.version', '-rge']
>> ended with error
>> Process ended with non-zero return code -11. See errors in the (error)
>> output.
>>
>>
> This relates to problems with g.version (#2351) and new, more strict error
> handling (#2326). I tried to fix g.version in r61589 but I'm not sure if I
> was successful, now it seems that I was not. I'm also not sure what r62747
> changed in g.version checks. (Note: Both changes are backported to release
> branch 7.0.)
>
> At least the error handling now gives us the idea about what's happening.
> -11 means segmentation fault on Ubuntu AFAIK, so it is really related to
> #2351.
>
> I changed the error handling to "ignore" in r62822 (and backported). It
> reintroduces the original behavior before #2326. Although it might be
> appropriate in this case, the better solution would be to fix g.version as
> r61589 was trying to do.
>
> https://trac.osgeo.org/grass/ticket/2351
> https://trac.osgeo.org/grass/ticket/2326
> https://trac.osgeo.org/grass/changeset/61589 (
> https://trac.osgeo.org/grass/changeset/61683)
> https://trac.osgeo.org/grass/changeset/62747 (
> https://trac.osgeo.org/grass/changeset/62748)
> https://trac.osgeo.org/grass/changeset/62822 (
> https://trac.osgeo.org/grass/changeset/62823)
>
>
>> I still have a GRASS session in the terminal, and can run some grass
>> commands, but not others. For example, "g.region -p" is fine, but
>> "g.mremove" give the following error:
>>
>> g.mremove: command not found
>>
>> Note that g.mremove was recently replaced g.remove. See Trac wiki for
> details:
>
> https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Renamedmodules
>
>
>> The strange thing is that about a month ago, I was able to install a
>> perfectly working version of GRASS7 on a similar computer with no issues
>> (other than the apparently ineffectual error with g.version). I've tried
>> this on three separate computers, and all have the same problem. I've tried
>> installing all the dev packages I could think of (for example, all wx
>> python dev libraries), but nothing seems to help.
>>
>> Any ideas what's going on? What can I do?
>>
>> There is something strange happening with packaging, the self-compiled
> version does not suffer from g.version issues.
>
> Vaclav
>
> ~Isaac
>>
>> On Wed, Nov 19, 2014 at 5:30 PM, Isaac Ullah  wrote:
>>
>>> Hi all,
>>>
>>>I've been trying to get GRASS7 installed on several machines running
>>> Xubunt

Re: [GRASS-dev] [GRASS GIS] #2497: Incompatile PostGIS Topology export

[GRASS GIS]

#2497: Incompatile PostGIS Topology export
-+--
 Reporter:  strk |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by strk):

 I've found that ST_GetFaceGeometry only returns a NULL value for faces
 with a negative id (which would make sense, assuming no edge would ever
 point to them as being on its right or left side.

 Should these negative faces be put in a grass-specific table rather than
 polluting the ISO one ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.out.postgis -l running for hours

[Sandro Santilli]

On Thu, Nov 20, 2014 at 10:47:13AM +0100, Sandro Santilli wrote:

> The "0 topogeoms" part of the summary reveals a bug somewhere.

I've found other issues with the exported topology, filed in a ticket:
https://trac.osgeo.org/grass/ticket/2497

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

[GRASS-dev] [GRASS GIS] #2497: Incompatile PostGIS Topology export

[GRASS GIS]

#2497: Incompatile PostGIS Topology export
-+--
 Reporter:  strk |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 I've tried exporting topology to PostGIS with v.out.postgis -l and the
 result was not correct.

 First there was no record in TOPOSCHEMA.relation so that all the literal
 TopoGeometry values (written in the output feature layer) result empty.

 Second all the calls to ST_GetFaceGeometry() return a null value, which
 I've yet to inspect/understand. All I noticed so far was that there were
 many negative face_id, which don't really have any special meaning in
 PostGIS/ISO (there's no difference between an area or an island, you only
 have faces, with roles being dependent on the upper abstraction level of
 the TopoGeometry).

 Unfortunately, topology.ValidateTopology doesn't notice any of these
 problems (this would be a PostGIS bug).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.out.postgis -l running for hours

[Sandro Santilli]

On Thu, Nov 20, 2014 at 10:47:13AM +0100, Sandro Santilli wrote:

> This other dataset took 20 minutes to import/build, and took 85 minutes
> to export to PostGIS (4 times more expensive to export).

ERRATA CORRIGE:

It took _2_ minutes to import/build (from shapefile)
and 85 to export to PostGIS

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

Re: [GRASS-dev] How to calculate log() in v.db.update with SQLite backend?

[Markus Neteler]

Congrats, Moritz.

On Thu, Nov 20, 2014 at 9:22 AM, Moritz Lennert
 wrote:
> Below is a proposal after a very superficial reading of the docs and code,
> so no guarantees (and I cannot really test here since it seems enabled by
> default).
>
> However, this means that we enable this automatically for each sqlite db
> opened by GRASS...

Maybe an issue, maybe not. The sqlite3 cmd line software has it enabled, too.


> Index: db/drivers/sqlite/db.c
> ===
> --- db/drivers/sqlite/db.c  (révision 62792)
> +++ db/drivers/sqlite/db.c  (copie de travail)
> @@ -110,6 +110,9 @@
> return DB_FAILED;
>  }
>
> +/* enable loading of extensions */
> +sqlite3_enable_load_extension(sqlite, 1);
> +
>  /* set the sqlite busy handler */
>  sqlite3_busy_handler(sqlite, sqlite_busy_callback, NULL);

Trying with my locally modified  v.db.update

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.copy
vect=precip_30ynormals,myprecip_30ynormals

GRASS 7.1.svn (nc_spm_08_grass7):~ > v.db.addcolumn
myprecip_30ynormals column="logjuly double precision"

GRASS 7.1.svn (nc_spm_08_grass7):~ > v.db.update myprecip_30ynormals
column="logjuly" qcolumn="log(jul)"
sqliteextra=/home/neteler/software/sqlite_extensions/libsqlitefunctions.so

GRASS 7.1.svn (nc_spm_08_grass7):~ > v.db.select myprecip_30ynormals
columns=jul,logjuly
jul|logjuly
132.842|4.88916045210132
127|4.84418708645859
124.206|4.82194147751127
104.648|4.65060233738593
98.298|4.58800368106618
...

Works.

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

[GRASS-dev] v.out.postgis -l running for hours

[Sandro Santilli]

I'm forwarding this mail from -user as it didn't get attention there
yesterday. Today I've tried again a v.out.postgis -l, this time
with a different (bigger) dataset.

This other dataset took 20 minutes to import/build, and took 85 minutes
to export to PostGIS (4 times more expensive to export).

 v.out.postgis complete. 224655 primitives written to .
 real85m16.237s
 user2m48.962s
 sys 1m19.671s

Is the export doing anything else than INSERT calls ?
I've seen some UPDATE calls against edges (which could maybe be avoided,
same problem in PostGIS itself: http://trac.osgeo.org/postgis/ticket/2993;
but I hadn't noticed if GRASS is also calling SELECT against the ISO
topology functions.

The input GRASS map:

 nodes=107553
 points=0
 lines=0
 boundaries=158084
 centroids=66571
 areas=66577
 islands=16046
 primitives=224655
 map3d=0

The created PostGIS topology:

 Topology topo_grass_ulfareale (5), SRID 0, precision 0   
 174124 nodes, 158084 edges, 82623 faces, 0 topogeoms, 1 layers
 Layer 1, type Polygonal (3), 0 topogeoms 
  Deploy: public.grass_ulfareale.topo 

The "0 topogeoms" part of the summary reveals a bug somewhere.
It means TopoGeometry objects were not registered in the relation
table. How are them created ? I see literal TopoGeometry objects
present in the public.grass_ulfareale.topo table, but those
numbers have no meaning on themselves w/out corresponding entries
in topo_grass_ulfareale.relation.

--strk;

- Forwarded message from Sandro Santilli  -

Date: Wed, 19 Nov 2014 00:17:33 +0100
From: Sandro Santilli 
To: grass-u...@lists.osgeo.org
Cc: landa.mar...@gmail.com
Subject: v.out.postgis -l running for hours
User-Agent: Mutt/1.5.21 (2010-09-15)
Bcc: sandro.santi...@gmail.com

I've imported a ~1 million small polygons dataset from PostGIS into
GRASS with v.in.ogr, which tool less than 30 minutes and was now
trying to export it into the PostGIS Topology model with v.out.postgis -l.

Unexpectedly this latter step is beeing running for hours and did not
even complete the first part:

GRASS 7.0.0beta3 (world):/usr/src/grass/grass-7.0.0beta3 > time \
v.out.postgis -l input=million_poly_topo1 \
olayer=grass_million_poly_topo1 dsn="PG:dbname=strk" \
olink=pg_million_poly_topo1
Copying features...
  35%

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
15997 strk  20   0 4928752 2.069g 1.578g R  98.5 13.3 280:28.46 postgres: 
strk strk [local] UPDATE
15994 strk  20   0 2796056 2.506g   7432 S   1.6 16.1  10:07.11 
v.out.postgis -l input=million_poly_topo1 olayer=grass_million_poly_topo1 dsn+

On the PostgreSQL side there's no data load visible:

 strk=# select count(*) from grass_million_poly_topo1;
  count
 ---
  0
 (1 row)

 strk=# select topologysummary('topo_grass_million_poly_topo1');
   topologysummary
 
  Topology topo_grass_million_poly_topo1 (2405), SRID 0, precision 0+
  0 nodes, 0 edges, 0 faces, 0 topogeoms, 1 layers  +
  Layer 1, type Polygonal (3), 0 topogeoms  +
   Deploy: public.grass_million_poly_topo1.topo +
 
 (1 row)

I guess things are being done in a transaction ?

>From the output table structure it looks like v.out.postgis is also
trying to export simple features (the "geom" field):

 strk=# \d grass_million_poly_topo1
Table "public.grass_million_poly_topo1"
  Column |   Type|   Modifiers
 
+---+
  fid| integer   | not null default 
nextval('grass_million_poly_topo1_fid_seq'::regclass)
  cat| integer   |
  value  | integer   |
  geom   | geometry(Polygon) |
  topo   | topogeometry  |
 Indexes:
 "grass_million_poly_topo1_pkey" PRIMARY KEY, btree (fid)
 "grass_million_poly_topo1_cat_idx" btree (cat)
 "grass_million_poly_topo1_geom_idx" gist (geom)
 "public_grass_million_poly_topo1_topo_idx" btree (((topo).id))
 Check constraints:
 "check_topogeom_topo" CHECK ((topo).topology_id = 2405 AND (topo).layer_id 
= 1 AND (topo).type = 3)

Could that be the cause of the slowness ? Is there a way to disable
conversion to simple-feature, which is already supported by
PostGIS Topology itself ?

Thanks in advance.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html

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

Re: [GRASS-dev] [GRASS-user] wxGUI raster digitizer available

[Paulo van Breugel]

Hi Anna

This is great, thanks! This is going to be a real time saver.

I am having trouble however running it. I seems to work fine except that I
can't save the edits. To leave the editing session, I have to select no
when asked to save the work.

Not sure if the below helps, but in the terminal I get the message:
GRASS_INFO_ERROR(30864,1): Raster map 
not found
GRASS_INFO_END(30864,1)

>From the command console:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in
__bootstrap_inner
self.run()
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/core/gt
hread.py", line 94, in run
ret = vars()['callable'](*args, **kwds)
  File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/rdigit/
controller.py", line 467, in _exportRaster
output=self._editedRaster, overwrite=True, quiet=True)
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py", line 373, in run_command
return handle_errors(returncode, returncode, args,
kwargs)
  File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py", line 308, in handle_errors
returncode=returncode)
CalledModuleError: Module run None ['r.patch', '--o', '--q',
u'input=x47731795,pnv_malawi2_ag2_backupcopy_30725',
u'output=pnv_malawi2_ag2@vegetation'] ended with error
Process ended with non-zero return code 1. See errors in the
(error) output.



On Wed, Nov 19, 2014 at 11:56 PM, Anna Petrášová 
wrote:

>
>
> On Wed, Nov 19, 2014 at 3:31 PM, Markus Neteler  wrote:
>
>> Hi Anna,
>>
>> On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová 
>> wrote:
>> > Hi all,
>> >
>> > I added raster digitizer in r62792 in trunk.
>>
>> what a great job!
>>
>> If you didn't find it: it is in the "Map Display" windows, then
>> selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
>>
>
> Once everything works, I will probably make a short video tutorial.
>
>>
>> > You are welcome to test it and
>> > report bugs/enhancements.
>> > It currently allows to draw areas, lines and points and specify width to
>> > buffer individual features. We can discuss some changes in gui
>> interface and
>> > behavior if you find the current one intuitive.  There is still a lot to
>> > improve especially in the drawing part (needs some refactoring of the
>> old
>> > drawing code).
>>
>> One general thing I found (also valid for the vector digitizer): I
>> wonder where to put a message what the mouse buttons mean.
>> Maybe in the status bar at bottom of the display/digitizer window?
>>
>> > Features:
>> > - draw area, line, point
>>
>> ... works.
>>
>> > - specify buffer width for individual features to create for example
>> > circles, roads of certain width...
>>
>> ... maybe rename from "Width" to "Buffer width"? Otherwise it could be
>> confused with the drawing line width.
>>
>
> There is not much space in toolbar..., especially if we in the future add
> more items (settings, label editing for example). What about just 'Buffer'?
> Currently the width is the width of the buffered line/diameter of the point
> (circle), which means 2 x buffer distance, so if we change it to buffer,
> then the value should be half of the line width?
>
>>
>> > - specify background map
>>
>> ... works (maybe have a button to optionally take computational region
>> from that map?)
>>
>
> Yes possibly, I am not sure about the region in general, if there should
> be any special handling.
>
>>
>> > - simple undo
>> > - save button to save results during drawing
>>
>> here I got an issue somewhere:
>>
>> Exception in thread Thread-4:
>> Traceback (most recent call last):
>>   File "/usr/lib64/python2.7/threading.py", line 811, in
>> __bootstrap_inner
>> self.run()
>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>> linux-gnu/gui/wxpython/core/gthread.py", line 94, in run
>> ret = vars()['callable'](*args, **kwds)
>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>> linux-gnu/gui/wxpython/rdigit/controller.py", line 432, in
>> _exportRaster
>> if item.GetPropertyVal('widthValue') and \
>>   File "/home/neteler/software/grass71/dist.x86_64-unknown-
>> linux-gnu/gui/wxpython/mapwin/graphics.py", line 439, in
>> GetPropertyVal
>> raise KeyError(_("Property does not exist: %s") %
>> (propName))
>> KeyError: 'Property does not exist: widthValue'
>>
>>
>>
> it normally works... Does this happen every time?
>
>
>> > - keeps drawing order in the output raster map
>> > - change color of drawing
>> > - doesn't block gui when exporting raster (which can take some time)
>>
>> Nice!
>>
>> > Does not support (yet?):
>> > - adding labels
>> > - interactive setting color of raster cells (not planned, there are
>> other tools)
>> > - vector export/import
>> >
>> > Known issues:
>> > - r.in.poly supports only CELL (I just realized that, this must be
>> changed)
>>
>> (meanwhile you changed that already, thanks)
>>
>> > - various small drawing issues
>> > - slow when exporting features with buffers

Re: [GRASS-dev] G7: v.mkhexgrid addon for hexagon creation

[Markus Neteler]

On Thu, Nov 20, 2014 at 9:52 AM, Markus Metz
 wrote:
...
> The points are not "cleverly spaced". Attached is a python script that
> generates center points of hexagons. The output of v.voronoi shows now
> hexagons.

Cool! Do you have a reference for ""cleverly spaced"? Just came across
http://en.wikipedia.org/wiki/Hexagonal_lattice
http://en.wikipedia.org/wiki/Hexagonal_tiling

Overall, this point generator might be a nice extension to v.mkgrid.

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

Re: [GRASS-dev] Fwd: FOSDEM 2015

[Moritz Lennert]

On 17/11/14 15:45, Moritz Lennert wrote:

Hello,

As you can see below, Margherita contacted me concerning a GRASS
presentation at the geospatial devromm foreseen for the first time at
the upcoming FOSDEM.

I can present something, but would like to know

1) if other devs are planning to attend and if yes, if they were
planning to present anything
2) which themes you think would be the most interesting to present from
a GRASS perspective

Currently, I've been thinking about two themes:

- The obvious "what's new in GRASS 7", but I'm not sure that this is the
most appropriate for the mostly developper crowd present at a FOSDEM.

- A focus on the different APIs in GRASS from C to pygrass to
grass.script, explaining structure and use cases of each.

Any other ideas ?


I guess I can I conclude from the lack of reactions that no other devs 
are coming to the FOSSDEM 2015... ?


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

Re: [GRASS-dev] G7: v.mkhexgrid addon for hexagon creation

[Markus Metz]

On Thu, Nov 20, 2014 at 12:29 AM, Markus Neteler  wrote:
> Hi,
>
> I have added v.mkhexgrid as new G7 addon to the Addons repo. The
> original author is Trevor Wiens who already implemented it as a Python
> script. I made some minor changes to get it running in GRASS GIS 7.
> Screenshot:
> https://svn.osgeo.org/grass/grass-addons/grass7/vector/v.mkhexgrid/v_mkhexgrid.png
>
> Originally I had hoped that v.voronoi would do the job but it does not
> create proper hexagons. I was running:
>
> # desired result:
> http://blogs.esri.com/esri/arcgis/files/2013/05/fig3.png (3rd figure
> within)
> # create first set of points
> g.region rast=elevation -p
> v.mkgrid -p map=pointpattern1 grid=13,15 position=region breaks=1
> # shift grid by half point distance
> g.region n=n+500 w=w+500 e=e+500 s=s+500 -p
> # create second set of points
> v.mkgrid -p map=pointpattern2 grid=13,15 position=region breaks=1
> # merge into final point pattern
> v.patch input=pointpattern1,pointpattern2 output=pointpattern3
> # generate Thiessen, hoping for hexagons
> v.voronoi input=pointpattern3 out=hexagon_attempt
> # show result
> d.mon wx0
> sleep 5
> d.vect hexagon_attempt type=boundary

The points are not "cleverly spaced". Attached is a python script that
generates center points of hexagons. The output of v.voronoi shows now
hexagons.

Markus M
#!/bin/env python

import os
import sys
import math


def main():
north = 1000
west = 1000
rows = 20
cols = 20

radius = 1000

# row spacing
rspace = radius / 2.0

# row shift
rshift = radius

# col spacing
cspace = math.sqrt(3) * radius
# col shift
cshift = math.sqrt(3) * radius / 2.0

f = file("points.csv", "w")

n = north
for r in range(rows):
	n = n + rspace
	w = west + cshift * (r % 2)
	for c in range(cols):
	w = w + cspace
	f.write("%f,%f\n" % (w, n))

f.close()



if __name__ == "__main__":
main()
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] How to calculate log() in v.db.update with SQLite backend?

[Moritz Lennert]

On 20/11/14 08:46, Moritz Lennert wrote:

On 19/11/14 19:12, Vaclav Petras wrote:


On Wed, Nov 19, 2014 at 12:59 PM, Markus Neteler mailto:nete...@osgeo.org>> wrote:


DBMI-SQLite driver error:
Error in sqlite3_step():
not authorized

ERROR: Error while executing: 'SELECT


load_extension('/home/neteler/software/sqlite_extensions/libsqlitefunctions.so')'

Traceback (most recent call last):
...
Process ended with non-zero return code 1. See errors in the (error)
output.

No idea what's disliked here in:

SELECT

load_extension('/home/neteler/software/sqlite_extensions/libsqlitefunctions.so');

UPDATE meuse_voronoi SET logzinc=log(zinc);

Any hints?


Loading user defined function is not considered completely safe, so it
is disabled by default. I think this is not an issue for GRASS GIS.

You have to enable it somehow. It seems that enable_load_extension() is
the way.


Right.

But this depends on the installation, i.e. how sqlite3 was compiled.
Here in Debian Testing I do not need to activate anything, so I assume
that it's activated by default.


However, I'm not sure if sqlite needs to be compiled with this option by 
default. I think we could activate it in the sqlite driver.


Below is a proposal after a very superficial reading of the docs and 
code, so no guarantees (and I cannot really test here since it seems 
enabled by default).


However, this means that we enable this automatically for each sqlite db 
opened by GRASS...


Moritz

Index: db/drivers/sqlite/db.c
===
--- db/drivers/sqlite/db.c  (révision 62792)
+++ db/drivers/sqlite/db.c  (copie de travail)
@@ -110,6 +110,9 @@
return DB_FAILED;
 }

+/* enable loading of extensions */
+sqlite3_enable_load_extension(sqlite, 1);
+
 /* set the sqlite busy handler */
 sqlite3_busy_handler(sqlite, sqlite_busy_callback, NULL);

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