date:20180302

Re: [GRASS-dev] [GRASS-PSC] planning releases - spring 2018

2018-03-02 Thread Michael Barton

I hope that the non-functional digitizer and semi-functional pull-down control 
can be fixed for Mac.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 27, 2018, at 3:30 PM, Markus Neteler 
> wrote:

On Tue, Feb 27, 2018 at 10:14 PM, Martin Landa 
> wrote:
Hi,

major release 7.4.0 is almost one month old, we should think about
time schedule for a next releases. Assuming that we are trying to
release new (point) version every three/four months, 7.4.1 could be
schedule to May [1].

That's good. Perhaps even earlier? Because I would like to see a new
release with ZSTD compression included since I cannot run trunk in
production and hesitate to heavily patch 7.4. locally. That would be
7.6.0 then.

Yet some backports are open for 7.4.1 [4]

Meanwhile we could also release 7.2.3 [2] (7.2.2 has been released in
16/9/2017). In March or later (see overall of changes [3]), what do
you think?

Yes, a new 7.2.3 release soon as well. Yesterday I submitted a fix it
since it failed to compile on Fedora 28. Some other distros should be
tested as well before releasing (however, that does not take ages).
Maybe that would become the last 7.2.x then? We'll see.

Also some backports are desired here: [5]

While we are at it, I would also package up without big marketing hype
a new 7.0.6 release [6], just to make it an official tarball. It
contains some updates you don't want to miss if still using 7.0 for
whatever reason.

Markus

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_milestone_7.4.1=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=yAC3qoDi2aRkLTakTAOWoCW04wi9b-UMn8XCyao4mPA=
[2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_milestone_7.2.3=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=ALpFL4wguP217QJ81M7V12qpOFULdWpJcpSq_nxX95s=
[3] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_changeset-3Freponame-3D-26new-3D72284-2540grass-252Fbranches-252Freleasebranch-5F7-5F2-26old-3D71497-2540grass-252Fbranches-252Freleasebranch-5F7-5F2=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=LpdQSyCNh1RxeOb6XFKVqKOWaklQ6-ndhAob3gCUpOM=

[4] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_wiki_Grass7Planning-23a7.4.1tobebackported=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=9CUm1iT0HSaGEqdQD2lFxgO8sffPscN3UvzOQjPaHc0=
[5] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_wiki_Grass7Planning-23a7.2.3tobebackported=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=WUkMKjORTS3ciUC1VwNeauZuFK_n9x27SBNxsbcwYtw=
[6] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_milestone_7.0.6=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=zjnek9NRFrIY9FiCiUvNQg8Dj9kdT6mdVXuj4oTH4oE=
___
grass-psc mailing list
grass-...@lists.osgeo.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.osgeo.org_mailman_listinfo_grass-2Dpsc=DwIGaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=xQ__h-TZ2aXaou26BV6e8rnUJAxAmpIdbPv6CyQoxZQ=mCdqd-llBum8Nte19J3ouwbCzWHhgOZ4Vn-wyykM6CE=

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

Re: [GRASS-dev] [GRASS GIS] #774: i.rgb.his, i.his.rgb, d.his support for >8 bit

2018-03-02 Thread GRASS GIS

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
--+-
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  i.rgb.his, i.his.rgb, d.his
   CPU:  All  |   Platform:  All
--+-

Comment (by wenzeslaus):

 Replying to [comment:16 mlennert]:
 > Nikos, how confident are you about your version in the sandbox ? Can it
 replace the version in trunk ?

 This is a computational danger zone, I think also automatic tests are
 required. I suggest to add tests to the modules in trunk and use them to
 test the new modules (whether they are in sandbox or addons).

-- 
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] #774: i.rgb.his, i.his.rgb, d.his support for >8 bit

2018-03-02 Thread GRASS GIS

#774: i.rgb.his, i.his.rgb, d.his support for >8 bit
--+-
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  i.rgb.his, i.his.rgb, d.his
   CPU:  All  |   Platform:  All
--+-
Changes (by neteler):

 * version:  svn-develbranch6 => svn-trunk


Comment:

 Replying to [comment:17 Nikos Alexandris]:
 > The statistics in https://trac.osgeo.org/grass/ticket/774#comment:13,
 show that going from either an 8-bit or 16-bit RGB to HIS and back to RGB,
 figures are not scrambled. Some rounding applies, as exemplified in the
 same stats above.  Even visually, I confirmed (not documented here) that
 the old and the new versions perform the same.

 This sounds very promising.

 > It will break i.pansharpen, unless i.pansharpen treats intensity ranging
 in [0,1].

 Would it be hard to add that to i.pansharpen?

 > Nevertheless, another set of tests would be certainly good to have to
 confirm the correctness of the new version.

 I'd suggest to "svn move" it from sandbox to addons for wider testing with
 g.extention.

-- 
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] #3509: g.region grow with negative number limited because of top and bottom

2018-03-02 Thread GRASS GIS

#3509: g.region grow with negative number limited because of top and bottom
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  minor   |  Milestone:  7.6.0
 Component:  Raster  |Version:  svn-trunk
Resolution:  |   Keywords:  grow, shrink, g.region, expand
   CPU:  |  computational region, extent, 3D
  Unspecified|   Platform:  Unspecified
-+-
Changes (by neteler):

 * milestone:  7.4.1 => 7.6.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] #789: g.region option to expand the computational region of about "some" pixels?

2018-03-02 Thread GRASS GIS

#789: g.region option to expand the computational region of about "some" pixels?
-+-
  Reporter:  nikos   |  Owner:  grass-dev@…
  Type:  | Status:  closed
  enhancement|
  Priority:  normal  |  Milestone:  7.4.1
 Component:  Default |Version:  unspecified
Resolution:  fixed   |   Keywords:  g.region, expand computational
   CPU:  |  region
  Unspecified|   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 I did the change in r72296. Here is a diff of only the naming change:

 {{{
 #!diff
 Index: main.c
 ===
 --- main.c  (revision 72295)
 +++ main.c  (working copy)
 @@ -337,13 +337,15 @@
  parm.pixels = G_define_option();
 -parm.pixels->key = "pixels";
 +parm.pixels->key = "grow";
  parm.pixels->key_desc = "value";
  parm.pixels->required = NO;
  parm.pixels->multiple = NO;
  parm.pixels->type = TYPE_INTEGER;
 -parm.pixels->description =
 -_("Number of pixels to increase the bounding box");
 +parm.pixels->label =
 +   _("Number of cells to add to each side of the current region
 extent");
 +parm.pixels->description =
 +   _("A negative number shrinks the current region extent");
  parm.pixels->guisection = _("Bounds");
 }}}

 The is an issue with shrinking now reported in #3509.

-- 
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] #3509: g.region grow with negative number limited because of top and bottom

2018-03-02 Thread GRASS GIS

#3509: g.region grow with negative number limited because of top and bottom
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  minor|  Milestone:  7.4.1
Component:  Raster   |Version:  svn-trunk
 Keywords:  grow, shrink, g.region, expand   |CPU:  Unspecified
  computational region, extent, 3D   |
 Platform:  Unspecified  |
-+-
 Here is what happens if you want to shrink region (grow < 0):

 {{{
 g.region -p raster=elevation
 g.region -p grow=-1
 # ERROR: Top must be larger than Bottom
 g.region -p grow=2
 g.region -p grow=-1
 g.region -p grow=-1
 g.region -p grow=-1
 # ERROR: Top must be larger than Bottom
 }}}

 When you have small depth (1 by default) you can't do `grow=-1`.

 ''Please, add milestone 7.6.''

-- 
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] #3508: grass start up: buggy to_text_string

2018-03-02 Thread GRASS GIS

#3508: grass start up: buggy to_text_string
--+---
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.3
 Component:  Startup  |Version:  svn-trunk
Resolution:   |   Keywords:  wingrass, unicode
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 I think this is a classical case of it being better not to mess around
 with the original byte string. All we do is taking a string from an
 environment variable, adding two new path elements and putting it back
 into another environment variable:

 {{{
 addon_base = os.getenv('GRASS_ADDON_BASE')
 [...]
 addons_man_path = os.path.join(addon_base, 'docs', 'man')
 os.environ['MANPATH'] = to_text_string(addons_man_path)
 }}}

 Do we really have to worry about encoding/decoding in that context ?

-- 
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] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

2018-03-02 Thread GRASS GIS

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.in.spotvgt bands
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mlennert):

 I've just attached the patch provided by Tudor. It allows importing any
 band, one by one. Probably more in line with the KISS principle than my
 patch trying to loop over all files.

 Any opinions from SPOT users out there ?

-- 
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] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

2018-03-02 Thread GRASS GIS

#3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.in.spotvgt bands
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by mlennert):

 * Attachment "i_in_spotvgt_any_band.diff" added.

 patch that allows importing any band (one by one) - provided by Tudor-Emil
 Coman

-- 
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] #3508: grass start up: buggy to_text_string

2018-03-02 Thread GRASS GIS

#3508: grass start up: buggy to_text_string
--+---
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.3
 Component:  Startup  |Version:  svn-trunk
Resolution:   |   Keywords:  wingrass, unicode
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Right. The code is similar to `_get_encoding()/decode()/encode()` group in
 source:grass/trunk/lib/python/script/utils.py#L159 from r65787. Do these
 functions work for you (assuming you can get around the startup issue)?
 All is basically based around `locale.getdefaultlocale()[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] #3508: grass start up: buggy to_text_string

2018-03-02 Thread GRASS GIS

#3508: grass start up: buggy to_text_string
--+---
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.3
 Component:  Startup  |Version:  svn-trunk
Resolution:   |   Keywords:  wingrass, unicode
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by martinl):

 `to_text_string` has been introduced 3 years ago in r65780

-- 
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] #3050: Set size in d.northarrow

2018-03-02 Thread GRASS GIS

#3050: Set size in d.northarrow
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  minor   |  Milestone:  7.4.1
 Component:  Display |Version:  svn-trunk
Resolution:  |   Keywords:  d.northarrow, cartography, gsoc2016
   CPU:  |   Platform:  Unspecified
  Unspecified|
-+-

Comment (by annakrat):

 No, it's still valid problem. But I am not sure which is the right
 solution at this point.

-- 
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] #3508: grass start up: buggy to_text_string

2018-03-02 Thread GRASS GIS

#3508: grass start up: buggy to_text_string
--+---
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.3
 Component:  Startup  |Version:  svn-trunk
Resolution:   |   Keywords:  wingrass, unicode
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by martinl):

 * priority:  normal => blocker


-- 
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] #3177: Automatically register addons in GUI

2018-03-02 Thread GRASS GIS

#3177: Automatically register addons in GUI
--+--
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  minor|  Milestone:  7.4.1
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:  g.extension,Makefile
   CPU:  Unspecified  |   Platform:  All
--+--

Comment (by annakrat):

 Replying to [comment:3 hellik]:
 > Replying to [comment:2 martinl]:
 > > Already done, Addons are visible in Modules tab (after restarting the
 GUI). Time to close this issue?
 >
 > AFAIK only C addons are added to the Modules tab, but not python addons;
 behaviour seen in winGRASS.

 I am not sure if there is a separate ticket for this, but I looked at the
 problem and I don't quite understand the logic behind it. Basically when
 scanning for available addons, the toolboxes run g.extension -ag and look
 if "executable" exists. For Python scripts it's not there:

 {{{
 grass.read_command('g.extension', quiet=True, flags='ag')
 name=r.lake.series
 description=Fills lake at given point(s) to given levels.
 keywords=raster,hydrology,hazard,flood
 executables=
 name=r.stream.distance
 description=Calculates distance to and elevation above streams and outlet.
 The module can work in stream mode where target are streams and outlets
 mode where targets are outlets.
 keywords=raster,hydrology,stream network,watercourse distance
 executables=r.stream.distance
 name=i.superpixels.slic
 description=Perform image segmentation using the SLIC segmentation method.
 keywords=imagery,segmentation,superpixels,SLIC
 executables=i.superpixels.slic
 }}}

 So the question is why the executable is not there, which is in
 g.extension:
 
https://trac.osgeo.org/grass/browser/grass/trunk/scripts/g.extension/g.extension.py#L413

 I don't understand the condition there to exclude scripts folder on
 windows.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GSOC 2018] - Implement a series of image fusion algorithms in GRASS GIS

2018-03-02 Thread Moritz Lennert


Hi Tudor,

Great to have you on board !

On 02/03/18 10:35, Tudor-Emil COMAN (25633) wrote:
I'm very interested in working this summer for a project I have seen 
proposed
on the GSOC 2018 idea page regarding the development of image fusion 
algorithms.
An already existing fusion algorithm is the High-Pass Filter Addition 
technique
implemented in the i.fusion.hpf module [1]. The scope of the project 
would be

to expand the capabilities of GRASS to combine data from different sensors.


As note to other developers: Tudor has already sent me off-list a patch 
to i.in.spotvgt to respond to bug #3186 [1]. I still have to test it 
before applying, but if anyone else is interested, contact me.




The first algorithm I would implement is based on Nicolas Brodu's paper 
named

Super-resolving multiresolution images with band-independant geometry of
multispectral pixels [2]. The algorithm presented in this paper would 
increase

the resolution of certain low resolution bands by inferring some geometric
characteristics from high resolution bands. As opposed to the already 
existing

HPFA fusion method, this one does not require a panchromatic band making it
suitable for satellites that do not produce panchromatic bands.

I'm sure some other fusion algorithms are needed in GRASS-GIS that are 
not yet
implemented. I'm interested in suggestions about such algorithms so that 
I can

read about them and incorporate them into my final proposal.


Be sure to also look at the R-FUSE algorithm [2] mentioned on the GSoC 
ideas page.


In general, I think that general algorithms such as those two, that do 
not linked to sensor specificities would be great.


This said, IIRC i.pansharpen currently has limits in terms of applying 
the classical algorithms to images encoded in more than 8 bits. 
Improving this (implying changes to the underlying modules) might be 
another element of the GSoC project.


Moritz


[1] https://trac.osgeo.org/grass/ticket/3186
[2] http://oatao.univ-toulouse.fr/16629/7/wei_16629.pdf
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3508: grass start up: buggy to_text_string

2018-03-02 Thread GRASS GIS

#3508: grass start up: buggy to_text_string
---+-
 Reporter:  martinl|  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:  7.2.3
Component:  Startup|Version:  svn-trunk
 Keywords:  wingrass, unicode  |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 GRASS fails even start on Windows when username contains non-ascii
 characters

 {{{
 Traceback (most recent call last):
   File "C:\Program Files\GRASS GIS 7.4.0\etc\grass74.py", line 2003, in
 
 main()
   File "C:\Program Files\GRASS GIS 7.4.0\etc\grass74.py", line 1854, in
 main
 set_paths(grass_config_dir=grass_config_dir)
   File "C:\Program Files\GRASS GIS 7.4.0\etc\grass74.py", line 620, in
 set_paths
 os.environ['MANPATH'] = to_text_string(addons_man_path)
   File "C:\Program Files\GRASS GIS 7.4.0\Python27\lib\os.py", line 420, in
 __setitem__
 putenv(key, item)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u017e' in
 position 10: ordinal not in range(128)
 Press any key to continue . . .
 }}}

 When I change line source:grass/trunk/lib/init/grass.py#L620

 {{{
 os.environ['MANPATH'] = to_text_string(addons_man_path)
 }}}

 to

 {{{
 os.environ['MANPATH'] = addons_man_path
 }}}

 then GRASS starts and even MANPATH variable is set up correctly (including
 non-ascii characters). Function `to_text_string` is apparently buggy.
 Tested on Czech (cp1250) Windows 8.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] #3505: Opening a workspace file

2018-03-02 Thread GRASS GIS

#3505: Opening a workspace file
--+-
  Reporter:  clerici  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.4.1
 Component:  wxGUI|Version:  7.4.0
Resolution:   |   Keywords:  wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by annakrat):

 I think that might have something to do with the changes for compatibility
 with wxPython 4. I need more time to investigate this.

-- 
Ticket URL: 
GRASS GIS 

___
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.0.6

2018-03-02 Thread Martin Landa

2018-03-02 10:10 GMT+01:00 Martin Landa :
>> No big announcement planned :-)
>
> I will build at least standalone installer for Windows. Also prepared
> copy-paste announcement [1].

published, https://grass.osgeo.org/news/73/15/GRASS-GIS-7-0-6-released/

Only standalone WinGRASS binaries uploaded. 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

[GRASS-dev] [GSOC 2018] - Implement a series of image fusion algorithms in GRASS GIS

2018-03-02 Thread Tudor-Emil COMAN (25633)

Hi,


My name is Tudor-Emil Coman and I study Computer Science at the Faculty of
Automatic Control and Computer Science in Bucharest, Romania as a MSc student.

I'm currently researching geospatial image processing technologies and I have
primarly worked with Sentinel 2 data on numerous frameworks like ESA SNAP,
GDAL, GeoDjango, PostGIS and of course GRASS GIS.

I'm very interested in working this summer for a project I have seen proposed
on the GSOC 2018 idea page regarding the development of image fusion algorithms.
An already existing fusion algorithm is the High-Pass Filter Addition technique
implemented in the i.fusion.hpf module [1]. The scope of the project would be
to expand the capabilities of GRASS to combine data from different sensors.

The first algorithm I would implement is based on Nicolas Brodu's paper named
Super-resolving multiresolution images with band-independant geometry of
multispectral pixels [2]. The algorithm presented in this paper would increase
the resolution of certain low resolution bands by inferring some geometric
characteristics from high resolution bands. As opposed to the already existing
HPFA fusion method, this one does not require a panchromatic band making it
suitable for satellites that do not produce panchromatic bands.

I'm sure some other fusion algorithms are needed in GRASS-GIS that are not yet
implemented. I'm interested in suggestions about such algorithms so that I can
read about them and incorporate them into my final proposal.

[1] - https://grass.osgeo.org/grass74/manuals/addons/i.fusion.hpf.html
[2] - https://arxiv.org/abs/1609.07986

Cheers,
Tudor

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

Re: [GRASS-dev] planning releases - spring 2018

2018-03-02 Thread Martin Landa

Hi,

2018-02-27 23:30 GMT+01:00 Markus Neteler :
> Yet some backports are open for 7.4.1 [4]
> [4] https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.4.1tobebackporte

preferable authors should do backports because they can decide best
(mmetz, wenzeslaus, marisn)

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.0.6

2018-03-02 Thread Martin Landa

Hi,

2018-03-01 22:42 GMT+01:00 Markus Neteler :
> GRASS GIS 7.0.6 now got "silently" released:
>
> https://trac.osgeo.org/grass/wiki/Release/7.0.6-News
>
> No big announcement planned :-)

I will build at least standalone installer for Windows. Also prepared
copy-paste announcement [1].

Ma

[1] 
https://grass.osgeo.org/grass_admin/moduleinterface.php?mact=News,m1_,editarticle,0&_sx_=6f9d79485418a286_articleid=73

-- 
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-PSC] planning releases - spring 2018

Re: [GRASS-dev] [GRASS GIS] #774: i.rgb.his, i.his.rgb, d.his support for >8 bit

Re: [GRASS-dev] [GRASS GIS] #774: i.rgb.his, i.his.rgb, d.his support for >8 bit

Re: [GRASS-dev] [GRASS GIS] #3509: g.region grow with negative number limited because of top and bottom

Re: [GRASS-dev] [GRASS GIS] #789: g.region option to expand the computational region of about "some" pixels?

[GRASS-dev] [GRASS GIS] #3509: g.region grow with negative number limited because of top and bottom

Re: [GRASS-dev] [GRASS GIS] #3508: grass start up: buggy to_text_string

Re: [GRASS-dev] [GRASS GIS] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

Re: [GRASS-dev] [GRASS GIS] #3186: [PATCH] i.in.spotvgt: allow import of any band, not only NDVI

Re: [GRASS-dev] [GRASS GIS] #3508: grass start up: buggy to_text_string

Re: [GRASS-dev] [GRASS GIS] #3508: grass start up: buggy to_text_string

Re: [GRASS-dev] [GRASS GIS] #3050: Set size in d.northarrow

Re: [GRASS-dev] [GRASS GIS] #3508: grass start up: buggy to_text_string

Re: [GRASS-dev] [GRASS GIS] #3177: Automatically register addons in GUI

Re: [GRASS-dev] [GSOC 2018] - Implement a series of image fusion algorithms in GRASS GIS

[GRASS-dev] [GRASS GIS] #3508: grass start up: buggy to_text_string

Re: [GRASS-dev] [GRASS GIS] #3505: Opening a workspace file

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

[GRASS-dev] [GSOC 2018] - Implement a series of image fusion algorithms in GRASS GIS

Re: [GRASS-dev] planning releases - spring 2018

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

21 matches

Site Navigation

Mail list logo

Footer information