[Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment
Simon Cropper (Botanicus Australia Pty Ltd)
scropper at botanicusaustralia.com.au
Wed Jan 20 07:22:21 CET 2010
Hi,
I was asked by a list member to provide feedback regarding the use of
gvSIG in a production environment. He communicated to me directly so the
list was not privy to the conversation. I respect his wishes not to have
the conversation on record but I would prefer to throw my observations
down so everyone can contribute/criticize/comment and the developers can
identify future priorities. Without going into the full conversation the
following points were *made by me* regarding gvSIG. I have highlighted
some salient points.
1. I have been using gvSIG as my primary GIS package since about
October 2009, or at least when the stable release of gvSIG 1.9 (BN
1253) was released.
2. As you will of noted I made comment on the list early in this
period that gvSIG+Sextante was the first OS GIS that allowed me to
complete my normal workflow without either resorting to the use of
ArcView or other OS packages.
3. Since then I have completed 2 'typical' projects and 1 'quite
large' and challenging project (the largest and most complicated
in my biennial calendar) and gvSIG has provided a robust
relatively stable GIS system.
4. You would have noted that the armada of posts on the server. These
are feedback as I push the limits of the package. Feedback I hope
will be valuable to developers and will result in an overall
improvement to the package.
5. In comparison to the pseudo standard - ArcView 3 - gvSIG is
comparable or excels in its functionality. The only area that
still a few glitches is the map routine; does maps quite well but
some combinations throw it into a spin. These problems are
transient however and no data to date have been lost.
6. The only problem I have encountered that has caused data
corruption (and I really tried hard to get this to happen after I
noted a couple of glitches) was editing an instance of a file
represented multiple times within the same view. *In theory, gvSIG
should prevent this from happening (i.e. editing this file without
first closing the other instances being used by gvSIG).* That
said, on review of all the other GIS packages and ArcView 3, I
note that they also do nothing to achieve an exclusive file lock
when editing a file.
7. I tested gvSIG 1.1.2 a while ago and decided it was not suitable
for my needs. When the Beta for 1.9 became available I found it
had the functionality but crashed doing simple things (=good to
play with, bad to use in production). Once the stable version of
gvSIG was released I found it did ~70% of what I needed but when
combined with Sextante did 95% of what I needed and a whole bunch
more that I only wish I had the capability of doing (spacial
analysis, image classification, etc).
8. After several months using gvSIG v1.9 (BN 1253) *I have drawn the
conclusion that the program is suitable for a production
environment*. *That said, the routines assumes that the user do
things in a particular way and if they don't it can kick up an
error.* As a programmer myself the cause of this is obvious --
*the developers have not constrained the use of the routine to a
particular action or developed a graceful error capturing
routine.* For example, if you edit a file which is currently
displayed in a view elsewhere (i.e. not the instance you are
editing) the program will generate an Java heap error (not very
descriptive). Apparently this is a known NO NO as gvSIG does not
exclusively lock the file (nor does any other GIS package for that
matter). *To me this is purely a programming error* *- you either
prevent the editing happening or automatically search for other
instances and turn them off while the edit is in progress.* *In
most of the situations that I have had problems the programmers
have not ensured the environment is correct or captured errors
gracefully and the result has been odd behaviour or an error
message.* After detailed investigation I find that I was asking
gvSIG to do something it could not do but it had not captured it
early enough or gracefully reminded me that that is not allowed.
Another 'problem' that comes to mind is the use of special
characters in the file names -- I think this has more to do with
Java rather than gvSIG -- use the minus sign in a name and all
hell breaks loose.
9. *So I suppose the warning is that if you have a reasonably adept
worker that is familiar with computers and GIS, gvSIG is
fantastic.* *For a rank amateur, there is a potential to have
regular problems being encountered as they blunder along.* In the
absence of good detailed tutorials in English, these problems
can't be avoided. *So if you plan to use gvSIG is commercial
environments where users are unskilled I suggest detailed tutorial
be developed and some training programs considered.* *If you feed
gvSIG what it wants it works like a dream.*
10. ... please don't get me wrong I really like gvSIG and still
continue to use it. In fact I am writing some tutorials myself to
help fill in the void. ...
11. The other thing to consider is that, at least in my opinion even
considering my 'negative' comments above, gvSIG is BEST OF BREED.
All these problems are also apparent in all the other OS Desktop
GIS products I have reviewed; and I have trialled quite a few.
--
Cheers Simon
Simon Cropper
Botanicus Australia Pty Ltd
PO Box 160, Sunshine, Victoria 3020.
P: 9311 5822. M: 041 830 3437.
mailto: scropper at botanicusaustralia.com.au
<mailto:scropper at botanicusaustralia.com.au>
web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au>
More information about the Gvsig_internacional
mailing list