Re: [GRASS-dev] NULL file compression: loop over uncompressed maps to save disk space

[Markus Metz]

On Tue, Jan 3, 2017 at 6:08 PM, Markus Neteler  wrote:
>
> Hi,
>
> while hunting for more GBs on my local disk I found many raster maps
> with a still uncompressed NULL files (no surprise since the optional
> new NULL compression was introduced in 7.2.0).
>
> As an example - EU DEM25m:
>
> uncompressed NULL file:
> 60 Apr 13  2016 ./eu_laea/PERMANENT/cell_misc/eu_dem25/null
>
> compressed NULL file:
> 32108798 Jan  3 15:09 eu_laea/PERMANENT/cell_misc/eu_dem25/nullcmpr
>
> Ratio:
> > 32108798 / 60
> [1] 0.005351466
>
> ... quite an improvement :-)
>
> Having tons of raster maps here I thought of running r.null over all
> raster maps. In general it is:
>
> export GRASS_COMPRESS_NULLS=1
> r.null -z myrastermap
>
> Attached a patch which adds a second line of output to "r.compress -p
> myrastermap" in order to check the actual compression state of a map:
>
> r.compress -p eu_dem25
>  is compressed (method 2: ZLIB). Data type: FCELL
>  has an uncompressed NULL file
>
> After compression it looks like this:
>
> r.compress -p eu_dem25
>  is compressed (method 2: ZLIB). Data type: FCELL
>  has a compressed NULL file
>
> Now, how to use that:
>
> # all in one (check if NULL is compressed, if no, do it otherwise don't
touch):
> r.compress -p eu_dem25 2>&1 | grep uncompressed && r.null -z eu_dem25
>
> Questions:
> I believe that an additional -g flag for shell style printing would be
> useful as well).
> Maybe with a -g flag no need to use the stderr redirect?
> Any better ideas here? (if yes, feel free to submit to SVN for testing)

I have added your changes and a new shell style option to trunk in r70337.
Note that this is not standard shell style because the module accepts
several input maps, thus compression info is written to stdout as one line
per input map. The format is
input map name|data type|name of data compression method|NULL file
compression
e.g.
eu_dem25|FCELL|ZLIB|NO
or
eu_dem25|FCELL|BZIP2|YES

>
>
> 
> Since r.null -z doesn't do anything useful if GRASS_COMPRESS_NULLS is
> not set I have tried (!) to add a G_message() to tell the user if that
> variable is set or not.
> r.null -z eu_dem25
> The GRASS_COMPRESS_NULLS environment variable is currently set
> 6%...
>
> But it *always* tells that it is set, so my getenv() parsing is wrong.
> Can anyone help please? Also attached...

Try trunk r70338. This also fixes removal of a compressed NULL file: the
file name is nullcmpr, not null2

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

Re: [GRASS-dev] [GRASS GIS] #3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

[GRASS GIS]

#3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)
--+
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.superpixels.slic
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+

Comment (by mlennert):

 I attach a more complete patch. It also includes assigning a random color
 table and writing to the output file history.

 Rashad, I don't want to commit because I don't know if you have been
 working locally on the module. Please let me know if you will do it, or if
 you want me to commit.

--
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] #3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

[GRASS GIS]

#3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)
--+
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.superpixels.slic
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+
Changes (by mlennert):

 * Attachment "distc_segfault_patch.diff" added.


--
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.what.rast: topology really necessary?

[Martin Landa]

Hi Stefan,

2017-01-10 22:49 GMT+01:00 Blumentrath, Stefan :
> After repeated testing, a colleague of mine pointed out that I know occupy 
> almost all available PostGIS connections on our server.
> It seems that connections hang from testing and that either v.external or 
> v.what.rast does not close the PG connection properly after the module 
> finishes... Or are there other possible explanations?

I would guess that the command which segfauls could be a problem. I
tested all the commands including v.what.rast which segfaults and
check number of active connection via pg_top. No connection hanged
even I launched the command with segfault.

> Where should I look to find the source of the issue?

Install pgtop on the server, login as postgres user and run pg_top
command. It will show you number of active connection. Run GRASS
command and check number of connection.

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+--
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, v. external
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by martinl):

 * keywords:  v.what.rast => v.what.rast, v. external


Old description:

> Recently the requirement for topology was removed from v.what.rast.
>
> However, the module now segfaults if used with a vector map without
> topology.
>
> The issue can be reproduced with the workflow and data in #3248, but with
>
> {{{
> v.external -b
> }}}
>
> Related discussion here: https://lists.osgeo.org/pipermail/grass-
> dev/2017-January/083830.html

New description:

 Recently the requirement for topology was removed from v.what.rast.

 However, the module now segfaults if used with a *linked* vector map
 without topology.

 The issue can be reproduced with the workflow and data in #3248, but with

 {{{
 v.external -b
 }}}

 Related discussion here: https://lists.osgeo.org/pipermail/grass-
 dev/2017-January/083830.html

--

--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+---
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, v. external, PostGIS
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by martinl):

 * keywords:  v.what.rast, v. external => v.what.rast, v. external, PostGIS
 * component:  Default => Vector


--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+--
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, v. external
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by martinl):

 * status:  new => assigned
 * cc: grass-dev@… (added)
 * owner:  grass-dev@… => martinl


--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+---
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, v. external, PostGIS
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Description changed by martinl:

Old description:

> Recently the requirement for topology was removed from v.what.rast.
>
> However, the module now segfaults if used with a *linked* vector map
> without topology.
>
> The issue can be reproduced with the workflow and data in #3248, but with
>
> {{{
> v.external -b
> }}}
>
> Related discussion here: https://lists.osgeo.org/pipermail/grass-
> dev/2017-January/083830.html

New description:

 Recently the requirement for topology was removed from v.what.rast.

 However, the module now segfaults if used with a vector map without
 topology.

 The issue can be reproduced with the workflow and data in #3248, but with

 {{{
 v.external -b
 }}}

 Related discussion here: https://lists.osgeo.org/pipermail/grass-
 dev/2017-January/083830.html

--

--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+---
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, v. external, PostGIS
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by martinl):

 It's not issue only for linked maps, but also for native format

 {{{
 v.random out=pn n=1000 -b --o column=z
 v.what.rast map=pn raster=rand column=morphology
 Column  not found in the table . Creating...
 Reading features from vector map...

 Segmentation fault
 }}}

--
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-SVN] r70321 - grass/trunk/raster/r.in.xyz

[Martin Landa]

Hi,

2017-01-09 23:01 GMT+01:00 Markus Neteler :
> I tried
> https://grass.osgeo.org/grass72/manuals/r.in.xyz.html#import-of-x,y,z-ascii-into-dem
>
> on my laptop at home and the example fails without output=..

I double checked:

GRASS 7.2.1svn (gismentors_utm):~/src/grass72_release > svn status
(no uncommitted changes)

Fresh compilation:

g.version -g
version=7.2.1svn
date=2017
revision=r70322
build_date=2017-01-11
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8

cat elevation.xyz
630007.5 228492.5 141.99614
630022.5 228492.5 141.37904
630037.5 228492.5 142.29822
630052.5 228492.5 143.97987

GRASS 7.2.1svn (gismentors_utm):~/smetiste > r.in.xyz
input=elevation.xyz separator=space -s -g
n=228492.5 s=228492.5 e=630052.5 w=630007.5 b=141.37904 t=143.97987

? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] NULL file compression: loop over uncompressed maps to save disk space

[Markus Neteler]

On Wed, Jan 11, 2017 at 10:34 AM, Markus Metz
 wrote:
> On Tue, Jan 3, 2017 at 6:08 PM, Markus Neteler  wrote:
...
>> Questions:
>> I believe that an additional -g flag for shell style printing would be
>> useful as well).
>> Maybe with a -g flag no need to use the stderr redirect?
>> Any better ideas here? (if yes, feel free to submit to SVN for testing)
>
> I have added your changes and a new shell style option to trunk in r70337.

Thanks for that!

> Note that this is not standard shell style because the module accepts
> several input maps, thus compression info is written to stdout as one line
> per input map. The format is
> input map name|data type|name of data compression method|NULL file
> compression
> e.g.
> eu_dem25|FCELL|ZLIB|NO
> or
> eu_dem25|FCELL|BZIP2|YES

Yes, that's quite useful like this. Maybe a small modification to make
it usable for the beloved eval() function?

r.compress -g eu_dem25
eu_dem25=FCELL|ZLIB|YES
?
This would keep the -g implementations consistent across different commands.

>> 
>> Since r.null -z doesn't do anything useful if GRASS_COMPRESS_NULLS is
>> not set I have tried (!) to add a G_message() to tell the user if that
>> variable is set or not.
>> r.null -z eu_dem25
>> The GRASS_COMPRESS_NULLS environment variable is currently set
>> 6%...
>>
>> But it *always* tells that it is set, so my getenv() parsing is wrong.
>> Can anyone help please? Also attached...
>
> Try trunk r70338.

Works.

> This also fixes removal of a compressed NULL file: the
> file name is nullcmpr, not null2

That old "null2" name is also here:

./raster/r.support/main.c:G_file_name_misc(path, "cell_misc",
"null2", raster->answer, G_mapset());

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

Re: [GRASS-dev] [GRASS GIS] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+--
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, level 1
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by martinl):

 * keywords:  v.what.rast, v. external, PostGIS => v.what.rast, level 1


--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+--
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, level 1
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by martinl):

 Seems to be a stack overflow somewhere since Map_info struct got ruined
 before segfault:

 {{{
 gdb) p Map.dblnk->field[0]
 $11 = {number = 6, name = 0x760344 , driver = 0x60d770 "sqlite", database = 0x642100
 "$GISDBASE/$LOCAT\005", table = 0x60d5f0 "pn18", key = 0x60d6b0 "cat"}
 }}}

 {{{
 #0  _int_malloc (av=av@entry=0x76f86b00 ,
 bytes=bytes@entry=26) at malloc.c:3762
 #1  0x76c68d94 in __GI___libc_malloc (bytes=26) at malloc.c:2925
 #2  0x7729e088 in G__malloc (file=0x772e166b
 "lib/gis/location.c", line=82, n=26) at alloc.c:39
 #3  0x772aa7c1 in G__location_path () at location.c:82
 #4  0x772a4aaa in file_name (path=0x7fff9990 "\001", dir=0x0,
 element=0x7fffae00 "vector/pn17", name=0x77bc2ed7 "dbln",
 mapset=0x6095f0 "PERMANENT", base=0x0)
 at file_name.c:107
 #5  0x772a4963 in G_file_name (path=0x7fff9990 "\001",
 element=0x7fffae00 "vector/pn17", name=0x77bc2ed7 "dbln",
 mapset=0x6095f0 "PERMANENT") at file_name.c:41
 #6  0x772c0743 in G__open (element=0x7fffae00 "vector/pn17",
 name=0x77bc2ed7 "dbln", mapset=0x6095f0 "PERMANENT", mode=1) at
 open.c:109
 #7  0x772c0929 in G_fopen_new (element=0x7fffae00
 "vector/pn17", name=0x77bc2ed7 "dbln") at open.c:224
 #8  0x77b7ddcc in Vect_write_dblinks (Map=0x7fffbf40) at
 field.c:923
 #9  0x77b7e395 in Vect_set_db_updated (Map=0x7fffbf40) at
 field.c:1023
 #10 0x004027bc in main (argc=4, argv=0x7fffd9e8) at main.c:251
 }}}

--
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.external: ID confusion

[Blumentrath, Stefan]

Hi again,

And sorry, some more v.external issues...

When I try to connect to a remote server in GRASS 7.2.1svn with v.external, I 
get "database not found" error.

In GRASS 7.0 the database is found with exactly the same command.

However, linking the table fails in 7.0 because the ID column is in mixed cases 
and column names are not quoted in the SQL generated by v.external.
BTW. Is it necessary to sort the ID column? Does it make sense if UUIDs are 
used as primary keys?

Cheers
Stefan


-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: mandag 9. januar 2017 18.17
To: Blumentrath, Stefan 
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 

Subject: Re: [GRASS-dev] v.external: ID confusion

Hi Stefan,

2017-01-09 16:42 GMT+01:00 Blumentrath, Stefan :
> Did I overlook something at import or should I open a ticket?

yes, please. Also provide all command and sample data to reproduce this issue. 
Thanks, Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.external: ID confusion

[Martin Landa]

Hi,

2017-01-11 12:54 GMT+01:00 Blumentrath, Stefan :
> When I try to connect to a remote server in GRASS 7.2.1svn with v.external, I 
> get "database not found" error.

new issue? I cannot reproduce it. Can you provide any details?

> However, linking the table fails in 7.0 because the ID column is in mixed 
> cases and column names are not quoted in the SQL generated by v.external.
> BTW. Is it necessary to sort the ID column? Does it make sense if UUIDs are 
> used as primary keys?

Any reproducable example? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo] #1816: upgrade Trac to 1.2 release

[Markus Neteler]

