Re: [GRASS-dev] GRASS GIS twitter account - was: Re: Fwd: [mapserver-users] new official twitter account

[Markus Neteler]

On Sat, Jul 22, 2017 at 4:11 PM, Markus Neteler  wrote:
> On Sat, Jul 22, 2017 at 2:43 PM, Vaclav Petras  wrote:
>> On Sat, Jul 22, 2017 at 5:24 AM, Luca Delucchi  wrote:
...
>> Last week or so, he gave
>> access to it through TweetDeck and he can give it to you as well. With
>> TweetDeck, I can now tweet and also delete old tweets. However, I don't have
>> a full access to the account and can't change name, banner, add people to
>> TweetDeck, etc. (Jorge has).
>>
>> https://twitter.com/GRASSGIS
>
> Great, that some progress has been made here. Looking forward to the
> cleanup of the remaining issues.
> Thanks for your support, Jorge!

... thanks for granting admin access to the account, Jorge!

Markus

-- 
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Inclusion of additional files with add-on

[Steven Pawley]

Thanks Helmut,

I have gone with your's and Moritz's suggestion and have completed 
r.terrain.texture with the Iwahashi and Pike nested-means terrain 
classification method in the add-ons.

Best regards,

Steve

Sent from my iPhone

On Aug 12, 2017, at 2:22 PM, Helmut Kudrnovsky  wrote:

>> (I also have three files representing color rules, and three category >files
> that are applied to the 8, 12 or 16 terrain classification >results)
> 
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.euro.ecosystem/r.euro.ecosystem.py#L72
> 
> an example where I've embeded color and category rules in the script. 
> 
> 
> 
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Inclusion-of-additional-files-with-add-on-tp5331342p5331362.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.register encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:14 mlennert]:
 >
 > Just the line
 >
 >
 > {{{
 > self.connection.text_factory = str
 > }}}
 >
 > already suffices to solve the above-mentioned issues

 But it only works with Python2. With Python3, I get:


 {{{
 python --version
 Python 3.5.4rc1

 t.create output=tempmean type=strds temporaltype=absolute title="Average
 temperature" description="Monthly temperature average in NC [deg C]"
 Traceback (most recent call last):
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/scripts/t.create", line 86, in 
 main()
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/scripts/t.create", line 68, in main
 import grass.temporal as tgis
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/temporal/__init__.py", line 3, in 
 from .core import *
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/temporal/core.py", line 44, in 
 from .c_libraries_interface import *
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/temporal/c_libraries_interface.py", line 27, in
 
 from grass.pygrass.rpc.base import RPCServerBase
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/pygrass/rpc/__init__.py", line 21, in 
 from grass.pygrass.vector import *
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/pygrass/vector/__init__.py", line 6, in 
 libgis.G_gisinit('')
   File "/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/lib/gis.py", line 3553, in G_gisinit
 return (G__gisinit (GIS_H_VERSION, pgm))
 ctypes.ArgumentError: argument 1: : wrong type
 }}}

 But then again, the same happens without Anna's patch, so this is a
 different issue.

 That's probably a point to keep in mind for a future code sprint:
 systematically test with python 3 and debug the issues...

--
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] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.register encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:13 zarch]:
 > Hi Anna,
 >
 > Replying to [comment:12 annakrat]:
 > > The problem mostly comes from calling gisenv function from
 script.utils which returns unicode. This was done some time ago to make
 the library Python3 compatible. So we eventually need to move towards
 unicode, but to have a quick fix for the release, we can keep the temporal
 library using bytestrings.
 >
 >
 > I didn't have time to test your solution yet.
 >
 > Actually for me it is still not clear where should we use `unicode` and
 where `bytes`.
 > Do you have some general guidelines?
 >
 > In the changes that I did, I transformed everything in bytes, and now
 the tests that I added to reproduce the ticket's error are passing, so the
 ticket is "theoretically" fixed.

 Using only the temporal_encode.patch​ you uploaded this morning and
 applying it to a fresh svn tree, I still get the same error with
 t.register and the weird output of t.info and t.topology. t.remove and
 t.unregister do not throw an error when run in that order, but when I run
 t.unregister before running t.remove I get the same error.

 Also, there is a lot of code such as this:


 {{{
  print("nsres_min=" + encode(self.get_nsres_min()))
  print("nsres_max=" + encode(self.get_nsres_max()))
  print("ewres_min=" + encode(self.get_ewres_min()))
  print("ewres_max=" + encode(self.get_ewres_max()))
 }}}

 and


 {{{
 string += encode(id) + fs + encode(start) + fs + encode(end)
 string += fs + encode(stats["mean"]) + fs + encode(stats["min"])
 string += fs + encode(stats["max"]) + fs + encode(stats["mean_of_abs"])
 string += fs + encode(stats["stddev"]) + fs + encode(stats["variance"])
 string += fs + encode(stats["coeff_var"]) + fs + encode(stats["sum"])
 string += fs + encode(stats["null_cells"]) + fs + encode(stats["cells"])
 }}}

 All the info transformed to strings here are numeric values that come from
 within the module. I don't think we should ever encode such values, or ?

--
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] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.register encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:12 annakrat]:
 > The problem mostly comes from calling gisenv function from script.utils
 which returns unicode.

 So you are saying that this has nothing to do with translated message
 strings ?

 >This was done some time ago to make the library Python3 compatible. So we
 eventually need to move >towards unicode, but to have a quick fix for the
 release, we can keep the temporal library using >bytestrings. This is a
 possible solution:
 >
 >
 > {{{
 > Index: lib/python/temporal/core.py
 > ===
 > --- lib/python/temporal/core.py   (revision 71395)
 > +++ lib/python/temporal/core.py   (working copy)
 > @@ -542,9 +542,9 @@
 >  grassenv = gscript.gisenv()
 >
 >  # Set the global variable for faster access
 > -current_mapset = grassenv["MAPSET"]
 > -current_location = grassenv["LOCATION_NAME"]
 > -current_gisdbase = grassenv["GISDBASE"]
 > +current_mapset = gscript.encode(grassenv["MAPSET"])
 > +current_location = gscript.encode(grassenv["LOCATION_NAME"])
 > +current_gisdbase = gscript.encode(grassenv["GISDBASE"])
 >
 >  # Check environment variable GRASS_TGIS_RAISE_ON_ERROR
 >  if os.getenv("GRASS_TGIS_RAISE_ON_ERROR") == "True" or \
 > @@ -1107,6 +1107,7 @@
 >  detect_types=self.dbmi.PARSE_DECLTYPES |
 self.dbmi.PARSE_COLNAMES)
 >  self.connection.row_factory = self.dbmi.Row
 >  self.connection.isolation_level = None
 > +self.connection.text_factory = str
 >  self.cursor = self.connection.cursor()
 >  self.cursor.execute("PRAGMA synchronous = OFF")
 >  self.cursor.execute("PRAGMA journal_mode = MEMORY")
 >
 > }}}
 >

 Just the line


 {{{
 self.connection.text_factory = str
 }}}

 already suffices to solve the above-mentioned issues (and I've gone a bit
 further in the tutorial and tested a series of other t.* modules, but
 haven't encountered any other error) but it's better to also protect
 against non-ascii gisdbase variables which wasn't an issue here for me.

 Thanks Anna !!

 I have to admit that I have no idea how this works. Some form of
 documentation of the entire system would be very helpful, in line with
 what Pietro said.

 > plus all gisenv calls in temporal modules need to be encoded to not let
 any unicode into the library. I would appreciate if somebody could test it
 more thoroughly. This would be a temporary solution, we need to move to
 unicode eventually, but I think that would require more time to fix and
 more significant changes.

 Can we at least already commit this small change which already makes a big
 difference ?

 > Also, this works only for sqlite3 backend, I haven't looked at
 postgres...

 How does the database backend come in when dealing with these strings ?

 Moritz

--
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] GRASS GIS 7.2.2RC1 has been released

[Martin Landa]

Hi,

2017-08-14 13:55 GMT+02:00 Moritz Lennert :
> Could this be posted ont he web site as well ? Makes it easier to point
> to the info on social networks...

personally I would suggest to publish news only about release, not RC.
Publishing on ML about RC should enough. Ma

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

Re: [GRASS-dev] [GRASS-user] GRASS GIS 7.2.2RC1 has been released

[Moritz Lennert]

Could this be posted ont he web site as well ? Makes it easier to point
to the info on social networks...

Moritz

Le Fri, 11 Aug 2017 11:34:47 +0200,
Markus Neteler  a écrit :

> We are pleased to announce the first release candidate of GRASS GIS
> 7.2.2 (7.2.2RC1) has been published. It provides more than 80 fixes
> and improvements with respect to GRASS GIS 7.2.1 including an
> important update for GCC7 support.
> 
> >>> Testing is welcome! <<<  
> 
> * Release notes: https://trac.osgeo.org/grass/wiki/Release/7.2.2-News
> 
> * Source code:
> http://grass.osgeo.org/grass72/source/grass-7.2.2RC1.tar.gz
> 
> * Changelog:
> http://grass.osgeo.org/grass72/source/ChangeLog_7.2.2RC1.gz
> 
> * Binaries:
>   * Windows binaries are available for testing at
>  https://grass.osgeo.org/grass72/binary/mswindows/native/
>   * OSGeo4W package have been uploaded (you need to mark `Exp` box).
>   * Linux: forthcoming
> 
> 
> About GRASS GIS
> 
> The Geographic Resources Analysis Support System
> (https://grass.osgeo.org/), commonly referred to as GRASS GIS, is an
> Open Source Geographic Information System providing powerful raster,
> vector and geospatial processing capabilities in a single integrated
> software suite. GRASS GIS includes tools for spatial modeling,
> visualization of raster and vector data, management and analysis of
> geospatial data, and the processing of satellite and aerial imagery.
> It also provides the capability to produce sophisticated presentation
> graphics and hardcopy maps. GRASS GIS has been translated into about
> twenty languages and supports a huge array of data formats. It can be
> used either as a stand-alone application or as backend for other
> software packages such as QGIS and R geostatistics. It is distributed
> freely under the terms of the GNU General Public License (GPL). GRASS
> GIS is a founding member of the Open Source Geospatial Foundation
> (OSGeo).
> 
> The GRASS Development Team, Aug 2017
> ___
> 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] [release planning] GRASS GIS 7.2.2

[Martin Landa]

2017-08-14 12:04 GMT+02:00 Martin Landa :
> 2017-08-14 11:54 GMT+02:00 Martin Landa :
>> C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/bin/r.in.lidar.exe:
>> error while loading shared libraries: libgrass_raster.7.3.svn.dll:
>> cannot open shared object file: No such file or directory

it's seems to be magically fixed be reinstalling msvcrt2013 package.
Will wait for the next build. Ma

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.2

[Martin Landa]

Hi,

2017-08-14 12:55 GMT+02:00 Markus Neteler :
> Some feedback:
> I have tested the OSGeo4W package on 32bit Windows 8.1 [2] : seems to
> work fine including NVIZ.

thanks for testing. Ma

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.2

[Markus Neteler]

On Fri, Aug 11, 2017 at 11:26 AM, Martin Landa  wrote:
> 2017-08-11 11:04 GMT+02:00 Markus Neteler :
>> RC1 is available:
>> https://trac.osgeo.org/grass/wiki/Release/7.2.2-News#ReleaseCandidate1RC1
>>
>> Binaries and announcements work in progress...
>
> Windows binaries are available for testing [1], also OSGeo4W package
> uploaded (you need to mark `Exp` box).

Some feedback:
I have tested the OSGeo4W package on 32bit Windows 8.1 [2] : seems to
work fine including NVIZ.


> [1] https://grass.osgeo.org/grass72/binary/mswindows/native/

[2] VMs for download:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.2

[Martin Landa]

2017-08-11 17:05 GMT+02:00 Martin Landa :
> Hi,
>
> 2017-08-11 15:59 GMT+02:00 Anna Petrášová :
>> I tested 64bit version on windows 10 and it works for me, but lidar
>> tools are missing.
>
> you are right, I have accidentally disabled las support also on 64bit
> platform. Unfortunately building server is not accessible since
> 15:00CET (at least for two days) due to network reconfiguration at
> CTU. Should be fixed in trunk (r71392). I will do backport later when
> first G73 64bit build will be published (probably on Monday). Ma

well, it broke [1] 64bit even few days ago it worked [2]. No changes
in buliding envirnment since then. Windows mystery, I am lost, any
idea?

C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/bin/r.in.lidar.exe:
error while loading shared libraries: libgrass_raster.7.3.svn.dll:
cannot open shared object file: No such file or directory

Ma

[1] https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71395-321/package.log
[2] https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71337-316/package.log

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.2

[Martin Landa]

2017-08-14 11:54 GMT+02:00 Martin Landa :
> C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/bin/r.in.lidar.exe:
> error while loading shared libraries: libgrass_raster.7.3.svn.dll:
> cannot open shared object file: No such file or directory

of course the library exists

$ file 
/c/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/lib/libgrass_raster.7.3.svn.dll
/c/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/lib/libgrass_raster.7.3.svn.dll:
PE32+ executable (DLL) (console) x86-64, for MS Windows

and

/c/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/lib

is in the path. Other raster modules do not fail. Only those with LAS
support. Ma

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