On Thu, Feb 15, 2018 at 6:22 PM, Anita Graser wrote:
>
>
> On Sun, Feb 11, 2018 at 8:52 AM, Paolo Cavallini
> wrote:
>
>> Il 10/02/2018 14:38, Anita Graser ha scritto:
>> > Since Madeira is just around the corner, let's organize a round table
>> > discussion on this issue. I've started a section
On Sun, Feb 11, 2018 at 8:52 AM, Paolo Cavallini
wrote:
> Il 10/02/2018 14:38, Anita Graser ha scritto:
> > Since Madeira is just around the corner, let's organize a round table
> > discussion on this issue. I've started a section here:
> > https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeir
Il 10/02/2018 14:38, Anita Graser ha scritto:
> On Fri, Feb 9, 2018 at 11:01 AM, Richard
> Duivenvoorde mailto:rdmaili...@duif.net>> wrote:
>
> Maybe at a hackfest, foss4g or other meeting it is good to come together
> face to face so it is easier to actually SHOW each other the
> bear
On Fri, Feb 9, 2018 at 11:01 AM, Richard Duivenvoorde
wrote:
> Maybe at a hackfest, foss4g or other meeting it is good to come together
> face to face so it is easier to actually SHOW each other the
> bears/problems we see?
>
Since Madeira is just around the corner, let's organize a round table
Dear Nyall and all,
here are some of my thoughts mostly relating to GRASS GIS (although it may
not express views of the whole GRASS GIS developer team).
On Thu, Feb 8, 2018 at 8:55 PM, Nyall Dawson wrote:
>
> Here's the situation as I see it:
>
>
> The past
> ---
>
> We (the
Il 09/02/2018 09:34, Rashad Kanavath ha scritto:
> I am giving up on this contribution as it seems impossible to get small
> changes like this.
> Thanks for all your time.
Hi Rashad,
please be patient: bear with us, and we'll find the most efficient
solution. In QGIS we have a very friendly enviro
>
> I am giving up on this contribution as it seems impossible to get small
> changes like this.
> Thanks for all your time.
The change is not small. It might have important consequences in other
parts of Processing. I gave the PR a +1, probably without having
analyzed it in detail. Alex and Nyal
On 09-02-18 09:34, Rashad Kanavath wrote:
>
>
> I am giving up on this contribution as it seems impossible to get small
> changes like this.
> Thanks for all your time.
Hi Rashad,
Thanks for your time.
But I do think that you do not give enough credit to Alex et al here:
https://github.com/qgi
On Thu, Feb 8, 2018 at 5:51 PM, Paolo Cavallini
wrote:
> 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
On 9 February 2018 at 00:20, Moritz Lennert
wrote:
> 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
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)?
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
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
>
> 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
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 packag
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 of
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
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 - comprisin
18 matches
Mail list logo