On Wed, Jan 11, 2017 at 12:17 AM, Markus Neteler  wrote:
> On Tue, Jan 10, 2017 at 7:48 PM, Vaclav Petras  wrote:
>> On Tue, Jan 10, 2017 at 11:43 AM, Markus Neteler  wrote:
>>>
>>> From the OSGeo ticket: Alternatives ( to review for supporting Trac 1.2 )
>>> :
>>>   - https://trac-hacks.org/wiki/TracStatsPlugin
>>
>>
>> Looks good. May be useful. Seems very comprehensive. Last commit on GitHub
>> from Dec 2016.
>
> Great, I have suggested that now to SAC.

Up-and-running, I have activated it:

https://trac.osgeo.org/grass/stats

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

Re: [GRASS-dev] Fwd: [OSGeo] #1816: upgrade Trac to 1.2 release

[Luca Delucchi]

On 11 January 2017 at 13:42, Markus Neteler  wrote:

>
> Up-and-running, I have activated it:
>
> https://trac.osgeo.org/grass/stats
>

for me it return an error

Error: Forbidden

STATS_VIEW privileges are required to perform this operation. You
don't have the required permissions.

TracGuide — The Trac User and Administration Guide


> Markus
>


-- 
ciao
Luca

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

Re: [GRASS-dev] Fwd: [OSGeo] #1816: upgrade Trac to 1.2 release

[Markus Neteler]

On Wed, Jan 11, 2017 at 1:49 PM, Luca Delucchi  wrote:
> On 11 January 2017 at 13:42, Markus Neteler  wrote:
>
>>
>> Up-and-running, I have activated it:
>>
>> https://trac.osgeo.org/grass/stats
>>
>
> for me it return an error
>
> Error: Forbidden
>
> STATS_VIEW privileges are required to perform this operation. You
> don't have the required permissions.

Right, fixed in
https://trac.osgeo.org/grass/admin/general/perm
following
https://trac-hacks.org/wiki/TracStatsPlugin#Configuration

Please try again.

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

Re: [GRASS-dev] Fwd: [OSGeo] #1816: upgrade Trac to 1.2 release

[Luca Delucchi]

On 11 January 2017 at 14:03, Markus Neteler  wrote:

>
> Right, fixed in
> https://trac.osgeo.org/grass/admin/general/perm
> following
> https://trac-hacks.org/wiki/TracStatsPlugin#Configuration
>
> Please try again.
>

It works, thanks!

> Markus



-- 
ciao
Luca

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

Re: [GRASS-dev] NULL file compression: loop over uncompressed maps to save disk space

[Markus Metz]

On Wed, Jan 11, 2017 at 12:37 PM, Markus Neteler  wrote:
>
> On Wed, Jan 11, 2017 at 10:34 AM, Markus Metz
>  wrote:
> > On Tue, Jan 3, 2017 at 6:08 PM, Markus Neteler 
wrote:
> ...
> >> Questions:
> >> I believe that an additional -g flag for shell style printing would be
> >> useful as well).
> >> Maybe with a -g flag no need to use the stderr redirect?
> >> Any better ideas here? (if yes, feel free to submit to SVN for testing)
> >
> > I have added your changes and a new shell style option to trunk in
r70337.
>
> Thanks for that!
>
> > Note that this is not standard shell style because the module accepts
> > several input maps, thus compression info is written to stdout as one
line
> > per input map. The format is
> > input map name|data type|name of data compression method|NULL file
> > compression
> > e.g.
> > eu_dem25|FCELL|ZLIB|NO
> > or
> > eu_dem25|FCELL|BZIP2|YES
>
> Yes, that's quite useful like this. Maybe a small modification to make
> it usable for the beloved eval() function?
>
> r.compress -g eu_dem25
> eu_dem25=FCELL|ZLIB|YES
> ?

In this case, eu_dem25 would be both the name of a raster map and the name
of a variable, I find this confusing. And you still need to split the
result. I guess parsing
eu_dem25|FCELL|ZLIB|YES
would be slightly easier in python than
eu_dem25=FCELL|ZLIB|YES

> This would keep the -g implementations consistent across different
commands.

Full easy support for eval() is not possible if the same parameters are
printed several times. See e.g. r.univar -gt with a zonal map, r.quantile,
r.stats.quantile or v.db.connect -g with several connections defined.
Therefore I would use one line with name=value where possible, otherwise
one line per input with separated fields. I would not mix the two, IMHO it
will cause confusion.

