Hello and thanks for your comments. Sorry to not have followed up on
previous replies from Paulo.
I agree that we all need to sending bug reports and assist with
documentation but this can be hugely time-consuming.
A good example might be a problem I had with CAD digitizing tool some time
ago. I
Am Mi, 5.04.2017, 20:45 schrieb DelazJ:
>
> http://www.opengis.ch/2016/02/04/increasing-the-stability-of-processing-algorithms/
The links in there are outdated. The correct/updates link is:
https://github.com/qgis/QGIS/tree/master/python/plugins/processing/tests
I hope it also works with GeoJSON.
Hi,
2017-03-28 20:43 GMT+02:00 Springfield Harrison :
>
> I agree. I am all in favour of choice, but less so for duplication.
>
> I would prefer one well design, well-documented tool rather than umpteen
choices, Each of which I have to try out and evaluate.
>
> I find that many of the tools are po
Hi,
Il 28/03/2017 20:43, Springfield Harrison ha scritto:
> I agree. I am all in favour of choice, but less so for duplication.
agreed. we are constantly streamlining and reducing duplication, it's an
ongoing process.
> I would prefer one well design, well-documented tool rather than umpteen
> c
I agree. I am all in favour of choice, but less so for duplication.
I would prefer one well design, well-documented tool rather than umpteen
choices, Each of which I have to try out and evaluate.
I find that many of the tools are poorly documented , don't work
intuitively or don't work at all. Mo
Il 28/03/2017 13:00, johnrobot ha scritto:
> Hi
> I do not want disable to all of the packages (GRASS etc), but I think that
> it would improve the user experience if there are not as many as 13 tools
> for buffering. We should be able to reduce this and I noticed that there are
> similar thoughts
Hi
I do not want disable to all of the packages (GRASS etc), but I think that
it would improve the user experience if there are not as many as 13 tools
for buffering. We should be able to reduce this and I noticed that there are
similar thoughts here,
https://hub.qgis.org/wiki/quantum-gis/Google_Su
Am Di, 21.03.2017, 21:23 schrieb johnrobot:
> I´m not convinced that having all these duplicates is a good thing. Do we
> really need 13 buffering tools? Why not try to minimize this? Having
> multiple tools for the same task only makes it harder for users and
> developers. Does QGIS have to expose
I´m not convinced that having all these duplicates is a good thing. Do we
really need 13 buffering tools? Why not try to minimize this? Having
multiple tools for the same task only makes it harder for users and
developers. Does QGIS have to expose all of the tools just because it is
possible?
Magn
Many processing tools are duplicates. For example, If I filter for
"buffer" I find 13 results in QGIS, GDAL, SAGA and GRASS libraries.
Since these last 3 are external projects, QGIS cannot control which
tools are in there. And why should "somebody at QGIS" choose for you and
everybody else whi
I noticed that there seems to be two tools (GDAL and QGIS) for reprojecting
data in Processing. Do we really need two separate tools? Why not merge
them?
Regards,
Magnus
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Processing-Duplicate-tools-for-reprojecting-tp5312941.
11 matches
Mail list logo
