Re: [GRASS-dev] improve resolution of bands

2017-10-20 Thread Nikos Alexandris

* Moritz Lennert  [2017-10-20 15:08:18 +0200]:


On 20/10/17 11:37, Luca Delucchi wrote:

Hi devs,

I just discovered this [0], I think it could be really useful this 
functionality in GRASS too, what do you think? The code is LGPL so 
it

could be ported "easily" in GRASS.


[0] http://nicolas.brodu.net/recherche/superres/index.html


+1


Certainly a valued addition for GRASS and the community.


IIUC, it's a new technique for image fusion ? As of now, we have
i.pansharpen in core which offers very basic fusion techniques and
Nikos' i.fusion.hpf in addons. New techniques would certainly be welcome.

A while ago, I was looking at Bayesian fusion methods, notably R-FUSE 
[1], for which Matlab code is available [2], but haven't had the time 
to go further. That might be another method that would be great to 
implement.


There is also this one http://www.freepatentsonline.com/8737733.html.
Not exactly new. Yet, I fear it cannot be freely used (as in cost-free).
If anyone could confirm.

[..]

Nikos


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

Re: [GRASS-dev] r.plane commits breaks winGRASS builds

2017-10-20 Thread Helmut Kudrnovsky
Helmut Kudrnovsky wrote
>>Re: bugfix. I could also change the name to "Jaeger". Let me know what
>>you prefer.
> 
> any chance for the bugfix? winGRASS will be still broken until the fix.
> 
> I'm in favor of:
> 
> """
> # -*- coding: utf-8 -*-
> """

done by

r71569 - grass/trunk/scripts/r.plane
r71570 - grass/branches/releasebranch_7_2/scripts/r.plane
r71571 - grass/branches/releasebranch_7_0/scripts/r.plane 

fix for grass/branches/releasebranch_6_4/scripts/r.plane is still open.




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.plane commits breaks winGRASS builds

2017-10-20 Thread Helmut Kudrnovsky
>Re: bugfix. I could also change the name to "Jaeger". Let me know what
>you prefer.

any chance for the bugfix? winGRASS will be still broken until the fix.

I'm in favor of:

"""
# -*- coding: utf-8 -*-
"""



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

2017-10-20 Thread Helmut Kudrnovsky
>v.clip and v.profile are IMHO important functionality for 7.4.0.

+1 for these 2 addons



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.0

2017-10-20 Thread Markus Neteler
On Oct 20, 2017 3:47 PM, "Moritz Lennert" 
wrote:
>
> On 02/10/17 23:35, Markus Neteler wrote:
>>
>> On Mon, Oct 2, 2017 at 3:48 PM, Martin Landa 
wrote:
>>>
>>> 2017-10-02 15:01 GMT+02:00 Luca Delucchi :
>
> G7A:r.geomorphon
> G7A:r.object.geometry - +/- equivalent to v.to.db, but for raster
> objects: very useful for many other modules (notably OBIA)
> G7A:r.vect.stats - very simple, but nice functionality to have in core
> G7A:v.centerpoint - basic GIS functionality
> G7A:v.clip - very easy to use and expected GIS functionality without
> hassle of complicated commmands :-)
> G7A:v.profile - expected GIS functionality
>

 +1 for all the candidates
>>>
>>>
>>> please note, that new modules in trunk should have (ideally) tests.
Martin
>>
>>
>> Right. As usual, especially the addon authors are kindly invited to
>> provide test cases.
>
>
>
> Is the plan to wait for integration of these addons before creating the
7.4 release branch ? If that is the case we should probably set a deadline.

v.clip and v.profile are IMHO important functionality for 7.4.0.

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

Re: [GRASS-dev] [release planning] 7.4.0

2017-10-20 Thread Moritz Lennert

On 02/10/17 23:35, Markus Neteler wrote:

On Mon, Oct 2, 2017 at 3:48 PM, Martin Landa  wrote:

2017-10-02 15:01 GMT+02:00 Luca Delucchi :

G7A:r.geomorphon
G7A:r.object.geometry - +/- equivalent to v.to.db, but for raster
objects: very useful for many other modules (notably OBIA)
G7A:r.vect.stats - very simple, but nice functionality to have in core
G7A:v.centerpoint - basic GIS functionality
G7A:v.clip - very easy to use and expected GIS functionality without
hassle of complicated commmands :-)
G7A:v.profile - expected GIS functionality



+1 for all the candidates


please note, that new modules in trunk should have (ideally) tests. Martin


Right. As usual, especially the addon authors are kindly invited to
provide test cases.



Is the plan to wait for integration of these addons before creating the 
7.4 release branch ? If that is the case we should probably set a deadline.


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

[GRASS-dev] [GRASS GIS] #3429: g.gui.iclass: segfault when loading vector layer

2017-10-20 Thread GRASS GIS
#3429: g.gui.iclass: segfault when loading vector layer
--+-
 Reporter:  mlennert  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.4.0
Component:  wxGUI |Version:  svn-trunk
 Keywords:  g.gui.iclass import segfault  |CPU:  Unspecified
 Platform:  Unspecified   |
--+-
 * define group
 * define classes
 * digitize a few training areas
 * save training areas to vector map
 * close g.gui.iclass
 * reopen g.gui.iclass
 * import saved vector maps
 => segfault

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] improve resolution of bands

2017-10-20 Thread Moritz Lennert

On 20/10/17 15:15, Margherita Di Leo wrote:



On Fri, Oct 20, 2017 at 3:08 PM, Moritz Lennert 
> wrote:


On 20/10/17 11:37, Luca Delucchi wrote:

Hi devs,

I just discovered this [0], I think it could be really useful
this functionality in GRASS too, what do you think? The code is
LGPL so it
could be ported "easily" in GRASS.


[0] http://nicolas.brodu.net/recherche/superres/index.html



+1

IIUC, it's a new technique for image fusion ? As of now, we have
i.pansharpen in core which offers very basic fusion techniques and
Nikos' i.fusion.hpf in addons. New techniques would certainly be
welcome.

A while ago, I was looking at Bayesian fusion methods, notably
R-FUSE [1], for which Matlab code is available [2], but haven't had
the time to go further. That might be another method that would be
great to implement.

Maybe also something to keep in mind for next GSoC ?


This sounds like a great idea, please don't let it fade out, it's always 
a good time to collect the ideas into the ideas page


https://trac.osgeo.org/grass/wiki/GSoC/2018

:-)

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

Re: [GRASS-dev] improve resolution of bands

2017-10-20 Thread Margherita Di Leo
On Fri, Oct 20, 2017 at 3:08 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/10/17 11:37, Luca Delucchi wrote:
>
>> Hi devs,
>>
>> I just discovered this [0], I think it could be really useful this
>> functionality in GRASS too, what do you think? The code is LGPL so it
>> could be ported "easily" in GRASS.
>>
>>
>> [0] http://nicolas.brodu.net/recherche/superres/index.html
>>
>
> +1
>
> IIUC, it's a new technique for image fusion ? As of now, we have
> i.pansharpen in core which offers very basic fusion techniques and
> Nikos' i.fusion.hpf in addons. New techniques would certainly be welcome.
>
> A while ago, I was looking at Bayesian fusion methods, notably R-FUSE [1],
> for which Matlab code is available [2], but haven't had the time to go
> further. That might be another method that would be great to implement.
>
> Maybe also something to keep in mind for next GSoC ?
>

This sounds like a great idea, please don't let it fade out, it's always a
good time to collect the ideas into the ideas page

Thanks


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

Re: [GRASS-dev] improve resolution of bands

2017-10-20 Thread Moritz Lennert

On 20/10/17 11:37, Luca Delucchi wrote:

Hi devs,

I just discovered this [0], I think it could be really useful this 
functionality in GRASS too, what do you think? The code is LGPL so it

could be ported "easily" in GRASS.


[0] http://nicolas.brodu.net/recherche/superres/index.html


+1

IIUC, it's a new technique for image fusion ? As of now, we have
i.pansharpen in core which offers very basic fusion techniques and
Nikos' i.fusion.hpf in addons. New techniques would certainly be welcome.

A while ago, I was looking at Bayesian fusion methods, notably R-FUSE 
[1], for which Matlab code is available [2], but haven't had the time to 
go further. That might be another method that would be great to implement.


Maybe also something to keep in mind for next GSoC ?

Moritz



[1] http://oatao.univ-toulouse.fr/16629/7/wei_16629.pdf
[2] https://github.com/qw245/BlindFuse


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

Re: [GRASS-dev] improve resolution of bands

2017-10-20 Thread Veronica Andreo
Hi

2017-10-20 11:37 GMT+02:00 Luca Delucchi :

> Hi devs,
>
> I just discovered this [0], I think it could be really useful this
> functionality in GRASS too, what do you think?
> The code is LGPL so it could be ported "easily" in GRASS.
>

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

[GRASS-dev] improve resolution of bands

2017-10-20 Thread Luca Delucchi
Hi devs,

I just discovered this [0], I think it could be really useful this
functionality in GRASS too, what do you think?
The code is LGPL so it could be ported "easily" in GRASS.


[0] http://nicolas.brodu.net/recherche/superres/index.html

-- 
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] r.plane commits breaks winGRASS builds

2017-10-20 Thread Markus Neteler
On Fri, Oct 20, 2017 at 10:03 AM, Martin Landa  wrote:
> Hi,
>
> 2017-10-20 9:16 GMT+02:00 Helmut Kudrnovsky :
>> looking into winGRASS build logs:
>>
>> https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71566-385/error.log
>> https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71567-385/error.log
>
> see 
> https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71567-385/package.log
>
> """
> SyntaxError: Non-ASCII character '\xc3' in file
> C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/scripts/r.plane.py
> on line 6, but no encoding declared; see
> http://python.org/dev/peps/pep-0263/ for details
> ../../include/Make/Html.make:14: recipe for target 'r.plane.tmp.html' failed
> make[3]: *** [r.plane.tmp.html] Error 1
> GISRC=/c/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/demolocation/.grassrc7
> """
>
> putting
>
> """
> # -*- coding: utf-8 -*-
> """
>
> in r.plane.py should fix the issue.

Sorry for accidentially haven broken this. I was not aware that
putting an umlaut into a .py file may become an issue.

Background: I am currently sitting next to this original r.plane
developer Stefan Jäger :-) He noted that his name got lost time ago
and I promised to put it back.
Also the r.statistics original author Martin Schröder is here. Funny
to meet them first time ~23 years after inception of the modules...

Re: bugfix. I could also change the name to "Jaeger". Let me know what
you prefer.

best,
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] r.plane commits breaks winGRASS builds

2017-10-20 Thread Martin Landa
Hi,

2017-10-20 9:16 GMT+02:00 Helmut Kudrnovsky :
> looking into winGRASS build logs:
>
> https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71566-385/error.log
> https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71567-385/error.log

see https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71567-385/package.log

"""
SyntaxError: Non-ASCII character '\xc3' in file
C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/scripts/r.plane.py
on line 6, but no encoding declared; see
http://python.org/dev/peps/pep-0263/ for details
../../include/Make/Html.make:14: recipe for target 'r.plane.tmp.html' failed
make[3]: *** [r.plane.tmp.html] Error 1
GISRC=/c/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/demolocation/.grassrc7
"""

putting

"""
# -*- coding: utf-8 -*-
"""

in r.plane.py should fix the issue.

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] r.plane commits breaks winGRASS builds

2017-10-20 Thread Helmut Kudrnovsky
looking into winGRASS build logs:

https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71566-385/error.log
https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71567-385/error.log

recent r.plane commits seems to break winGRASS builds:

GRASS GIS 7.3.svn r71567 compilation log
--
Started compilation: Thu Oct 19 23:40:19 2017
--
Errors in:
/c/msys64/usr/src/grass_trunk/scripts/r.plane
--
In case of errors please change into the directory with error and run
'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Fri Oct 20 00:17:27 2017





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev