[Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment

Wed Jan 20 14:28:02 CET 2010

Hi Cesar,

that sounds excellent. Regarding file level locking,
I think you should not bother with it too much.
If people need multi-user access to geodata, they
should use a PostGIS databases and leave it to the
DBMS to handle conflicts -- it's designed to do that.
File system locking will never work that well.

Cheers,

Ben

----- Original Message -----
From: "Cèsar Ordiñana" <cordin at disid.com>
To: "Users and Developers mailing list" <gvsig_internacional at listserv.gva.es>
Sent: Wednesday, January 20, 2010 2:22:16 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in	production environment

Hi Simon,

First of all, thanks for all your feedback, suggestions and errors 
reported.

I'm deeply involved in the development of the gvSIG 2.0, so I would like 
to explain what is being done in relation to your points 6 and 8.

One of the main changes in gvSIG 2.0 is a complete design and 
implementation of the data access library. Knowing the problems of 
previous versions, like the ones you have highlighted, we added resource 
management to the library implementation.

This way, if the user opens many layers in the same or different views 
from the same file, or even many table documents, we know they share the 
same file. The resource management service also locks write access to a 
resource, so two different layers (in the same gvSIG instance) can't 
write a file at the same time, but one after the other.

So now we have the basic tools to be able to solve some of those 
problems, but still have to do some work to translate that knowledge to 
the application level. Things like:

- If you finish editing a layer, refresh other layers from the same file.
- Warn the user that he's trying to edit a layer which is being edited 
in another view.
- ...

I'm not sure how much development effort we will be able to spend in 
this problem, but I think in gvSIG 2.0 we will be able to handle those 
cases more gracefully, at least for the most regular ones.

All of this for the single gvSIG instance with many layers/views of the 
same file scenario. For the scenario of many gvSIG instances or other 
applications opening the same file, we could use file locking at the 
system level. But I hope this to be a more unusual case, as I don't 
think we will be able to work on it for the gvSIG 2.0 release.

Regards,

-- 
César Ordiñana Navarro
gvSIG software architect
DiSiD Technologies SL  http://www.disid.com

Simon Cropper (Botanicus Australia Pty Ltd) escribió:
> 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.
>
>   

_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.