Hi Rashad
Thanks so much for your email below….sometimes things are not always easy to
figure out, especially as QGIS gets bigger and more complex. We will really
value your contribution as we move forward … and we will try to come up with a
solution that works well for everyone.
Best regards
Hello,
Sorry for the misunderstanding about my last mail, I didn't want to
be disrespectful. I would like to continue the discussion about this
contribution.
We will push this contribution and try to answer to all
questions, comments or issues about it. We will submit with my colleagues in
few da
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 zer
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
>
> >
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,
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 freq
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
On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya wrote:
> I dont think that it is possible to make it more generic. It's not only
> descriptors with only outputs and inputs. Each backend app has its own
> logic. GRASS needs outputs to be converted to its own format. SAGA accepts
> only SHP for vector
I dont think that it is possible to make it more generic. It's not only
descriptors with only outputs and inputs. Each backend app has its own
logic. GRASS needs outputs to be converted to its own format. SAGA accepts
only SHP for vector layers and generates its own SDAT format for raster
outputs.
Hi Rashad,
2018-02-07 15:41 GMT+02:00 Rashad Kanavath :
> Do you see a possibility of a generic processing provider?. One that can
> read descriptor files and run algorithms!.
This is possible in the ideal world of ponies and rainbows. In real
world we need
to deal with different types of the inp
Hello victor,
Do you see a possibility of a generic processing provider?. One that can
read descriptor files and run algorithms!.
I see processing as a single plugin (included in QGIS or not). And if it
can avoid need to have sub-plugin managed by all those other development
team. That's even bett
I dont see the advantage in having providers in core. And if there is an
advantage, it's clearly not in how easy it is going to be to maintain the
plugin. 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
ha
12 matches
Mail list logo
