Re: [GRASS-dev] closing tickets as wontfix because of "No activity"

2019-02-09 Thread Luca Delucchi
On Sat, 9 Feb 2019 at 22:42, Markus Metz 
wrote:

> Hi Martin,
>

Hi,

>
> I don't think it is a good idea to close tickets as "wontfix" because of
> "No activity". The issues might still be relevant. I suggest to ping the
> appropriate maintainer(s) instead.
>
>
I had same feeling...


> "wontfix" should IMHO be used if a ticket can not be fixed for technical
> reasons.
>
> my2c
>
> Markus M
>
>
-- 
ciao
Luca

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

Re: [GRASS-dev] [GRASS GIS] #3226: v.select: how to handle situation where no features are found

2019-02-09 Thread GRASS GIS
#3226: v.select: how to handle situation where no features are found
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.4
 Component:  Vector   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  v.select
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by hcho):

 I'm not sure if "not" creating an empty vector is more efficient. For
 example,
 {{{
 v.select ainput=vect1 binput=vect2 output=outvect operator=disjoint --o

 # the existence and validity of outvect would be guaranteed if v.select
 created
 # an empty output for no features
 for cat in `v.db.select -c map=outvect column=cat`; do
 echo $cat
 done
 }}}
 needs to be changed like this:
 {{{
 # make sure there is no previous output vector because v.select won't
 # delete or create a new empty vector when no features are selected
 g.remove -f type=vector name=outvect

 v.select ainput=vect1 binput=vect2 output=outvect operator=disjoint --o

 # check if v.select selected any features
 eval `g.findfile element=vector file=outvect`
 if [ "x$file" != "x" ]; then
 for cat in `v.db.select -c map=outvect column=cat`; do
 echo $cat
 done
 fi
 }}}

 I think "at least" this module should delete the output vector if no
 features are selected with --o flag to avoid a false positive "by mistake"
 and save one line, but for me, it makes more sense to create an empty
 output for easier scripting. Maybe a new flag like -e for empty output?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3226: v.select: how to handle situation where no features are found

2019-02-09 Thread GRASS GIS
#3226: v.select: how to handle situation where no features are found
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.4
 Component:  Vector   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  v.select
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by hcho):

 When no features are selected and the overwrite flag (--o) is given,
 shouldn't this module delete the output vector then? Recently, I ran into
 this problem and used the wrong vector from a previous iteration.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3746: Quouting of strings with white space in t.info breaks tests for temporal modules

2019-02-09 Thread GRASS GIS
#3746: Quouting of strings with white space in t.info breaks tests for temporal
modules
-+-
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.8.0
 Component:  Tests   |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  temporal,t.info
   CPU:  All |   Platform:  All
-+-
Changes (by sbl):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The rest of the test-errors in the temporal testsuites were not touched as
 they indicate other issues (e.g. related to Python 3, changed results, or
 errors in the test-code.)

 Types of those errors are:
 * AssertionError: reference argument is not a string (in several tests)
 * grass.exceptions.FatalError: Wrong type of input A (in algebra tests)
 * AttributeError: 'NoneType' object has no attribute 'second' (in several
 tests related to datetime_math)
 * AssertionError: There is no map  of type  in
 the current mapset (t.rast.aggregate)
 * Process ended with non-zero return code t.remove(inputs=['R'],
 type='strds', flags=u'rf', quiet=True). See errors in the (error) output.
 * UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
 position 2: ordinal not in range(128)

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3746: Quouting of strings with white space in t.info breaks tests for temporal modules

2019-02-09 Thread GRASS GIS
#3746: Quouting of strings with white space in t.info breaks tests for temporal
modules
-+-
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.8.0
 Component:  Tests   |Version:  svn-trunk
Resolution:  |   Keywords:  temporal,t.info
   CPU:  All |   Platform:  All
-+-

