Re: [GRASS-user] new map in wxgui digitizer

2016-11-18 Thread Dave Roberts 

Hi Anna,  yes I can create tickets now.  I'll do that this weekend.

Thanks, Dave

On 11/18/16 10:03, Anna Petrášová wrote:

On Fri, Nov 18, 2016 at 10:41 AM, Dave Roberts  wrote:

Friends,

  I am trying to make use of the wxgui digitizer and finding it somewhat
challenging.  One issue is that I like to run from the console (i.e. grass73
-text) and that produces a subtly different widget than if I run from the
gui (i.e. grass73 -gui).  Using the console version, when I try to digitize
a new map (as opposed to editing an existing map) I get the error below.

GRASS GIS 7.3.svn > Traceback (most recent call last):
  File "/usr/local/grass-7.3.svn/gui/wxpython/vdigit/toolbars.py", line 849,
in OnSelectMap
if self.layers[selection] == self.mapLayer:
UnboundLocalError: local variable 'selection' referenced before assignment

and it doesn't digitize any points.

The obvious short term solution is to work from the GUI, but that defeats
much oswhat I am trying to accomplish in scriptable, repeatable analyses.

GRASS GIS 7.3.svn (r69510)

Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET 2016
x86_

Thanks, Dave




That's a bug we should fix before release (if it's in 72). I don't
remember, are you able to create a ticket now?

Anna


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




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

Re: [GRASS-user] v.net.iso - segmentation fault error

