Re: [GRASS-dev] [GRASS GIS] #3344: r.stream.slope Segmentation fault: 11 error

[GRASS GIS]

#3344: r.stream.slope Segmentation fault: 11 error
--+--
  Reporter:  msweier  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Addons   |Version:  7.0.4
Resolution:   |   Keywords:  r.stream, segmentation fault
   CPU:  Unspecified  |   Platform:  All
--+--

Comment (by mmetz):

 Replying to [comment:5 sbl]:
 > Same here on Ubuntu (both 14.04 and 16.04) with fresh GRASS 7.4 (r72099)
 and a bit older 7.2 (r70326).
 >
 > Here is an example with North Carolina data:
 >
 > {{{
 > g.extension extension=r.stream.slope operation=add
 > g.region raster=elev_state_500m -p
 > r.stream.extract elevation=elev_state_500m threshold=100
 stream_length=10 stream_raster=stream direction=dir
 > r.stream.slope elevation=elev_state_500m direction=dir gradient=grad
 difference=diff
 > }}}
 >
 > Specifying any output gives segfault, specifying no output gives no
 error...

 Please try r72216, i.e. reinstall r.stream.slope

--
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] #3344: r.stream.slope Segmentation fault: 11 error (was: r.stream.slope Segmentation fault: 11 error macOS 10.12.4)

[GRASS GIS]

#3344: r.stream.slope Segmentation fault: 11 error
--+--
  Reporter:  msweier  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Addons   |Version:  7.0.4
Resolution:   |   Keywords:  r.stream, segmentation fault
   CPU:  Unspecified  |   Platform:  All
--+--
Changes (by sbl):

 * platform:  MacOSX => All
 * milestone:  7.2.3 => 7.4.1


Comment:

 Same here on Ubuntu with fresh GRASS 7.4.

 Here is an example with North Carolina data:

 {{{
 g.extension extension=r.stream.slope operation=add
 g.region raster=elev_state_500m -p
 r.stream.extract elevation=elev_state_500m threshold=100 stream_length=10
 stream_raster=stream direction=dir
 r.stream.slope elevation=elev_state_500m direction=dir gradient=grad
 difference=diff
 }}}

 Specifying any output gives segfault, specifying no output gives no
 error...

--
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] #3488: v.in.ogr mangeling of column names when imporing OSM geojson extracts

[GRASS GIS]

#3488: v.in.ogr mangeling of column names when imporing OSM geojson extracts
-+-
  Reporter:  alice   |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.4.1
 Component:  Vector  |Version:  svn-releasebranch74
Resolution:  fixed   |   Keywords:  v.in.ogr
   CPU:  All |   Platform:  Linux
-+-

Comment (by mmetz):

 Replying to [comment:3 neteler]:
 > In [changeset:"72215" 72215]:
 > {{{
 > #!CommitTicketReference repository="" revision="72215"
 > v.in.ogr: fix duplicate column names (trunk, r72209; fixes #3488)
 > }}}

 Is it working for you 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] #3488: v.in.ogr mangeling of column names when imporing OSM geojson extracts

[GRASS GIS]

#3488: v.in.ogr mangeling of column names when imporing OSM geojson extracts
-+-
  Reporter:  alice   |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.4.1
 Component:  Vector  |Version:  svn-releasebranch74
Resolution:  fixed   |   Keywords:  v.in.ogr
   CPU:  All |   Platform:  Linux
-+-
Changes (by neteler):

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