Comment (by sbl):

 In [changeset:"74073" 74073]:
 {{{
 #!CommitTicketReference repository="" revision="74073"
 add quotes around t.info strings; see #3746
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] closing tickets as wontfix because of "No activity"

2019-02-09 Thread Markus Metz
Hi Martin,

I don't think it is a good idea to close tickets as "wontfix" because of
"No activity". The issues might still be relevant. I suggest to ping the
appropriate maintainer(s) instead.

"wontfix" should IMHO be used if a ticket can not be fixed for technical
reasons.

my2c

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

Re: [GRASS-dev] [GRASS GIS] #2684: i.segment do not recycle IDnumbers (categories)

2019-02-09 Thread GRASS GIS
#2684: i.segment do not recycle IDnumbers (categories)
+-
  Reporter:  franziskabeau  |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  Default|Version:  7.0.0
Resolution:  fixed  |   Keywords:
   CPU:  x86-64 |   Platform:  MSWindows 7
+-
Changes (by mmetz):

 * status:  reopened => closed
 * resolution:   => fixed


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2684: i.segment do not recycle IDnumbers (categories)

2019-02-09 Thread GRASS GIS
#2684: i.segment do not recycle IDnumbers (categories)
+-
  Reporter:  franziskabeau  |  Owner:  grass-dev@…
  Type:  defect | Status:  reopened
  Priority:  normal |  Milestone:  7.0.7
 Component:  Default|Version:  7.0.0
Resolution: |   Keywords:
   CPU:  x86-64 |   Platform:  MSWindows 7
+-
Changes (by mmetz):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 Already fixed in trunk r73559, closing as fixed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): CLI location creation: cannot read .prj file for new location

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): CLI location creation: cannot read .prj file for
new location
---+---
  Reporter:  rshepard  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:  locaton wizard, .prj file
   CPU:  x86-32|   Platform:  Linux
---+---

Comment (by mmetz):

 Replying to [comment:4 mmetz]:
 > Replying to [comment:2 neteler]:
 > >
 > >
 > > {{{
 > > # write out user's WKT string as .prj file
 > > echo
 
'PROJCS["NAD_1983_UTM_Zone_11N",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETER["false_northing",0],UNIT["Meter",1]]'
 > bla.prj
 > >
 > > # attempt to generate a new location from it:
 > > grass77 -c bla.prj  ~/grassdata/mylocation
 > > Starting GRASS GIS...
 > > Creating new GRASS GIS location ...
 > > ERROR: ERROR 4: `bla.prj' not recognized as a supported file format.
 > > ERROR: Unable to read georeferenced file  using GDAL library
 > > }}}
 > >
 > >
 > > I checked further and found a difference between g.proj and
 > > gdalsrsinfo opening files:
 > >
 > > general/g.proj/input.c, line 271 :
 > > (inofficially: https://github.com/GRASS-GIS/grass-
 ci/blob/master/general/g.proj/input.c#L271)
 > >
 > > {{{
 > > if ((gdal_ds = GDALOpen(geofile, GA_ReadOnly))) {
 > > }}}
 > >
 > > apps/gdalsrsinfo.cpp, line 306
 > >
 https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalsrsinfo.cpp#L306
 > >
 > > {{{
 > > poGDALDS = static_cast(GDALOpenEx( pszInput, 0,
 > > nullptr, nullptr, nullptr ));
 > > }}}
 > >
 > >
 > > It seems that GDALOpenEx() is more flexible concerning the input (it
 > > exists since GDAL 2.0):
 >
 > No, the trick is here:
 >
 
https://github.com/OSGeo/gdal/blob/a0e1932541cb4edc6d2e254d7af6f64cd0dc0806/gdal/apps/gdalsrsinfo.cpp#L334
 >
 > If `GDALOpenEx()` fails, it checks if it is a *.prj file

 Please try trunk r74072

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): CLI location creation: cannot read .prj file for new location

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): CLI location creation: cannot read .prj file for
new location
---+---
  Reporter:  rshepard  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:  locaton wizard, .prj file
   CPU:  x86-32|   Platform:  Linux
---+---

Comment (by mmetz):

 Replying to [comment:2 neteler]:
 >
 >
 > {{{
 > # write out user's WKT string as .prj file
 > echo
 
'PROJCS["NAD_1983_UTM_Zone_11N",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETER["false_northing",0],UNIT["Meter",1]]'
 > bla.prj
 >
 > # attempt to generate a new location from it:
 > grass77 -c bla.prj  ~/grassdata/mylocation
 > Starting GRASS GIS...
 > Creating new GRASS GIS location ...
 > ERROR: ERROR 4: `bla.prj' not recognized as a supported file format.
 > ERROR: Unable to read georeferenced file  using GDAL library
 > }}}
 >
 >
 > I checked further and found a difference between g.proj and
 > gdalsrsinfo opening files:
 >
 > general/g.proj/input.c, line 271 :
 > (inofficially: https://github.com/GRASS-GIS/grass-
 ci/blob/master/general/g.proj/input.c#L271)
 >
 > {{{
 > if ((gdal_ds = GDALOpen(geofile, GA_ReadOnly))) {
 > }}}
 >
 > apps/gdalsrsinfo.cpp, line 306
 > https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalsrsinfo.cpp#L306
 >
 > {{{
 > poGDALDS = static_cast(GDALOpenEx( pszInput, 0,
 > nullptr, nullptr, nullptr ));
 > }}}
 >
 >
 > It seems that GDALOpenEx() is more flexible concerning the input (it
 > exists since GDAL 2.0):

 No, the trick is here:
 
https://github.com/OSGeo/gdal/blob/a0e1932541cb4edc6d2e254d7af6f64cd0dc0806/gdal/apps/gdalsrsinfo.cpp#L334

 If `GDALOpenEx()` fails, it checks if it is a *.prj file

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): CLI location creation: cannot read .prj file for new location (was: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): CLI location creation: cannot read .prj file for
new location
---+---
  Reporter:  rshepard  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:  locaton wizard, .prj file
   CPU:  x86-32|   Platform:  Linux
---+---

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2684: i.segment do not recycle IDnumbers (categories)

2019-02-09 Thread GRASS GIS
#2684: i.segment do not recycle IDnumbers (categories)
+-
  Reporter:  franziskabeau  |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  Default|Version:  7.0.0
Resolution:  wontfix|   Keywords:
   CPU:  x86-64 |   Platform:  MSWindows 7
+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2678: GRASS starts even when Mapset is locked

2019-02-09 Thread GRASS GIS
#2678: GRASS starts even when Mapset is locked
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.7
 Component:  Startup |Version:  svn-trunk
Resolution:  wontfix |   Keywords:  init, grass.py, lock, locking,
   CPU:  |  .gislock, GUI
  Unspecified|   Platform:  Linux
-+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-user] Unable to read .prj file

