<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I agree with Stefan.<br>
<br>
I have found comparison tables of little use as the compiler has to
summarize what is probably quite complex routines. They rarely give a
potential user like myself the complete picture.<br>
<br>
My view has been that the only way to evaluate the usefulness of a
program is to use it on actual data trying to do actual things.<br>
<br>
I have tried multiple OS GIS packages and they all do different things
in different ways. Some useful some novel (to me).<br>
<br>
What really counts is if you can use one program to complete your
normal workflow without needing to use other packages.<br>
<br>
I am not saying that someone should not use multiple packages during
their normal work week only that you should be able to do your normal
work without having to transfer data (and half the time actually
convert data) between various packages to get what you need done.<br>
<br>
So from my point of view projects should not look at other projects,
developers should not list functionality of their program or any other
combination. Users should provide standard workflow tasks -- repetitive
tasks sequences they complete regularly. Then be asked to complete
those tasks on each of the programs being tested. Then the users rate
ease of setup, ease of use, suitability of output, support, etc. The
actual list of user experience ratings can be knocked up by an overview
committee. This committee could also vet the users who put their hand
up to ensure a good spectrum of users and tasks, from different
sections of society (academic, commercial, newbie) are all represented
and no bias exists.<br>
<br>
If developers think this might be too harsh (as users may not fully
understand what is going on or how the program works), maybe a middle
ground would be that the developers submit a solution to these workflow
processes. The users follow these instructions and evaluate the
outcome. This avoids users baulking at some quite eccentric GUI
interfaces or program setup (solution must provide clear setup
instructions for Windows and Linux). These solutions are tried and
reviewed by the user. The workflows, results, comments and developer
solutions can be collated onto one site (the OSGeo site seems
appropriate) as a valuable resource for developers and user alike.<br>
<div class="moz-signature">
<p>Cheers Simon</p>
<p style="margin-left: 36pt;">
Simon Cropper <br>
Botanicus Australia Pty Ltd<br>
PO Box 160, Sunshine, Victoria 3020.<br>
P: 9311 5822. M: 041 830 3437.<br>
<a href="mailto:scropper@botanicusaustralia.com.au">mailto:
scropper@botanicusaustralia.com.au</a> <br>
<a href="http://www.botanicusaustralia.com.au">web:
www.botanicusaustralia.com.au</a> <br>
</p>
</div>
<br>
<br>
Stefan Steiniger wrote:
<blockquote cite="mid:4B2E96F3.9090301@geo.uzh.ch" type="cite">Hei all,
<br>
<br>
thanks for Cameron on keeping me in the loop, and to Markus for
<br>
remembering :) I am now subscribed to this list.
<br>
<br>
I think Pauls idea sounds interesting - because this whole comparison
<br>
thing is
<br>
a) quite cumbersome when we have 10 desktop GIS (+ X), and
<br>
b) neither really worth because desktop GIS are used for a multitude of
<br>
tasks, while web map Servers or databases aren't that much - right?
<br>
<br>
So as Paul is quoted on the osgeo wiki: one needs to set up use cases
<br>
first (just wrote that today in a new article too, which contains a
<br>
section on selecting free GIS software). And I also discovered that
just
<br>
most of the projects have a different focus during my evaluation. Which
<br>
of course does not mean that such thing should not be presented - but
it
<br>
must be focussed in some way or the other to have a benefit. And as a
<br>
side note, I am not sure if measuring processing times makes sense
<br>
either, as GIS analysis feature sets are so different.
<br>
<br>
However, I am in for testing with OpenJUMP.
<br>
<br>
Two more notes:
<br>
- my comparison tables are now already 2 years old now (from 2007),
i.e.
<br>
need some update (but the last pub in Ecological Informatics took into
<br>
account newer developments too, but is superficial and focused towards
<br>
the "average" GIS users).
<br>
- I gave a talk about this at OGRS:
<br>
<a class="moz-txt-link-freetext" href="http://www.ogrs2009.org/doku.php?id=keynotes">http://www.ogrs2009.org/doku.php?id=keynotes</a>
<br>
pdf can be downloaded from there.
<br>
<br>
cheers from Germany right now (Xmas)
<br>
stefan
<br>
<br>
PS: I know also of this comparison by T. Hengl et al. on Grass vs. SAGA
<br>
for Geomorphologic Analysis
<br>
<a class="moz-txt-link-freetext" href="http://www.igc.usp.br/pessoais/guano/downloads/Hengl_etal_2009_gmorph.pdf">http://www.igc.usp.br/pessoais/guano/downloads/Hengl_etal_2009_gmorph.pdf</a>
<br>
<br>
<br>
Paul Ramsey schrieb:
<br>
<blockquote type="cite">Interested in a different approach that is
lower impact, but still
<br>
interesting and entertaining? Have developers review a "competing"
<br>
project and then present their findings, in the form of "What I love
<br>
about ___, what I hate about____".
<br>
<br>
Jody Garnett presents "What I love about QGIS, what I hate about QGIS."
<br>
Jorge Sanz presents "What I love about uDig, what I hate about uDig."
<br>
Tim Sutton presents "What I love about gvSIG, what I hate about gvSIG."
<br>
<br>
Not only do you get an unvarnished view, but you can have shorter
<br>
presentations with a discussion segment at the end of each one.
<br>
<br>
Works for almost any application category too.
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Discuss mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a>
<br>
<br>
<br>
</blockquote>
</body>
</html>