On Wed, 17 Apr 2013 10:08:56 -0700 (PDT)
vinayan vinayan...@gmail.com wrote:
I think it is best to have maximum algorithms available in c++ ap, in the
analysis module(i see that some are already available)..I would be willing
to contribute to it if required
All fTools functions are in
Victor,
Maybe I'm wrong but I think that Sextante does not work on qgis 1.8, right?
Note that, in such a case, feedback from users will be limited as most
users work with the stable release.
I have a 1.9 version on the little Mac and test from time to time.
Agus
On Wed, Apr 17, 2013 at 12:27
hi!
If I remember correct Carson Farmer startet to bring the algorithms into a
cpp library (which would be a good and fast choice i think)
I'd welcome having fast and reliable algorithms in cpp .. So I agree with
Agustin - very welcome work..
regards
Werner
On Thu, Apr 18, 2013 at 4:48 PM,
Agustin
SEXTANTE now only works on 1.9 (to become 2.0 soon...), but all this
discussion is about tools in versions = 2.0. So those users that
work with the stable version will have SEXTANTE in their stable 2.0
I agree with the need of that c++ conversion. Once that is ready,
wrapping from
That was my thought...but for some reasons some operations are very
slow from the fTools code, even if they use indexing. I have a couple
of examples with points in polygon calculation, that take ages in
fTools (or the same SEXTANTE algorithm, which has the same code), and
they shouldn't. Maybe
Victor,
I know this is about = 1.9, that's is the point:
I want to stress the contradiction about asking for feedback while
the tools cannot be tested on the stable version that most users use.
Qgis has an extraordinary feature:
users can test experimental tools developed as plugins while keeping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 17/04/2013 07:42, Anita Graser ha scritto:
I see. So you'd suggest to keep only Sextante code (where duplicates exist!)
but
provide shortcuts from the menu? I'd +1 that.
I've been testing a variety of functions in the menus and in Sextante
Anita, yep, remove code for ftool functions that are in sextante but keep
vector menu shortcuts.
On 17 Apr 2013 12:42, Anita Graser anitagra...@gmx.at wrote:
On Wed, Apr 17, 2013 at 3:19 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:
There might be a way to make most people happy here.
I
Paolo, imo decision of looking into this option for 2.0 vs 2.1 should be
primarily driven by quality. If qgis can offer better quality in vector
functions by maintaining the two mechanism for 2.0 then it should be
deferred to 2.1. If the opposite is true, then might be worth for Victor to
weight
Hi,
personally I think that we should leave only SEXTANTE but first need
to implement all missed functionality.
On Tue, 16 Apr 2013 09:34:13 -0700 (PDT)
Anita Graser anitagra...@gmx.at wrote:
In case of GDAL tools, I see the advantage of being able to copy the GDAL
code.
Agreed, having such
Bernhard
I am sorry to hear about your bad experience. Could you detail a bit
more about what you are doing (algorithms you are running, etc)?.
PostGIS layers should work without problems, but I have recently fixed
a problem with PostGIS when using SAGA algorithms, so there might be
other issues
Hi Victor,
thank you for your quick reply and even more for all the work you are
doing for SEXTANTE. If it is operable (and I am sure, it will be)
SEXTANTE will be a big step forward for QGIS!
I am going to send you the model an layers (as shape files, you need to
import two of them into
I like the idea of allowing menu entries to be defined from SEXTANTE
algorithms, as a shortcut to them. If we agree on that, I could start
working on it.
Thanks everyone for you ideas!
Cheers
Victor
2013/4/17 Bernhard Ströbl bernhard.stro...@jena.de:
Hi all,
for a course I am about to give
I agree with allowing the user to define some Menu entries. As an end user
I'd rather have all Analytical tools in one place, but this would allow
people to not loose their habit of calling some more commonly used tools
(I agree with Paolo, a poll with be good) from the Menu.
Sextante is more
Hi all,
just want to inform you that Victor was able to solve my two problems.
Number 1 (CRS missmatch) was kinda my fault (or let's say the fault of a
former QGIS version where my project originally was created in: QGIS did
compare proj4 definition and picked the first CRS the definition of
Bernard's problem was related with using non-file layers in the
modeler. It was a very easy fix, so please, everyone that's using
SEXTANTE, share your problems so we can work on them and make the
software more stable. :-)
Thanks in advance!
2013/4/17 Bernhard Ströbl bernhard.stro...@jena.de:
Hi
Wouldn't it be good to have SEXTANTE as category in the bug tracker
(like fTools and GDAL tools)?
Bernhard
Am 17.04.2013 12:27, schrieb Victor Olaya:
Bernard's problem was related with using non-file layers in the
modeler. It was a very easy fix, so please, everyone that's using
SEXTANTE,
Well since I can't code I can help with the testing, just point me where to
start and I will try Sextante
Sent from Samsung tabletFilipe Dias filipesd...@gmail.com wrote:I agree with
allowing the user to define some Menu entries. As an end user I'd rather have
all Analytical tools in one
Get Qgis Master, randomly (or deliberately) choose tools that you know how
to use and run them. If they don't work as expected, report a bug:
http://hub.qgis.org/projects/sextante/issues
When I have enough time, I do my regular work using Qgis Master and report
the bugs that I find.
On Wed,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 17/04/2013 10:29, Filipe Dias ha scritto:
I agree with allowing the user to define some Menu entries. As an
end user I'd rather have all Analytical tools in one place, but
this would allow people to not loose their habit of calling some
more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 17/04/2013 09:49, Victor Olaya ha scritto:
I like the idea of allowing menu entries to be defined from
SEXTANTE algorithms, as a shortcut to them. If we agree on that, I
could start working on it.
yes, nice idea - be careful not to generate
Am 17.04.2013, 18:26 Uhr, schrieb Paolo Cavallini cavall...@faunalia.it:
so until we have a proper, automatic test at every commit, I would
prefer to rest on solid ground.
Let me just note that I'm not so sure how solid our ground is. E.g. ftools
union tool used to work fine and is broken
+1 for keeping the vector menu.
I think it is best to have maximum algorithms available in c++ ap, in the
analysis module(i see that some are already available)..I would be willing
to contribute to it if required
thanks
Vinayan
--
View this message in context:
Hi,
I know this thread has been silent for a while but I think it's important to
bring it up once more.
I'm currently trying to develop some materials and wondering if they should
cover ftools/GDAL or Sextante mainly. Currently, it sounds like it is
certain that Sextante will be around in future
I agree. Sextante makes finding the appropriate tools a lot easier,
specially when the user is doing GIS analysis for a long time.
In ArcGIS 9.1 or 9.2 ESRI removed the Analysis tools from Menu and put them
all on ArcToolbox. A lot of users complained and they ended up creating a
Geoprocessing
There might be a way to make most people happy here.
I find the vector menu a nice ui shortcut for useful functions. If sextante
relevant functions are at par (or better), couldn't the vector menu items
stay, which would please many, and when clicked triggers sextante's
function dialogue? Victor?
On Wed, Apr 17, 2013 at 3:19 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:
There might be a way to make most people happy here.
I find the vector menu a nice ui shortcut for useful functions. If
sextante relevant functions are at par (or better), couldn't the vector
menu items stay, which
I strongly oppose eliminating the tools in fTools and gdaltools from
the main menu.
Your argument contemplates the picture from the point of view of the
developer only.
While having certain tools (i.e. R scripts, original sextante, OTB...)
within the
Sextante menu makes sense, from a user point of
Agustin
I actually have always wondered why fTools were
within Sextante also.
The main reason is that being part of SEXTANTE, they become more
powerful tools. They can be used in the modeler, in the batch
processing interface, in the console... Plus, history is kept for
those commands as
Yeah,
I already needed to use as batch when SEXTANTE wasn't that popular, so I
had to use grass instead.
So just the batch feature already justifies the implementation of FTools in
SEXTANTE, thank you guys, it's really a worthy tool.
Caio Hamamura
2013/3/25 Victor Olaya vola...@gmail.com
On 25/03/2013, at 19:52 , Agustin Lobo wrote:
I strongly oppose eliminating the tools in fTools and gdaltools from
the main menu.
Your argument contemplates the picture from the point of view of the
developer only.
While having certain tools (i.e. R scripts, original sextante, OTB...)
Hi,
On Tue, 19 Mar 2013 19:40:03 +0100
Martin Dobias wonder...@gmail.com wrote:
The port of original algorithms to SEXTANTE seems to be nearly
complete and SEXTANTE has superior approach of creating the GUI for
algorithms dynamically (similar to GRASS toolbox) instead of manually
creating
On 03/19/2013 11:34 PM, Alexander Bruy wrote:
Hi,
On Tue, 19 Mar 2013 19:40:03 +0100
Martin Dobias wonder...@gmail.com wrote:
The port of original algorithms to SEXTANTE seems to be nearly
complete and SEXTANTE has superior approach of creating the GUI for
algorithms dynamically (similar to
Hi!
I am usually also for cleaning up - and removing stuff like duplicate
labelling and such things but for functions like GDAL and fTools i rather
tend to hold them as long as there are not all equivalent function
available elsewhere.
My point would be to rather clean the GUI (less
While we work on moving everything into SEXTANTE, a quick solution can
be to add new algorithms in SEXTANTE that call the fTools and GDAL
tools and pop up the current dialogs. They will not be available in
the SEXTNATE modeler or batch processing interface, but at least they
will be in SEXTANTE
On Wed, Mar 20, 2013 at 9:05 AM, Victor Olaya vola...@gmail.com wrote:
While we work on moving everything into SEXTANTE, a quick solution can
be to add new algorithms in SEXTANTE that call the fTools and GDAL
tools and pop up the current dialogs. They will not be available in
the SEXTNATE
I'm afraid it would be super confusing to have tools in Sextante but
not available in Modeller.
hmmm, I agree that, in this case, it will be confusing, but SEXTANTE
supports having algorithms that can be in the modeler and not in the
toolbox, or in the toolbox and not in the modeler. There are
I also would miss the command line viewer that's in GDAL Tools. That is
extremely useful when prototyping something that I plan to move to a script.
I forgot about the command line window and the (folder) batch
geoprocessing in gdal tools...
please don't get rid of them without a replacement
Hi,
I have been wondering recently about the status of original fTools and
GdalTools plugins and their algorithms in SEXTANTE. As far as I
understand, the implementation in SEXTANTE is independent from the
original plugins. That means that any changes in fTools or GdalTools
have to be ported
. So...what about removing the original
fTools and GdalTools plugins before 2.0 and focusing on improvements
of their counterparts in SEXTANTE?
it does not seems so easy to me, in sextante there are missing tools,
just to make examples, (gdal) clipper, gdaldem, eliminate sliver
polygons... and
Before doing that, we should make sure all algorithms are in SEXTANTE.
Some of them might not be in there, because I did not ported them,
considering that another algorithm was equivalent. Particularly, the
dem tools and the interpolation tools in SAGA should replace the ones
in GDAL and add much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 19/03/2013 20:42, Victor Olaya ha scritto:
Anyway, I think that redundancy in SEXTANTE is not so bad as having
several ways of doing the same thing in the QGIS interface, since
users will understand that algorithms come from differnt providers
42 matches
Mail list logo
