Re: [GRASS-dev] External providers in QGIS

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

Re: [GRASS-dev] External providers in QGIS

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

Re: [GRASS-dev] External providers in QGIS

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

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

#789: g.region option to expand the computational region of about "some" pixels? -+- Reporter: nikos | Owner: grass-dev@… Type: | Status: new enhancement| Priority:

Re: [GRASS-dev] [GRASS GIS] #3488: v.in.ogr mangeling of column names when imporing OSM geojson extracts

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

Re: [GRASS-dev] [GRASS GIS] #3488: v.in.ogr mangeling of column names when imporing OSM geojson extracts

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

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

#789: g.region option to expand the computational region of about "some" pixels? -+- Reporter: nikos | Owner: grass-dev@… Type: | Status: new enhancement| Priority:

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,

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

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)

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

Re: [GRASS-dev] External providers in QGIS

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

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

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

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

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

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

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

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

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

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

#789: g.region option to expand the computational region of about "some" pixels? -+- Reporter: nikos | Owner: grass-dev@… Type: | Status: new enhancement| Priority:

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

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

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

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

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

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

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

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

Re: [GRASS-dev] External providers in QGIS

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

Re: [GRASS-dev] External providers in QGIS

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

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

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

Re: [GRASS-dev] External providers in QGIS

* 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