Comment:

 In [changeset:"72215" 72215]:
 {{{
 #!CommitTicketReference repository="" revision="72215"
 v.in.ogr: fix duplicate column names (trunk, r72209; fixes #3488)
 }}}

--
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?

[GRASS GIS]

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

Comment (by mmetz):

 Replying to [comment:26 lucadelu]:
 > Replying to [comment:25 mlennert]:
 >
 > >
 > > Why not ? If you have the same use case as the one described by Nikos,
 but with a 3D point map, wouldn't you need the same functionality also in
 top and bottom direction ?
 >
 > For me it is the same, but probably I would like to have a flag to
 modify the 3D region to use with pixels option

 Either have one option that modifies extents of all 3 dimensions, or have
 separate options for each dimension, e.g. xpixels, ypixels, zpixels. I
 favour the first solution, one option for all 3 dimensions.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] External providers in QGIS

[Helmut Kudrnovsky]

pcav wrote
> Il 08/02/2018 15:49, Nikos Alexandris ha scritto:
>> * Moritz Lennert 

> mlennert@.worldonline

>  [2018-02-08 15:20:14
>> +0100]:
>> 
>>> On 08/02/18 15:08, Nikos Alexandris wrote:
 I guess, there are numerous cases like this one. What would,
 effectively, mean a removal of external providers (in this case GRASS
 GIS)?
>>>
>>> Let's make it clear once and for all: noone is speaking about the
>>> complete removal of external providers. The issue is where, how and by
>>> whom they should be maintained, i.e. within the QGIS core code base,
>>> or as plugins.
>> 
>> 
>> Thank you the heads-up Moritz.
> 
> true, but removal from core would mean the external plugin has to be
> created, maintained, tested, and documented by someone. If this is
> missing, the external plugin simply wil not appear. This is what
> happened with R. Once a provider is out and unmaintained, it becomes
> less visible, and less likely to attract attention. The work to bring it
> back to life, with all the above, will be much higher than when in core,
> and increasing over time.
> All the best.
> 
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-dev

this touches Moritz' questions listed here:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087420.html





-
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] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 15:49, Nikos Alexandris ha scritto:
> * Moritz Lennert  [2018-02-08 15:20:14
> +0100]:
> 
>> On 08/02/18 15:08, Nikos Alexandris wrote:
>>> I guess, there are numerous cases like this one. What would,
>>> effectively, mean a removal of external providers (in this case GRASS
>>> GIS)?
>>
>> Let's make it clear once and for all: noone is speaking about the
>> complete removal of external providers. The issue is where, how and by
>> whom they should be maintained, i.e. within the QGIS core code base,
>> or as plugins.
> 
> 
> Thank you the heads-up Moritz.

true, but removal from core would mean the external plugin has to be
created, maintained, tested, and documented by someone. If this is
missing, the external plugin simply wil not appear. This is what
happened with R. Once a provider is out and unmaintained, it becomes
less visible, and less likely to attract attention. The work to bring it
back to life, with all the above, will be much higher than when in core,
and increasing over time.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 13:43, Rashad Kanavath ha scritto:

> But aside all decision making stuff, can you check what is to be done in
> this PR?
> https://github.com/qgis/QGIS/pull/6272
> It is something worthy a discussion and not a plugin or not. I was
> asking because QGIS 3 is near and diff is not that big.
> If there is something extra need to be done to get this merged, I would
> happy to hear about it.

agreed, this is an important and urgent point.
please some qgis dev could check this?
thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 10:31, Rashad Kanavath ha scritto:

> I don't know what these developers are going to do with a bugfix after a
> new release. That's some kind of mystery unsolved to me.

we are doing regular point releases, an approach which has proven very
successful IMHO

> I hope there will be zero bugs after releases.

I hope you are joking :)

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Nikos Alexandris]

* Moritz Lennert  [2018-02-08 15:20:14 +0100]:


On 08/02/18 15:08, Nikos Alexandris wrote:

I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?


Let's make it clear once and for all: noone is speaking about the 
complete removal of external providers. The issue is where, how and by 
whom they should be maintained, i.e. within the QGIS core code base, 
or as plugins.



Thank you the heads-up Moritz.

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] External providers in QGIS

[Moritz Lennert]

On 08/02/18 15:08, Nikos Alexandris wrote:

I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?