>
> That old "null2" name is also here:
>
> ./raster/r.support/main.c:G_file_name_misc(path, "cell_misc",
> "null2", raster->answer, G_mapset());

Fixed in r70340,1 (trunk, relbr72).

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

Re: [GRASS-dev] wxGUI: align to resolution by default

[Markus Metz]

On Fri, Jan 6, 2017 at 6:26 PM, Martin Landa  wrote:
>
> Hi,
>
> 2017-01-05 22:56 GMT+01:00 Markus Metz :
>
> > The above example does not set the region from two map layers (one
vector,
> > one raster), that would be g.region -p vector=vect_map raster=rast_map.
> > Instead, it sets the region extents from a vector and aligns the region
to a
> > raster. That is a big difference.
>
> yes, I am saying that this operation is not straightforward in wxGUI,
> user need to do several steps
>
> 1) set comp region from raster
> 2) go to settings, enable -a flag\
> 3) set comp region from vector
> 4) probably disable -a
>
> > IMHO, the GUI should not try to be too clever about how to adjust the
> > computational region, instead users should be clever about how to
adjust the
> > computational region because changed region settings can cause
unexpected
> > results.
>
> Hm, I added to wxGUI new item to "Set computational region from
> selected vector(s) align to raster" (r70276). This is enabled only
> when user selects vector(s) and one raster map together. If it make
> sense to you I will backport to relbr72.

How about two items:
- "Set computational region from selected map(s)" will set the region
extents to include all selected maps, irrespective of type.
- "Align region to selected raster" will align the region to a single
selected raster

Just to be safe, I usually do this two-step adjustment: first set the
extents, then set and/or align to the resolution.

Markus M

>
> Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r70321 - grass/trunk/raster/r.in.xyz

[Luca Delucchi]

On 11 January 2017 at 12:08, Martin Landa  wrote:
> Hi,
>

Hi,

>
> GRASS 7.2.1svn (gismentors_utm):~/src/grass72_release > svn status
> (no uncommitted changes)
>
> Fresh compilation:
>
> g.version -g
> version=7.2.1svn
> date=2017
> revision=r70322
> build_date=2017-01-11
> build_platform=x86_64-pc-linux-gnu
> build_off_t_size=8
>
> cat elevation.xyz
> 630007.5 228492.5 141.99614
> 630022.5 228492.5 141.37904
> 630037.5 228492.5 142.29822
> 630052.5 228492.5 143.97987
>
> GRASS 7.2.1svn (gismentors_utm):~/smetiste > r.in.xyz
> input=elevation.xyz separator=space -s -g
> n=228492.5 s=228492.5 e=630052.5 w=630007.5 b=141.37904 t=143.97987
>
> ? Ma
>

also for it works (using lidaratm2.txt from [0])

r.in.xyz in=/tmp/lidaratm2.txt sep=, -s -g
n=35.969493 s=35.949693 e=-75.620999 w=-75.63 b=-1.937 t=200.935

[0] https://www.grassbook.org/wp-content/uploads/ncexternal/index.html

-- 
ciao
Luca

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

Re: [GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Hi Martin,

Thanks for the hint. Will do so...

Cheers
Stefan


-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: onsdag 11. januar 2017 11.26
To: Blumentrath, Stefan 
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 

Subject: Re: [GRASS-dev] v.what.rast: topology really necessary?

Hi Stefan,

2017-01-10 22:49 GMT+01:00 Blumentrath, Stefan :
> After repeated testing, a colleague of mine pointed out that I know occupy 
> almost all available PostGIS connections on our server.
> It seems that connections hang from testing and that either v.external or 
> v.what.rast does not close the PG connection properly after the module 
> finishes... Or are there other possible explanations?

I would guess that the command which segfauls could be a problem. I tested all 
the commands including v.what.rast which segfaults and check number of active 
connection via pg_top. No connection hanged even I launched the command with 
segfault.

> Where should I look to find the source of the issue?

Install pgtop on the server, login as postgres user and run pg_top command. It 
will show you number of active connection. Run GRASS command and check number 
of connection.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3252: Provide an error message pointing out that session is not active

[GRASS GIS]

#3252: Provide an error message pointing out that session is not active
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.1
Component:  Startup  |Version:  unspecified
 Keywords:  GRASS GIS environment variables, |CPU:  Unspecified
  g.gisenv, G_getenv, G_getenv_nofatal,  |
  G_fatal_error, fatal error, LOCATION_NAME, |
  session|
 Platform:  Unspecified  |
-+-
 When you run

 {{{
 grass73 ~/grassdata/nc_spm_08_grass7/user1 --exec d.mon wx0
 }}}

 it gives

 {{{
 ERROR: Variable 'LOCATION_NAME' not set
 }}}

 it also prints

 {{{
 Traceback (most recent call last):
   File "/home/vpetras/dev/grass/gcc_trunk/dist.x86_64-pc-linux-
 gnu/gui/wxpython/mapdisp/main.py", line 608, in 
 fd = open(pidFile, 'w')
 IOError: [Errno 2] No such file or directory:
 '/home/vpetras/grassdata/nc_spm_08_grass7/user1/.tmp/lemur/MONITORS/wx0/pid'
 }}}

 but what it is trying to say is that there is not running in an active
 GRASS GIS session (session ended but d.mon wx0 runs in the background).

 Similar situation can be created in Python using:

 {{{
 #!python
 import os
 import sys
 import subprocess

 # create GRASS GIS runtime environment
 gisbase = subprocess.check_output(["grass", "--config", "path"]).strip()
 os.environ['GISBASE'] = gisbase
 sys.path.append(os.path.join(gisbase, "etc", "python"))

 # do GRASS GIS imports
 import grass.script as gs
 import grass.script.setup as gsetup

 # set GRASS GIS session data
 rcfile = gsetup.init(gisbase, "/home/vpetras/grassdata",
 "nc_spm_08_grass7", "user1")

 # run module
 gs.parse_command('g.region', region="swwake_30m", flags='pg')

 # end the GRASS session
 os.remove(rcfile)

 # run module again
 gs.parse_command('g.region', region="swwake_30m", flags='pg')
 }}}

 The error is again (possibly with traceback):

 {{{
 ERROR: Variable 'LOCATION_NAME' not set
 }}}

 But it should be one of those (or any other you think is better):

 {{{
 ERROR: No GRASS GIS session is not active: Variable 'LOCATION_NAME' not
 set

 ERROR: Variable 'LOCATION_NAME' not set. Are you in GRASS GIS session?

 ERROR: Variable 'LOCATION_NAME' not set. Are you running GRASS GIS
 session?

 ERROR: Not running in a GRASS GIS session (variable 'LOCATION_NAME' not
 set)
 }}}

--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+--
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, level 1
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by martinl):

 * milestone:  7.2.1 => 7.4.0


Comment:

 Since changes in `v.what.rast` (r70331+r70332) haven't been ported to
 relbr72, setting milestone to 7.4.0.

--
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] #3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

[GRASS GIS]

#3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)
--+
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.superpixels.slic
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+

Comment (by mmetz):

 Replying to [comment:3 mlennert]:
 > I attach a more complete patch. It also includes assigning a random
 color table and writing to the output file history.

 There is more to fix around L157, see also my comments in the dev ml [0]

 [0] https://lists.osgeo.org/pipermail/grass-dev/2017-January/083745.html

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] NULL file compression: loop over uncompressed maps to save disk space

[Markus Neteler]

On Wed, Jan 11, 2017 at 3:06 PM, Markus Metz
 wrote:
> On Wed, Jan 11, 2017 at 12:37 PM, Markus Neteler  wrote:
>> On Wed, Jan 11, 2017 at 10:34 AM, Markus Metz

>> > Note that this is not standard shell style because the module accepts
>> > several input maps, thus compression info is written to stdout as one
>> > line per input map. The format is
>> > input map name|data type|name of data compression method|NULL file
>> > compression
>> > e.g.
>> > eu_dem25|FCELL|ZLIB|NO
>> > or
>> > eu_dem25|FCELL|BZIP2|YES
>>
>> Yes, that's quite useful like this. Maybe a small modification to make
>> it usable for the beloved eval() function?
>>
>> r.compress -g eu_dem25
>> eu_dem25=FCELL|ZLIB|YES
>> ?
>
> In this case, eu_dem25 would be both the name of a raster map and the name
> of a variable, I find this confusing. And you still need to split the
> result. I guess parsing
> eu_dem25|FCELL|ZLIB|YES
> would be slightly easier in python than
> eu_dem25=FCELL|ZLIB|YES
>
>> This would keep the -g implementations consistent across different
>> commands.
>
> Full easy support for eval() is not possible if the same parameters are
> printed several times. See e.g. r.univar -gt with a zonal map, r.quantile,
> r.stats.quantile or v.db.connect -g with several connections defined.
> Therefore I would use one line with name=value where possible, otherwise one
> line per input with separated fields. I would not mix the two, IMHO it will
> cause confusion.

ok fine. After a bit of testing I suggest to backport the new flag and
r.null messages so that NULL compression becomes easy also in 7.2 (I
enjoyed already the --exec interface to loop over all mapsets from
outside and compress all maps therein).

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

[GRASS-dev] [GRASS GIS] #3253: Main GUI fails to start when g.extension fails when fetching the addons

[GRASS GIS]

#3253: Main GUI fails to start when g.extension fails when fetching the addons
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.1
Component:  wxGUI|Version:  svn-
 Keywords:  toolboxes, g.extension, startup, |  releasebranch72
  addons |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 The GUI fails to start when `g.extension` fails during ''Addons'' toolbox
 creation in `core/toolboxes.py`. GUI should continue just with an empty
 ''Addons'' toolbox.

 After hitting OK, there is no further error or window visible. It does not
 matter what if it is during GRASS start or with `g.gui` with or without
 `-f`, same for 72 branch and trunk.

 This is the error message in a dialog. The `g.extension` error is in the
 command line which is not ideal because it should be at the same place as
 the traceback.

 {{{
 List of addons cannot be obtained because g.extension failed.

 Reason: Process ended with non-zero return code 1. See errors in the
 (error) output.

 Traceback (most recent call last):
   File ".../gui/wxpython/core/toolboxes.py", line 507, in _getAddons
 output = gcore.read_command('g.extension', quiet=True,
 flags='qwertyuiopag')
   File ".../etc/python/grass/script/core.py", line 474, in read_command
 return handle_errors(returncode, stdout, args, kwargs)
   File ".../etc/python/grass/script/core.py", line 330, in handle_errors
 returncode=returncode)
 CalledModuleError: Module run None ['g.extension', '--q', '-qwertyuiopag']
 ended with error
 Process ended with non-zero return code 1. See errors in the (error)
 output.
 }}}

--
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] #3254: dbmi: add support for uuid data type

[GRASS GIS]

#3254: dbmi: add support for uuid data type
--+-
 Reporter:  martinl   |  Owner:  grass-dev@…
 Type:  task  | Status:  new
 Priority:  normal|  Milestone:  7.4.0
Component:  Database  |Version:  unspecified
 Keywords:  postgresql, uuid  |CPU:  Unspecified
 Platform:  Unspecified   |
--+-
 GRASS DBMI lacks support for uuid data type (1). Currently PG DB driver
 reports:

 {{{
  WARNING: PostgreSQL driver: column 'locationID', type 2950 is not
 supported
 }}}

 (1) https://www.postgresql.org/docs/9.6/static/datatype-uuid.html

--
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] #3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

[GRASS GIS]

#3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)
--+
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.superpixels.slic
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+

Comment (by mlennert):

 Replying to [comment:4 mmetz]:
 > Replying to [comment:3 mlennert]:
 > > I attach a more complete patch. It also includes assigning a random
 color table and writing to the output file history.
 >
 > There is more to fix around L157, see also my comments in the dev ml [0]
 >
 > [0] https://lists.osgeo.org/pipermail/grass-dev/2017-January/083745.html

 Yes, sorry, I had overlooked that you had already solved this issue and
 others in that mail. I don't know how much of this might become redundant
 when the SEG library is used.

 If Rashad doesn't tell me otherwise, I'll commit your fixes + my additions
 later today.

--
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] #3249: v.what.rast: segfault with map without topology

[GRASS GIS]

#3249: v.what.rast: segfault with map without topology
--+--
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.what.rast, level 1
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by marisn):

 When ever there seems to be a problem with memory, use valgrind!

 The reason of segfault is a failure to allocate memory on line 197. It
 comes from call to Vect_get_num_primitives few lines earlier.
 Vect_get_num_primitives uses Map.plus to get info about number of
 features, but plus "Holds basic topology-related information about vector
 map". No topology == no number of features in plus == allocation of 0
 sized memory for cache == illegal writes further in code.

 Solution:
 * information about number of features must be obtained in some other way
 (L194)
 * probably also Vect_get_num_primitives should be modified to return -1 if
 topology is missing

--
Ticket URL: 
GRASS GIS 

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