2016-11-18 Thread Markus Metz 
On Fri, Nov 18, 2016 at 4:48 PM, Eduardo Corbelle Rico <
eduardo.corbe...@gmx.net> wrote:
>
>
> O Xov, 17-11-2016 ás 08:52 +0100, Markus Metz escribiu:
> >
> > On Wed, Nov 16, 2016 at 7:14 PM, Eduardo Corbelle Rico  > l...@gmx.net> wrote:
> > >
> > > O Mér, 16-11-2016 ás 15:22 +0100, Markus Metz escribiu:
> > > >
> > > > On Wed, Nov 16, 2016 at 11:44 AM, Eduardo Corbelle Rico
> >  > > > e...@gmx.net> wrote:
> > > > >
> > > > > O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu:
> > > > > > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico
> > > > > >  wrote:
> > > > > > >
> > > > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu:
> > > > > > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Dear all,
> > > > > > > > >
> > > > > > > > > I am unable to use v.net.iso because of a "segmentation
> > > > fault"
> > > > > > > > > error. I
> > > > > > > > >  have a script that used to work correctly in GRASS 6.4
> > (32
> > > > > > > > > bit)
> > > > > > > > > but
> > > > > > > > > produces this error after I switched to GRASS 7.0.4 (64
> > > > bit).
> > > > > > > > >
> > > > > > > > > If I try to follow both examples shown in https://grass
> > .osg
> > > > eo.o
> > > > > > > > > rg/g
> > > > > > > > > rass
> > > > > > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset
> > for
> > > > > > > > > GRASS 7)
> > > > > > > > > the
> > > > > > > > > same error appears:
> > > > > > > > >
> > > > > > > > > > Building graph...
> > > > > > > > > > Registering arcs...
> > > > > > > > > > Segmentation fault
> > > > > > > >
> > > > > > > > The segmentation fault must happen in the vector
> > libraries. I
> > > > > > > > tested
> > > > > > > > on Linux and can not reproduce the segmentation fault.
> > > > Valgrind
> > > > > > > > also
> > > > > > > > does not show anything that could cause a segmentation
> > fault.
> > > > Can
> > > > > > > > you
> > > > > > > > provide a gdb backtrace?
> > > > > > > >
> > > > > > > > Markus M
> > > > > > >
> > > > > > > Thank you Markus,
> > > > > > >
> > > > > > > My system is debian Stretch, and the following lines
> > describe
> > > > my
> > > > > > > attempt at generating a gdb backtrace. Please let me know
> > if I
> > > > > > > should
> > > > > > > do otherwise.
> > > > > >
> > > > > > So far so good. The module crashes in a library function that
> > > > comes
> > > > > > from libavl without modifications, but I can still not see
> > why it
> > > > > > could cause a segmentation fault. Can you recompile with the
> > > > compiler
> > > > > > debugging option -g? gdb will then be able to provide more
> > > > > > information:
> > > > > >
> > > > > > make distclean
> > > > > > CFLAGS="-g" ./configure 
> > > > > > make
> > > > > >
> > > > > > optionally make install
> > > > > >
> > > > > > Then start GRASS and use gdb for v.net.iso as before.
> > > > > >
> > > > > > Markus M
> > > > > >
> > > > >
> > > > > Dear Markus,
> > > > >
> > > > > Following those instructions does not seem to have changed the
> > > > > resulting backtrace info (copied below). Maybe I missed
> > something
> > > > along
> > > > > the way?
> > > > >
> > > > > -
> > > >
> > > >
> > > > Is this something Debian specific that debugging symbols must be
> > > > explicitly activated? Are you using GCC or another compiler?
> > > >
> > > > Alternatively, you can also try valgrind:
> > > >
> > > > CMD="v.net.iso input=myroads_net output=myroads_net_iso
> > > > center_cats=1-10 costs=1000,2000,5000 --o"
> > > > valgrind --tool=memcheck --log-file=v.net.iso.vg.log $CMD
> > > >
> > > > Markus M
> > > >
> > >
> > > You were right: it was my fault not having grass-core-dbgsym and
> > grass-
> > > dev-dbgsym packages installed.
> >
> > You do not need these packages when you compile from source.
> >
> > > I copied below the results of the
> > > debugging commands:
> > >
> > > 
> > > GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso`
> > > GNU gdb (Debian 7.11.1-2+b1) 7.11.1
> > > Copyright (C) 2016 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later  > /gpl
> > > .html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.  Type "show
> > > copying"
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-linux-gnu".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > .
> > > Find the GDB manual and other documentation resources online at:
> > > .
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from /usr/lib/grass70/bin/v.net.iso...Reading
> > symbols
> > > from

[GRASS-user] importing Mars DEM takes too long

2016-11-18 Thread Anna Petrášová 
Hi,

I was trying to import Mars DEM with r.in.gdal, and it takes forever
to finish it (It showed 3% after 10 minutes). This is what gdalinfo
says:

> gdalinfo /tmp/ESP_035583_2060_RED.JP2
Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
Files: /tmp/ESP_035583_2060_RED.JP2
   /tmp/ESP_035583_2060_RED.JP2.aux.xml
Size is 13094, 26340
Coordinate System is:
PROJCS["Equirectangular MARS",
GEOGCS["GCS_MARS",
DATUM["unknown",
SPHEROID["unnamed",3392593.6110435,0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Equirectangular"],
PARAMETER["latitude_of_origin",25],
PARAMETER["central_meridian",180],
PARAMETER["standard_parallel_1",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (3889293.250,1519463.750)
Pixel Size = (0.500,-0.500)
Corner Coordinates:
Upper Left  ( 3889293.250, 1519463.750) (114d18'56.57"W, 50d39'41.21"N)
Lower Left  ( 3889293.250, 1506293.750) (114d18'56.57"W, 50d26'20.49"N)
Upper Right ( 3895840.250, 1519463.750) (114d12'18.52"W, 50d39'41.21"N)
Lower Right ( 3895840.250, 1506293.750) (114d12'18.52"W, 50d26'20.49"N)
Center  ( 3892566.750, 1512878.750) (114d15'37.55"W, 50d33' 0.85"N)
Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Undefined
  Overviews: 6547x13170, 3273x6585, 1636x3292, 818x1646, 409x823,
204x411, 102x205
  Overviews: arbitrary
  Image Structure Metadata:
NBITS=10

GRASS location was created from this file:

projection: 99 (Equirectangular MARS)
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  a=3392593.6110435 es=0
north:  1519463.75
south:  1506293.75
west:   3889293.25
east:   3895840.25
nsres:  0.5
ewres:  0.5
rows:   26340
cols:   13094
cells:  344895960

I tried to open it in QGIS and it appeared instantly. Then, I tried to
export it from QGIS as Geotiff, but that took again very long (I
didn't wait for it to finish). Running gdal_translate in command line
can't finish either. I tried to debug r.in.gdal and it seems to be
stuck on line 1103 in  GDALRasterIO call. Any advice? I can send the
data privately.

Thank you,

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

Re: [GRASS-user] new map in wxgui digitizer

2016-11-18 Thread Anna Petrášová 
On Fri, Nov 18, 2016 at 10:41 AM, Dave Roberts  wrote:
> Friends,
>
>   I am trying to make use of the wxgui digitizer and finding it somewhat
> challenging.  One issue is that I like to run from the console (i.e. grass73
> -text) and that produces a subtly different widget than if I run from the
> gui (i.e. grass73 -gui).  Using the console version, when I try to digitize
> a new map (as opposed to editing an existing map) I get the error below.
>
> GRASS GIS 7.3.svn > Traceback (most recent call last):
>   File "/usr/local/grass-7.3.svn/gui/wxpython/vdigit/toolbars.py", line 849,
> in OnSelectMap
> if self.layers[selection] == self.mapLayer:
> UnboundLocalError: local variable 'selection' referenced before assignment
>
> and it doesn't digitize any points.
>
> The obvious short term solution is to work from the GUI, but that defeats
> much oswhat I am trying to accomplish in scriptable, repeatable analyses.
>
> GRASS GIS 7.3.svn (r69510)
>
> Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET 2016
> x86_
>
> Thanks, Dave
>
>

That's a bug we should fix before release (if it's in 72). I don't
remember, are you able to create a ticket now?

Anna

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

Re: [GRASS-user] v.net.iso - segmentation fault error

2016-11-18 Thread Eduardo Corbelle Rico 

O Xov, 17-11-2016 ás 08:52 +0100, Markus Metz escribiu:
> 
> On Wed, Nov 16, 2016 at 7:14 PM, Eduardo Corbelle Rico  l...@gmx.net> wrote:
> >
> > O Mér, 16-11-2016 ás 15:22 +0100, Markus Metz escribiu:
> > >
> > > On Wed, Nov 16, 2016 at 11:44 AM, Eduardo Corbelle Rico
>  > > e...@gmx.net> wrote:
> > > >
> > > > O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu:
> > > > > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico
> > > > >  wrote:
> > > > > >
> > > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu:
> > > > > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Dear all,
> > > > > > > >
> > > > > > > > I am unable to use v.net.iso because of a "segmentation
> > > fault"
> > > > > > > > error. I
> > > > > > > >  have a script that used to work correctly in GRASS 6.4
> (32
> > > > > > > > bit)
> > > > > > > > but
> > > > > > > > produces this error after I switched to GRASS 7.0.4 (64
> > > bit).
> > > > > > > >
> > > > > > > > If I try to follow both examples shown in https://grass
> .osg
> > > eo.o
> > > > > > > > rg/g
> > > > > > > > rass
> > > > > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset
> for
> > > > > > > > GRASS 7)
> > > > > > > > the
> > > > > > > > same error appears:
> > > > > > > >
> > > > > > > > > Building graph...
> > > > > > > > > Registering arcs...
> > > > > > > > > Segmentation fault
> > > > > > >
> > > > > > > The segmentation fault must happen in the vector
> libraries. I
> > > > > > > tested
> > > > > > > on Linux and can not reproduce the segmentation fault.
> > > Valgrind
> > > > > > > also
> > > > > > > does not show anything that could cause a segmentation
> fault.
> > > Can
> > > > > > > you
> > > > > > > provide a gdb backtrace?
> > > > > > >
> > > > > > > Markus M
> > > > > >
> > > > > > Thank you Markus,
> > > > > >
> > > > > > My system is debian Stretch, and the following lines
> describe
> > > my
> > > > > > attempt at generating a gdb backtrace. Please let me know
> if I
> > > > > > should
> > > > > > do otherwise.
> > > > >
> > > > > So far so good. The module crashes in a library function that
> > > comes
> > > > > from libavl without modifications, but I can still not see
> why it
> > > > > could cause a segmentation fault. Can you recompile with the
> > > compiler
> > > > > debugging option -g? gdb will then be able to provide more
> > > > > information:
> > > > >
> > > > > make distclean
> > > > > CFLAGS="-g" ./configure 
> > > > > make
> > > > >
> > > > > optionally make install
> > > > >
> > > > > Then start GRASS and use gdb for v.net.iso as before.
> > > > >
> > > > > Markus M
> > > > >
> > > >
> > > > Dear Markus,
> > > >
> > > > Following those instructions does not seem to have changed the
> > > > resulting backtrace info (copied below). Maybe I missed
> something
> > > along
> > > > the way?
> > > >
> > > > -
> > >
> > >
> > > Is this something Debian specific that debugging symbols must be
> > > explicitly activated? Are you using GCC or another compiler?
> > >
> > > Alternatively, you can also try valgrind:
> > >
> > > CMD="v.net.iso input=myroads_net output=myroads_net_iso
> > > center_cats=1-10 costs=1000,2000,5000 --o"
> > > valgrind --tool=memcheck --log-file=v.net.iso.vg.log $CMD
> > >
> > > Markus M
> > >
> >
> > You were right: it was my fault not having grass-core-dbgsym and
> grass-
> > dev-dbgsym packages installed.
> 
> You do not need these packages when you compile from source.
> 
> > I copied below the results of the
> > debugging commands:
> >
> > 
> > GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso`
> > GNU gdb (Debian 7.11.1-2+b1) 7.11.1
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later  /gpl
> > .html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> > copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/lib/grass70/bin/v.net.iso...Reading
> symbols
> > from /usr/lib/debug/.build-
> > id/5a/060fc6c3da41153d82601e3fa37ba6d88e9c6c.debug...done.
> > done.
> >
> >
> > (gdb) run input=myroads_net output=myroads_net_iso center_cats=1-
> 10
> > costs=1000,2000,5000
> 
> This seems to be the GRASS version installed with your package
> manager because make install installs by default to /usr/local/:
> > Starting program:

[GRASS-user] new map in wxgui digitizer

2016-11-18 Thread Dave Roberts 

Friends,

  I am trying to make use of the wxgui digitizer and finding it 
somewhat challenging.  One issue is that I like to run from the console 
(i.e. grass73 -text) and that produces a subtly different widget than if 
I run from the gui (i.e. grass73 -gui).  Using the console version, when 
I try to digitize a new map (as opposed to editing an existing map) I 
get the error below.


GRASS GIS 7.3.svn > Traceback (most recent call last):
  File "/usr/local/grass-7.3.svn/gui/wxpython/vdigit/toolbars.py", line 
849, in OnSelectMap

if self.layers[selection] == self.mapLayer:
UnboundLocalError: local variable 'selection' referenced before assignment

and it doesn't digitize any points.

The obvious short term solution is to work from the GUI, but that 
defeats much oswhat I am trying to accomplish in scriptable, repeatable 
analyses.


GRASS GIS 7.3.svn (r69510)

Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET 
2016 x86_


Thanks, Dave


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