Let's make it clear once and for all: noone is speaking about the 
complete removal of external providers. The issue is where, how and by 
whom they should be maintained, i.e. within the QGIS core code base, or 
as plugins.


Moritz


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

Re: [GRASS-dev] External providers in QGIS

[Nikos Alexandris]

Dear all,

a case somewhat relevant to the discussion.

I am tasked by a client to work with and on some existing scripts that derive
maps related to recreational areas. These scripts use GRASS GIS.
Hence, it is naturally to shape a GRASS GIS Add-on.

The add-on will eventually be of interest for many, and mostly non
GIS-experts.  The whole idea was to expose the Add-on to QGIS and
eventually train and practice with it persons who are not experienced
GIS users.

Both QGIS and GRASS GIS, in this case, and the whole OSGeo ecosystem,
have things to gain, while offering small tools that interest many.

I guess, there are numerous cases like this one. What would,
effectively, mean a removal of external providers (in this case GRASS
GIS)?

Among the, indeed, many algorithms that might appear, or be
overwhelming, there are always here and there tools that make life
easier for people who don't have the time or the need to dive deep into
special concepts of GRASS, SAGA or OTB.  And QGIS is for the the
reference.

Thanks, Nikos



* Paolo Cavallini  [2018-02-06 18:57:17 +0100]:


Hi all,
following the discussion on qgis-dev ML:
https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
it has been proposed to remove all external providers (namely OTB,
already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
remain as QGIS cannot be built without). This raised a number of
concerns, so PSC decided not to rush removing them from the upcoming 3.0
release, and to open a wider discussions about this, involving all the
interested parties, to find an optimal solution.
If volunteers outside QGIS core team, ideally from the respective
backends, could take the maintenance of these providers, not much would
change for the end user. If not, this will mean effectively missing
hundreds of algs from QGIS.
I personally propose to reinstate the OTB plugin with Rashad (from OTB)
as maintainer.
QGIS.ORG will seek to support any decision made with funding where possible.
Looking forward for your feedback.
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 


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] [QGIS-Developer] External providers in QGIS

[Moritz Lennert]

On 08/02/18 13:43, Rashad Kanavath wrote:



On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya > wrote:


OTB's proposed solution was that plugin or provider algorithm if
activated can find otb installation. If not found, there is code
which will download and install otb packages and configure it
for users.


I still don't see why this cannot be done if OTB provider is a
separate plugin. Users can install a plugin with the provider, and
then that provider can have the logic to automatically download OTB,
install it, or do whatever is needed in case OTB is not found
already installed.

I think is is good to educate our users a little bit. We are talking
about people that will be using complex algorithms for performing
advanced analysis. I guess we can expect that they can install a
plugin themselves and it is not a traumatic experience for them...
Looks like installing a separate plugin it's some sort of cruel
chinese torture...when it takes just 3 mouse clicks.

I agree with Giovanni, there is no need to provide something that
has everything installed out-of the box. Also, take into account
that reading the files that contain the algorithm descriptions takes
time (plus, there might be some additional checks performed when
populating the toolbox). People not doing analysis should not have
to suffer that extra loading time...


QGIS increases no of algorithms for a provider. It is simple as that. 
OTB has less than 80 applications and coming to QGIS, it will be 100 or 
150. (no interest to count them in qgis)
  And OTB was reading descriptor from xml which is going to be now csv 
like others.
Given all that info, I won't be surprised if it takes more time in 
future because of new algorithms added to providers. If QGIS was reading 
proper way or even open to accepting fixes.


The entire proposal/request to put back OTB was that decision was made 
on OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix 
it, they can't be put back. This single point was fueling this and other 
threads.
Also discussion wasn't started with "why no providers are included?". It 
was why some of them are removed even if there is an offer to help!


I don't care enough to continue this discussion about plugin or not plugin.



Warning: I don't claim any knowledge of the actual QGIS provider code, 
but I'm afraid that this is the case for many external SW developers, so 
please bear with me and correct me where I'm wrong.


However, I do have the feeling that part of the debate is due to 
fuzzyness of the actual subject. AFAIU, there a different issues here, 
and only if we clarify what we are talking about exactly, and what the 
actual issues are, can we advance. So, here's my understanding:


1) the descriptor files of the different algorithms in external SW

It seems that at least from OTB and GRASS side, willingness has been 
signaled to take over the handling of those.


2) the code that allows to launch these algorithms from within QGIS

IIUC this is again subdivided into two parts:

- a generic class within QGIS code for creating a provider
- the specific external SW related instances of these classes

The first part is definitely part of QGIS core.

The current debate (again AFAIU) is mostly about the second part. And 
one question linked to this is how much of the handling can be done by 
the generic class code, and how much is SW-specific. IOW, would it be 
possible to have exactly the same format of descriptor files for all SW, 
and a generic API to interpret those, or are the idiosyncrasies of the 
different SW such that API and descriptor files will have to be SW 
specific ?


A second question is how much within the second part (the SW specific 
provider) depends on evolutions of QGIS code, i.e. when QGIS moves from 
one version to the next, will the code in this part have to change, or 
will it remain stable, and how much depends on evolutions in the 
external SW code. If changes in external SW happen more often than it 
seems to make sense to keep this part of the code away from QGIS core, 
but if changes in QGIS happen more often than the opposite would seem 
better.


Another issue is that current expertise on how to code these providers 
is within the QGIS development team. If you decide to put these 
providers into plugins, _and_ to no longer ensure the maintenance of 
these plugins, this would mean that the development teams of the 
external SW have to acquire the necessary knowledge. Looking at general 
scarcity of human power in all of the teams, I'm not sure this will 
happen easily.


Do I understand things correctly ?

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

Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya  wrote:

>
>
>>
>> OTB's proposed solution was that plugin or provider algorithm if
>> activated can find otb installation. If not found, there is code which will
>> download and install otb packages and configure it for users.
>>
>
> I still don't see why this cannot be done if OTB provider is a separate
> plugin. Users can install a plugin with the provider, and then that
> provider can have the logic to automatically download OTB, install it, or
> do whatever is needed in case OTB is not found already installed.
>
> I think is is good to educate our users a little bit. We are talking about
> people that will be using complex algorithms for performing advanced
> analysis. I guess we can expect that they can install a plugin themselves
> and it is not a traumatic experience for them... Looks like installing a
> separate plugin it's some sort of cruel chinese torture...when it takes
> just 3 mouse clicks.
>
> I agree with Giovanni, there is no need to provide something that has
> everything installed out-of the box. Also, take into account that reading
> the files that contain the algorithm descriptions takes time (plus, there
> might be some additional checks performed when populating the toolbox).
> People not doing analysis should not have to suffer that extra loading
> time...
>

QGIS increases no of algorithms for a provider. It is simple as that. OTB
has less than 80 applications and coming to QGIS, it will be 100 or 150.
(no interest to count them in qgis)
 And OTB was reading descriptor from xml which is going to be now csv like
others.
Given all that info, I won't be surprised if it takes more time in future
because of new algorithms added to providers. If QGIS was reading proper
way or even open to accepting fixes.

The entire proposal/request to put back OTB was that decision was made on
OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix it,
they can't be put back. This single point was fueling this and other
threads.
Also discussion wasn't started with "why no providers are included?". It
was why some of them are removed even if there is an offer to help!

I don't care enough to continue this discussion about plugin or not plugin.

But aside all decision making stuff, can you check what is to be done in
this PR?
https://github.com/qgis/QGIS/pull/6272
It is something worthy a discussion and not a plugin or not. I was asking
because QGIS 3 is near and diff is not that big.
If there is something extra need to be done to get this merged, I would
happy to hear about it.