2019-02-09 Thread Markus Neteler
On Sat, Feb 9, 2019 at 6:18 PM Markus Metz
 wrote:
...
> > Perhaps g.proj should be updated accordingly?
>
> Easy to implement, please open a ticket such that it does not get forgotten.

Sure, see (the ticket title is IMHO opposed to the current situation,
but never mind):
Ticket URL: https://trac.osgeo.org/grass/ticket/3750#comment:2

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

Re: [GRASS-dev] [GRASS GIS] #2591: error in grass.sh selecting python version

2019-02-09 Thread GRASS GIS
#2591: error in grass.sh selecting python version
+-
  Reporter:  foret37|  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  Default|Version:  unspecified
Resolution:  wontfix|   Keywords:
   CPU:  OSX/Intel  |   Platform:  Unspecified
+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2532: TypeError: environment can only contain string when launching script on Windows

2019-02-09 Thread GRASS GIS
#2532: TypeError: environment can only contain string when launching script on
Windows
--+-
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Default  |Version:  svn-trunk
Resolution:  wontfix  |   Keywords:  encoding
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2508: Vect_open_old2 cannot recognize mapset='ogr'

2019-02-09 Thread GRASS GIS
#2508: Vect_open_old2 cannot recognize mapset='ogr'
+-
  Reporter:  artegion   |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  LibVector  |Version:  unspecified
Resolution:  wontfix|   Keywords:  ogr
   CPU:  All|   Platform:  All
+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

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

2019-02-09 Thread GRASS GIS
#2497: Incompatile PostGIS Topology export
--+---
  Reporter:  strk |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.6.1
 Component:  Vector   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  postgis, topology
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by martinl):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  7.0.7 => 7.6.1


Comment:

 Already fixed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2499: GRASS70: v.in.ogr in does not handle "nan" in attribute tables properly

2019-02-09 Thread GRASS GIS
#2499: GRASS70: v.in.ogr in does not handle "nan" in attribute tables properly
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.1
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  v.in.ogr, DBMI, SQLite, nan
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * milestone:  7.0.7 => 7.6.1


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2491: configure: error: *** Unable to locate FreeType includes.

2019-02-09 Thread GRASS GIS
#2491: configure: error: *** Unable to locate FreeType includes.
--+-
  Reporter:  strk |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Compiling|Version:  unspecified
Resolution:  wontfix  |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2475: g.findfile type/element support not clear

