[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 12:08:28 CET 2010
Ben,
In making a direct comparison, the Open Source Community far exceeds the
service provided by paid-for licensed products (=OS Community moderate
to good; Paid-for Service Lousy). This does not mean they can not
improve. As I have mentioned in the past the lists can be like black
holes - there is no tracking system and no obligation for someone to answer.
I will also note that most people on the lists are old hands at GIS --
very few newbies. The list is not as inviting as some forums. That said,
the experience base is quite high and if you can rouse someone interest
you can get some direct and pertinent answers.
The other issue is time or should I say time zone. Very few people on
the list that respond to postings are in my time zone. In order to get
answers you need to be willing to watch for a response at night and
answer quickly otherwise you can wait several days for a simple answer.
This by far the biggest hurdle, in a production environment, some people
just can't wait to long. You will have noticed that for some posts I
respond to myself several times with extra information or updates before
I get a response.
For someone like myself, who tinkers, programs, experiments and is the
boss, this is not that big an issue (although irritating at times), but
for others it can be problematic. Part of the solution is the
development of good tutorials in English -- the gvSIG team is working on
this and I am also contributing.
BUT lets face it I am not that typical of your list members. Over the
last few months I feel I have dominated the lists with comments,
questions, problems, etc. At times I expect to get a comment from the
moderator asking me to tone down. From comments off list and on list I
get the impression lots are watching but few are participating.
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>
On 20/01/2010 7:30 PM, Benjamin Ducke wrote:
> Hi Simon,
>
> Thanks for your detailed feedback.
> I would be interested in one more aspect:
> how do you judge the support level of gvSIG
> (and perhaps open source projects in general),
> compared to paid-for support of licensed
> products?
>
> Are the mailing lists and reaction times sufficient
> to support critical work? Or do you think another
> support level (perhaps paid-for) would be more
> adequate?
>
> Thanks,
>
> Ben
>
> ----- Original Message -----
> From: "Simon Cropper (Botanicus Australia Pty Ltd)"<scropper at botanicusaustralia.com.au>
> To: "Users and Developers mailing list"<gvsig_internacional at listserv.gva.es>
> Sent: Wednesday, January 20, 2010 7:22:21 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> Subject: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment
>
> 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.
>
>
More information about the Gvsig_internacional
mailing list