> About the R plugin not being available now...well, it's in a separate repo
> and can be adapted to QGIS 3, packaged and published. No one has taken care
> of that, it's true, but that only means we have no R support. If the R
> provider was be in core, it would mean that we would have a dead or
> malfunctioning provider being shipped with QGIS. That is a much worse
> option. And I dont see why, if someone is willing to fix that R provider,
> having it in core will make it easier.
>
> Cheers!
>



-- 
Regards,
   Rashad
___
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?

[GRASS GIS]

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

Comment (by lucadelu):

 Replying to [comment:25 mlennert]:

 >
 > Why not ? If you have the same use case as the one described by Nikos,
 but with a 3D point map, wouldn't you need the same functionality also in
 top and bottom direction ?

 For me it is the same, but probably I would like to have a flag to modify
 the 3D region to use with pixels option

 my2cents

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] New addon: i.pysptools.unmix

[Stefan Blumentrath]

Hi Moritz,

We are about to compare results from the two addons...
Unfortunately, I missed some details, so the manual page is not online yet 
(issues should be fixed now).

The main additions, compared to i.spec.unmix are 
 - three alternative endmember detection algorithms
 - (at least) two additional algorithms for spectral unmixing (Unconstrained 
least squares and fully constrained least squares (with the latter, pixels 
values in the resulting maps sum up to 1).

I should probably also mention, that i.pysptools.unmix allows to write out 
detected end members in a format that i.spec.unmix understands. So the modules 
can be complementary...

Cheers,
Stefan


-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: torsdag 8. februar 2018 09.06
To: Stefan Blumentrath ; grass-user grass-user 
(grass-u...@lists.osgeo.org) ; GRASS developers 
list (grass-dev@lists.osgeo.org) 
Subject: Re: [GRASS-dev] New addon: i.pysptools.unmix

On 06/02/18 23:37, Stefan Blumentrath wrote:
> Dear all,
> 
> I just committed a new addon (i.pysptools.unmix) which is a wrapper 
> around the endmember extraction and spectral unmixing functionality in 
> the pysptools python library [1].
> 
> Feedback will be gladly received!

Great, thanks a lot ! How does it compare to i.spec.unmix ? I assume it adds 
more algorithms ?

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

Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 10:15 AM, Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>

OTB's proposed solution was that plugin or provider algorithm if activated
can find otb installation. If not found, there is code which will download
and install otb packages and configure it for users.


> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri 
> Cc: qgis-developer ;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-dev@lists.osgeo.org>; Victor Olaya 
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - from my experience - comprising years of feedbacks from the courses
> > I teach - the most frequently used algs are available within the GDAL
> > and QGIS algs list
> >
> > - a few generic and widely used algs are from GRASS and SAGA. We would
> > miss them - out of the box - but it could also be an opportunity to
> > port them. For examples v.to.points, transects, profiles.
> > Anyway we would have the plugins for GRASS and SAGA, in case...
> >
> > - specific algs are for specialized users. Here I think plugins are
> > best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added
> > to the list, consistently with the others approach.
> >
> > I appreciate a lot the work from Richard, I hope this discussion is
> > not understood as to belittle its effort!
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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
>



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

Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

[G. Allegri]

What I ment is that, from my perspective, we shouldn't seek to make QGIS a
do-it-all software by default, because the GIS/EO/RS/Data Analysis fields
are so wide that, from that point of view, everything could go into QGIS
and it would be an overwhelmin experience for users.
Any generic sw I know offers extensions, plugins, for specialized use
cases.  From my experience a user prefers few tools that match their needs,
instead of digging into a long list of (mostly) obscure algs...

Anyway, I don't want to stress on this...
Giovanni

2018-02-08 10:15 GMT+01:00 Stefan Blumentrath :

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>
> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri 
> Cc: qgis-developer ;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-dev@lists.osgeo.org>; Victor Olaya 
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - from my experience - comprising years of feedbacks from the courses
> > I teach - the most frequently used algs are available within the GDAL
> > and QGIS algs list
> >
> > - a few generic and widely used algs are from GRASS and SAGA. We would
> > miss them - out of the box - but it could also be an opportunity to
> > port them. For examples v.to.points, transects, profiles.
> > Anyway we would have the plugins for GRASS and SAGA, in case...
> >
> > - specific algs are for specialized users. Here I think plugins are
> > best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added
> > to the list, consistently with the others approach.
> >
> > I appreciate a lot the work from Richard, I hope this discussion is
> > not understood as to belittle its effort!
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavallini 
wrote:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
>
> why not granting them write access?
>
That would still need users *waiting* for QGIS release for fix in algo is
what I understood from other parts of discussion.
I don't know what these developers are going to do with a bugfix after a
new release. That's some kind of mystery unsolved to me.
I hope there will be zero bugs after releases.


>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution


> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



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

Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

[Stefan Blumentrath]

Hi,

Regarding the negative effect of algorithms getting lost I fully agree with you 
Paolo.

However, it might simplify the discussion if we try separate user experience 
and development (and packaging) solutions as well as means and ends...

Aim should be to have the different back-ends available for user in a way that 
is as straight forward as possible. From my point of view that includes that 
possibly available providers are not hidden from users who just install bare 
QGIS. If they want to activate them, but don`t have the backends installed (and 
possibly a plugin) then they should get a notice that they have to install them 
(and I don`t see a problem with installing provider + plugin compared to just 
provider).

And if that sort of user experience is guaranteed I - as a user - would not 
care about where the code is maintained (in QGIS core, in the provider core, or 
in a separate plugin). My impression is that Victors arguments for an 
out-of-core solution are very valid, esp. given effects of the independent 
release cycles of the backends and QGIS on packaging needs (at least for the 
GRASS plugin).
The only difference I see is that additional packages would be needed for a 
plugin solution. But that is probably not too bad or even an advantage...

Finally, if there is interest in keeping the processing integration alive (and 
it obviously is) having it in an independent repo should not be a show stopper. 
Only negative effect I can see is that this produces additional repos, where 
access rights have to be managed. But that should not be a major issue either...

Cheers
Stefan

P.S.: Just a pity that this discussion starts after medspx just put down all 
this work:
https://github.com/qgis/QGIS/pull/5603
https://github.com/qgis/QGIS/pull/5968
https://github.com/qgis/QGIS/pull/5426

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paolo 
Cavallini
Sent: torsdag 8. februar 2018 09.04
To: G. Allegri 
Cc: qgis-developer ; 
saga-gis-develo...@lists.sourceforge.net; grass-dev 
; Victor Olaya 
Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for 
serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch to 
other software.
We have already removed R provider: even if used by a tiny minority, and 
certainly not perfect, the previous situation was better than the current one, 
without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - from my experience - comprising years of feedbacks from the courses 
> I teach - the most frequently used algs are available within the GDAL 
> and QGIS algs list
> 
> - a few generic and widely used algs are from GRASS and SAGA. We would 
> miss them - out of the box - but it could also be an opportunity to 
> port them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
> 
> - specific algs are for specialized users. Here I think plugins are 
> best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added 
> to the list, consistently with the others approach.
> 
> I appreciate a lot the work from Richard, I hope this discussion is 
> not understood as to belittle its effort!

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
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] [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri  wrote:

> I'm much more in favour for out of core providers, for the same reasons
> reported by Victor. Having only GDAL and QGIS algorithms in core will
> reduce the number of available algorithms out of the box, but:
>
> - from my experience - comprising years of feedbacks from the courses I
> teach - the most frequently used algs are available within the GDAL and
> QGIS algs list
>

Do you have these toolboxes installed during training? OTB, SAGA, GRASS
etc..
OTB is focused on remote sensing. Unless you have a training or course that
area, your statistics on them being not needed is pretty unreliable. Don't
you think?
What QGIS uses to run a classification/segmentation algorithm without OTB
and GRASS GIS.


> - a few generic and widely used algs are from GRASS and SAGA. We would
> miss them - out of the box - but it could also be an opportunity to port
> them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
>
> - specific algs are for specialized users. Here I think plugins are best
> suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
> list, consistently with the others approach.
>
> I appreciate a lot the work from Richard, I hope this discussion is not
> understood as to belittle its effort!
>
> my 2 cents...
> Giovanni
>
> Il 7 feb 2018 18:25, "Paolo Cavallini"  ha scritto:
>
>> Il 07/02/2018 11:18, Victor Olaya ha scritto:
>> > I dont see the advantage in having providers in core.
>>
>> I see the following:
>> * tests (already available in our infrastructure)
>> * translations
>> * more exposure
>> * documentation
>>
>> > And if there is an
>> > advantage, it's clearly not in how easy it is going to be to maintain
>> > the plugin.
>>
>> until now it has been maintained somehow; if more resources are needed,
>> we can find a way
>>
>> > If the people responsible of a given backend (like OTB) are
>> > going to maintain it (which makes sense), why putting it in core where
>> > they don't have write access?
>>
>> why not granting them write access?
>>
>> > Better in a separate repo. Also, they can
>> > release whenever there are changes, without having to wait for a new
>> > release. That way, the plugin will always be in sync with new releases
>> > of the backend app.
>>
>> this is certainly true; AFAICT OTB people has proposed a solution
>>
>> > If we put them in core...why putting only this big ones (which in some
>> > cases require installing external apps manually by the user), and not
>> > put other plugins that exist and contain Processing providers?
>>
>> I'd be in favour of adding anything important for users.
>>
>> Thanks for your thoughts.
>>
>> When in Madeira we can have a discussion about this. It would be good if
>> all interested parties could meet, locally and remotely.
>>
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> QGIS-Developer mailing list
>> qgis-develo...@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



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

Re: [GRASS-dev] New addon: i.pysptools.unmix

[Moritz Lennert]

On 06/02/18 23:37, Stefan Blumentrath wrote:

Dear all,

I just committed a new addon (i.pysptools.unmix) which is a wrapper 
around the endmember extraction and spectral unmixing functionality in 
the pysptools python library [1].


Feedback will be gladly received!


Great, thanks a lot ! How does it compare to i.spec.unmix ? I assume it 
adds more algorithms ?


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

Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
for serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch
to other software.
We have already removed R provider: even if used by a tiny minority, and
certainly not perfect, the previous situation was better than the
current one, without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - from my experience - comprising years of feedbacks from the courses I
> teach - the most frequently used algs are available within the GDAL and
> QGIS algs list
> 
> - a few generic and widely used algs are from GRASS and SAGA. We would
> miss them - out of the box - but it could also be an opportunity to port
> them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
> 
> - specific algs are for specialized users. Here I think plugins are best
> suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
> list, consistently with the others approach.
> 
> I appreciate a lot the work from Richard, I hope this discussion is not
> understood as to belittle its effort!

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
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?

[GRASS GIS]

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

Comment (by mlennert):

 Replying to [comment:24 lucadelu]:
 > Replying to [comment:22 martinl]:
 > > Replying to [comment:21 lucadelu]:
 > > > but nothing changed in the output of g.region -p, so no idea...
 > >
 > > try
 > >
 > > {{{
 > > g.region -p3
 > > }}}
 >
 > Thanks Martin, top and bottom are used only for 3D region? If yes I
 don't think that pixels option should modify them

 Why not ? If you have the same use case as the one described by Nikos, but
 with a 3D point map, wouldn't you need the same functionality also in top
 and bottom direction ?

--
Ticket URL: 
GRASS GIS 

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