2019-02-09 Thread GRASS GIS
#2475: g.findfile type/element support not clear
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  8.0.0
 Component:  Default |Version:  unspecified
Resolution:  |   Keywords:  g.findfile, find_file, types,
 |  elements, cell, fcell, dcell, rast, rast3d, API
   CPU:  |  change, g.list
  Unspecified|   Platform:  Unspecified
-+-
Changes (by martinl):

 * milestone:  7.0.7 => 8.0.0


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-user] Unable to read .prj file

2019-02-09 Thread Markus Metz
On Sat, Feb 9, 2019 at 12:05 PM Markus Neteler  wrote:
>
> (adding grass-dev)
>
> On Sat, Feb 9, 2019 at 11:14 AM Markus Neteler  wrote:
> > On Sat, Feb 9, 2019 at 10:57 AM Helmut Kudrnovsky  wrote:
> > >
> > > >Just the GRASS GIS logics (still) prevent from accepting a .prj file
as
> > > input.
> > >
> > > at least in the GUI and the location wizzard you can use a .prj-file
to
> > > create a new location.
> >
> > Yes but not on the beloved command line:
> >
> > grass77 -c bla.prj  ~/grassdata/mylocation
> > Starting GRASS GIS...
> > Creating new GRASS GIS location ...
> > ERROR: ERROR 4: `bla.prj' not recognized as a supported file format.
> > ERROR: Unable to read georeferenced file  using GDAL library

g.proj wkt=bla.prj -p
works

>
> I checked further and found a difference between g.proj and
> gdalsrsinfo opening files:
>
> general/g.proj/input.c, line 271 :
> (inofficially:
https://github.com/GRASS-GIS/grass-ci/blob/master/general/g.proj/input.c#L271
)
>
> if ((gdal_ds = GDALOpen(geofile, GA_ReadOnly))) {
>
> apps/gdalsrsinfo.cpp, line 306
> https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalsrsinfo.cpp#L306
>
> poGDALDS = static_cast(GDALOpenEx( pszInput, 0,
> nullptr, nullptr, nullptr ));
>
> It seems that GDALOpenEx() is more flexible concerning the input (it
> exists since GDAL 2.0):
>
https://www.gdal.org/classGDALDataset.html#a9cb8585d0b3c16726b08e25bcc94274a
>
> Perhaps g.proj should be updated accordingly?

Easy to implement, please open a ticket such that it does not get forgotten.

Markus M
>
> Markus
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2453: Thai characters not displaying correctly in the query results window of Map Display in GRASS 7.0.0beta3 Windows

2019-02-09 Thread GRASS GIS
#2453: Thai characters not displaying correctly in the query results window of 
Map
Display in GRASS 7.0.0beta3 Windows
---+---
  Reporter:  richardc  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  8.0.0
 Component:  Default   |Version:  svn-releasebranch70
Resolution:|   Keywords:  Map Display, Asian characters
   CPU:  x86-32|   Platform:  MSWindows 7
---+---
Changes (by martinl):

 * milestone:  7.0.7 => 8.0.0


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2413: pygrass: number_of wrong function associated

2019-02-09 Thread GRASS GIS
#2413: pygrass: number_of wrong function associated
--+-
  Reporter:  artegion |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.4.5
 Component:  Python   |Version:  svn-releasebranch70
Resolution:  fixed|   Keywords:  pygrass vector
   CPU:  Unspecified  |   Platform:  All
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  7.0.7 => 7.4.5


Comment:

 Already fixed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2019-02-09 Thread GRASS GIS
#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  wxGUI|Version:  unspecified
Resolution:  wontfix  |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2324: v.to.rast: useless area warning on points-only maps

2019-02-09 Thread GRASS GIS
#2324: v.to.rast: useless area warning on points-only maps
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.1
 Component:  Vector   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  v.to.rast
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * milestone:  7.0.7 => 7.6.1


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2322: v.db.addtable: add sanity check to avoid unreadable column types with SQLite

2019-02-09 Thread GRASS GIS
#2322: v.db.addtable: add sanity check to avoid unreadable column types with
SQLite
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.1
 Component:  Database |Version:  svn-releasebranch70
Resolution:   |   Keywords:  v.db.addtable, SQLite
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by martinl):

 * milestone:  7.0.7 => 7.6.1


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2314: output r.out.xyz

2019-02-09 Thread GRASS GIS
#2314: output r.out.xyz
-+-
  Reporter:  pvanbosgeo  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.7
 Component:  Default |Version:  svn-trunk
Resolution:  worksforme  |   Keywords:  separator, pipe, r.out.xyz, r.stats
   CPU:  All |   Platform:  MSWindows 7
-+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Not reproducable in G76

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2246: G7: r.shaded.relief result not added to layer tree

2019-02-09 Thread GRASS GIS
#2246: G7: r.shaded.relief result not added to layer tree
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.7
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  worksforme  |   Keywords:  r.shaded.relief
   CPU:  x86-64  |   Platform:  All
-+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Works with G76 (r.shade)

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2240: wxGUI: measurement tool does not show line after first click

2019-02-09 Thread GRASS GIS
#2240: wxGUI: measurement tool does not show line after first click
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.6.1
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  d.measure
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by martinl):

 * type:  defect => enhancement
 * milestone:  7.0.7 => 7.6.1


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2069: List of GRASS 7 compiler warnings in libraries

2019-02-09 Thread GRASS GIS
#2069: List of GRASS 7 compiler warnings in libraries
+-
  Reporter:  neteler|  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  Compiling  |Version:  svn-trunk
Resolution:  wontfix|   Keywords:
   CPU:  x86-64 |   Platform:  Linux
+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

2019-02-09 Thread GRASS GIS
#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-
Changes (by martinl):

 * milestone:  7.0.7 => 7.6.1


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1728: r.slope.aspect: possible data type bug?

2019-02-09 Thread GRASS GIS
#1728: r.slope.aspect: possible data type bug?
--+
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Raster   |Version:  svn-trunk
Resolution:  wontfix  |   Keywords:  r.slope.aspect
   CPU:  All  |   Platform:  All
--+
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1713: Error at compilation error located in grass_trunk/visualization/ximgview

2019-02-09 Thread GRASS GIS
#1713: Error at compilation error located in grass_trunk/visualization/ximgview
+-
  Reporter:  pierreroudier  |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  Compiling  |Version:  svn-trunk
Resolution:  wontfix|   Keywords:  ximgview
   CPU:  x86-64 |   Platform:  Linux
+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 No activity.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1691: r.ros and r.spread don't overwrite

2019-02-09 Thread GRASS GIS
#1691: r.ros and r.spread don't overwrite
--+-
  Reporter:  madi |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Raster   |Version:  svn-releasebranch64
Resolution:  invalid  |   Keywords:  r.ros, r.spread
   CPU:  x86-64   |   Platform:  Linux
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => invalid


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new location

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new
location
---+---
  Reporter:  rshepard  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:  locaton wizard, .prj file
   CPU:  x86-32|   Platform:  Linux
---+---

Comment (by neteler):

 {{{
 # write out user's WKT string as .prj file
 echo
 
'PROJCS["NAD_1983_UTM_Zone_11N",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETER["false_northing",0],UNIT["Meter",1]]'
 > bla.prj

 # attempt to generate a new location from it:
 grass77 -c bla.prj  ~/grassdata/mylocation
 Starting GRASS GIS...
 Creating new GRASS GIS location ...
 ERROR: ERROR 4: `bla.prj' not recognized as a supported file format.
 ERROR: Unable to read georeferenced file  using GDAL library
 }}}


 I checked further and found a difference between g.proj and
 gdalsrsinfo opening files:

 general/g.proj/input.c, line 271 :
 (inofficially: https://github.com/GRASS-GIS/grass-
 ci/blob/master/general/g.proj/input.c#L271)

 {{{
 if ((gdal_ds = GDALOpen(geofile, GA_ReadOnly))) {
 }}}

 apps/gdalsrsinfo.cpp, line 306
 https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalsrsinfo.cpp#L306

 {{{
 poGDALDS = static_cast(GDALOpenEx( pszInput, 0,
 nullptr, nullptr, nullptr ));
 }}}


 It seems that GDALOpenEx() is more flexible concerning the input (it
 exists since GDAL 2.0):
 https://www.gdal.org/classGDALDataset.html#a9cb8585d0b3c16726b08e25bcc94274a

 Perhaps g.proj could be updated accordingly?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1481: v.in.ogr with postgis layers fails if the table schema is on the first place in the search_path of the database

2019-02-09 Thread GRASS GIS
#1481: v.in.ogr with postgis layers fails if the table schema is on the first
place in the search_path of the database
-+---
  Reporter:  tomdb   |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.7
 Component:  Vector  |Version:  6.4.1
Resolution:  worksforme  |   Keywords:  v.in.ogr, postgis
   CPU:  x86-32  |   Platform:  Linux
-+---
Changes (by martinl):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Works in G76

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults

2019-02-09 Thread GRASS GIS
#2643: d.vect png with icon=basic/circle and long paths segfaults
-+-
  Reporter:  pertusus|  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  major   |  Milestone:  7.0.7
 Component:  Display |Version:  svn-releasebranch70
Resolution:  worksforme  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Not able to reproduce with G76.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Memory consumption using pygrass.utils.get_raster_for_points

2019-02-09 Thread Steven Pawley
Hello devs,

When running pygrass.utils.get_raster_for_points repeatedly, it appears
that the python memory allocation continuously increases until all ram is
consumed, even if the extracted values are not being collected (or are
overwriting the same variable).

I noticed this when extracting raster data at point locations, when using a
large point dataset, even though I had pre-allocated a numpy array to
receive the results.

Below is an example on the nc_spm_08_grass7 example data (in the landsat
mapset), repeating the operation say 50 times on the same point vector
dataset. I wouldn't have expected the memory consumption to continuously
increase for this operation, because I'm overwriting the 'arr' variable
each time. However, if you repeat this enough times, you will run out of
system memory and the allocated memory does not appear to be released, i.e.
even if you manually force garbage collection.

Any suggestions?


from grass.pygrass.vector import VectorTopo
from grass.pygrass.raster import RasterRow
from grass.pygrass.modules.shortcuts import raster as r
from grass.pygrass.gis.region import Region
from grass.pygrass.utils import get_raster_for_points

reg = Region()
reg.from_rast("landclass96")
reg.write()
reg.set_raster_region()

r.random(input="landclass96", npoints=20, vector="landclass96_roi",
 overwrite=True)

points = VectorTopo("landclass96_roi")
points.open("r")

# repeat spatial query of raster
for i in range(50):
with RasterRow("lsat5_1987_10") as src:
arr = get_raster_for_points(points, src)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Memory consumption using pygrass.utils.get_raster_for_points

2019-02-09 Thread Steven Pawley

Hello devs,

When running pygrass.utils.get_raster_for_points repeatedly, it appears 
that the python memory allocation continuously increases until all ram 
is consumed, even if the extracted values are not being collected (or 
are overwriting the same variable).


I noticed this when extracting raster data at point locations, when 
using a large point dataset, even though I had pre-allocated a numpy 
array to receive the results.


Below is an example on the nc_spm_08_grass7 example data (in the landsat 
mapset), repeating the operation say 50 times on the same point vector 
dataset. I wouldn't have expected the memory consumption to continuously 
increase for this operation, because I'm overwriting the 'arr' variable 
each time. However, if you repeat this enough times, you will run out of 
system memory and the allocated memory does not appear to be released, 
i.e. even if you manually force garbage collection.


Any suggestions?


from grass.pygrass.vector import VectorTopo
from grass.pygrass.raster import RasterRow
from grass.pygrass.modules.shortcuts import raster as r
from grass.pygrass.gis.region import Region
from grass.pygrass.utils import get_raster_for_points

reg = Region()
reg.from_rast("landclass96")
reg.write()
reg.set_raster_region()

r.random(input="landclass96", npoints=20, vector="landclass96_roi",
 overwrite=True)

points = VectorTopo("landclass96_roi")
points.open("r")

# repeat spatial query of raster
for i in range(50):
    with RasterRow("lsat5_1987_10") as src:
    arr = get_raster_for_points(points, src)

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

Re: [GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new location

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new
location
---+---
  Reporter:  rshepard  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:  locaton wizard, .prj file
   CPU:  x86-32|   Platform:  Linux
---+---

Comment (by hellik):

 Replying to [ticket:3750 rshepard]:
 > Trying to create a new location using a shapefile .prj. GRASS tells me
 it annot read the file using gdal.

 for me it works with the GUI location wizard; see attached screenshot to
 choose the option ''read projection from a .prj file''.

 >
 > Markus N. confirms this and recommends using the .shp file instead.

 that's the option read projection from a georeferenced file.
 >
 > Setting the location's projection on the command line works, but not
 from the GUI. The 2019-02-09 thread has more details.

 isn't it the other way around?

 CLI with .prj file doesn't work, but GUI with .prj file works.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new location

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new
location
---+---
  Reporter:  rshepard  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:  locaton wizard, .prj file
   CPU:  x86-32|   Platform:  Linux
---+---
Changes (by hellik):

 * Attachment "location_wizard.PNG" added.

 location wizard - read prj file

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new location

2019-02-09 Thread GRASS GIS
#3750: Grass 7.7.svn (r74061): GUI location widget cannot read .prj file for new
location
---+-
 Reporter:  rshepard   |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:
Component:  wxGUI  |Version:  svn-trunk
 Keywords:  locaton wizard, .prj file  |CPU:  x86-32
 Platform:  Linux  |
---+-
 Trying to create a new location using a shapefile .prj. GRASS tells me it
 annot read the file using gdal.

 Markus N. confirms this and recommends using the .shp file instead.

 Setting the location's projection on the command line works, but not from
 the GUI. The 2019-02-09 thread has more details.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-user] Unable to read .prj file

2019-02-09 Thread Markus Neteler
(adding grass-dev)

On Sat, Feb 9, 2019 at 11:14 AM Markus Neteler  wrote:
> On Sat, Feb 9, 2019 at 10:57 AM Helmut Kudrnovsky  wrote:
> >
> > >Just the GRASS GIS logics (still) prevent from accepting a .prj file as
> > input.
> >
> > at least in the GUI and the location wizzard you can use a .prj-file to
> > create a new location.
>
> Yes but not on the beloved command line:
>
> grass77 -c bla.prj  ~/grassdata/mylocation
> Starting GRASS GIS...
> Creating new GRASS GIS location ...
> ERROR: ERROR 4: `bla.prj' not recognized as a supported file format.
> ERROR: Unable to read georeferenced file  using GDAL library

I checked further and found a difference between g.proj and
gdalsrsinfo opening files:

general/g.proj/input.c, line 271 :
(inofficially: 
https://github.com/GRASS-GIS/grass-ci/blob/master/general/g.proj/input.c#L271)

if ((gdal_ds = GDALOpen(geofile, GA_ReadOnly))) {

apps/gdalsrsinfo.cpp, line 306
https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalsrsinfo.cpp#L306

poGDALDS = static_cast(GDALOpenEx( pszInput, 0,
nullptr, nullptr, nullptr ));

It seems that GDALOpenEx() is more flexible concerning the input (it
exists since GDAL 2.0):
https://www.gdal.org/classGDALDataset.html#a9cb8585d0b3c16726b08e25bcc94274a

Perhaps g.proj should be updated accordingly?

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

Re: [GRASS-dev] GSoC 2019 Idea: Continuous Fuzzing for GRASS GIS to uncover software bugs

2019-02-09 Thread Even Rouault
Note that OSS-Fuzz only supports C/C++ libs. Not Python
Fuzzed binaries must statically link all their dependencies:
https://github.com/google/oss-fuzz/blob/master/docs/fuzzer_environment.md

Even

> Hi,
> 
> here an idea for https://trac.osgeo.org/grass/wiki/GSoC/2019
> 
> Since I am not the right person to follow a student on this, I put it here:
> 
> === Continuous Fuzzing for GRASS GIS to uncover software bugs ===
> 
>  * TL;DR: Fuzz testing is a well-known technique for uncovering
> various kinds of programming errors in software. Many of these
> detectable errors (e.g. buffer overflow) can have serious security
> implications. The student will make GRASS GIS ready for OSS-Fuzz.
>   * https://github.com/google/oss-fuzz OSS-Fuzz - Continuous Fuzzing
> for Open Source Software
>  * Requirements:
>   * Student needs to show understanding of the GRASS GIS software
> structure and significantly extend on text above in the proposal.
>   * Language: Python, C
>  * Mentors: ...
>  * Co-mentors: ...
>  * Proposed by: ...
> 
> Here the full template to be used:
> https://lists.osgeo.org/pipermail/discuss/2019-February/038233.html
> 
> Maybe someone here would like to take over to write up the idea properly?
> 
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3749: winGRASS7.7.svn python 3: GUI freezes at start

2019-02-09 Thread GRASS GIS
#3749: winGRASS7.7.svn python 3: GUI freezes at start
--+
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  critical |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:  worksforme   |   Keywords:  python3, py3, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows
--+
Changes (by hellik):

 * status:  new => closed
 * resolution:   => worksforme


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3749: winGRASS7.7.svn python 3: GUI freezes at start

2019-02-09 Thread GRASS GIS
#3749: winGRASS7.7.svn python 3: GUI freezes at start
--+
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  python3, py3, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows
--+

Comment (by hellik):

 Replying to [comment:3 martinl]:
 > I am just note sure that this message relates to freezing. The GUI pops
 up on my testing Windows machine (even with this message printed out).

 closing ticket; as it seems that some windows updating processes caused
 the freezing. GUI is opening now.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3749: winGRASS7.7.svn python 3: GUI freezes at start

2019-02-09 Thread GRASS GIS
#3749: winGRASS7.7.svn python 3: GUI freezes at start
--+
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  python3, py3, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows
--+

Comment (by martinl):

 I am just note sure that this message relates to freezing. The GUI pops up
 on my testing Windows machine (even with this message printed out).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3749: winGRASS7.7.svn python 3: GUI freezes at start

2019-02-09 Thread GRASS GIS
#3749: winGRASS7.7.svn python 3: GUI freezes at start
--+
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  python3, py3, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows
--+

Comment (by neteler):

 Here is some (un)related discussion about fixing the usage of wx.Yield(),
 maybe helpful?

 https://groups.google.com/forum/#!msg/wxpython-
 users/lMyQuXGTE5I/dMu0Ca4SDAAJ

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GSoC 2019 Idea: Continuous Fuzzing for GRASS GIS to uncover software bugs

2019-02-09 Thread Markus Neteler
Hi,

here an idea for https://trac.osgeo.org/grass/wiki/GSoC/2019

Since I am not the right person to follow a student on this, I put it here:

=== Continuous Fuzzing for GRASS GIS to uncover software bugs ===

 * TL;DR: Fuzz testing is a well-known technique for uncovering
various kinds of programming errors in software. Many of these
detectable errors (e.g. buffer overflow) can have serious security
implications. The student will make GRASS GIS ready for OSS-Fuzz.
  * https://github.com/google/oss-fuzz OSS-Fuzz - Continuous Fuzzing
for Open Source Software
 * Requirements:
  * Student needs to show understanding of the GRASS GIS software
structure and significantly extend on text above in the proposal.
  * Language: Python, C
 * Mentors: ...
 * Co-mentors: ...
 * Proposed by: ...

Here the full template to be used:
https://lists.osgeo.org/pipermail/discuss/2019-February/038233.html

Maybe someone here would like to take over to write up the idea properly?

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

Re: [GRASS-dev] [GRASS GIS] #3749: winGRASS7.7.svn python 3: GUI freezes at start

2019-02-09 Thread GRASS GIS
#3749: winGRASS7.7.svn python 3: GUI freezes at start
--+
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  python3, py3, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows
--+
Changes (by hellik):

 * priority:  normal => critical


-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3749: winGRASS7.7.svn python 3: GUI freezes at start

2019-02-09 Thread GRASS GIS
#3749: winGRASS7.7.svn python 3: GUI freezes at start
+-
 Reporter:  hellik  |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.8.0
Component:  wxGUI   |Version:  svn-trunk
 Keywords:  python3, py3, wingrass  |CPU:  Unspecified
 Platform:  MSWindows   |
+-
 tested with

 {{{
 GRASS GIS 7.7.svn (r74061M)
 }}}

 wxGUI freezes at start up with following message:

 {{{
 C:\>g.gui wxpython
 Starte  GUI im Hintergrund. Bitte warten Sie ...
 C:\OSGEO4~1\apps\grass\grass77/gui/wxpython/wxgui.py:98:
 DeprecationWarning: Yield() is deprecated
   wx.Yield()
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] FOSS4G 2019 Bucharest Call for Contributions Open

2019-02-09 Thread Markus Neteler
On Fri, Jan 25, 2019 at 11:48 AM Moritz Lennert
 wrote:
>
> Who else will come to Bucharest ? Anyone willing to (co-)organise a
> workshop ?
>
> What topics would users find the most useful for a workshop ?


Hi,

I plan to submit a workshop on "actinia" [1, 2] - geoprocessing in the
cloud with GRASS GIS and REST API.
So, that's of course GRASS related but strictly a GRASS workshop.

Best,
Markus

[1] https://actinia.mundialis.de/
[2] https://github.com/mundialis/actinia_core/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev