[Gvsig_english] gvSIG 1.9 (1243) some issues regarding the latest version

[Wolfgang Qual]

Hello Manuel,
thanks for your comment. This is a cruical state as many features are no
available, which I definitively need to be able to use gvSIG for real
life work: tables, join, event themes, spatial join etc. The functions
have improved a lot and quite some features are new, like the export to
dbf/xls. Well done. Today, I was able to do quite some work using only
Open Source tools like gvSIG and OpenOffice. I had to apply some
workarounds, but it worked. However, some function, like the dbf-export
of tables did not work at all. This needs to be changed within the
stabilization process. Otherwise, some may ask: why do they call this
program "stable"? On the other hand, I understand that a stable 1.9 is
very very important for the project. Therefore, I hope that some of the
described issues will be resolved soon. I'll keep my fingers crossed
(and will continue testing and writing nasty reports) ;)

Best,
Wolfgang

Am Freitag, den 14.08.2009, 15:42 +0200 schrieb Manuel Madrid:
> Hi Wolfgang.
> 
> UFF! Since we're now finishing the stabilization process, maybe it's too 
> late to do some of this changes on gvSIG 1.9. Nevertheless we'll have a 
> look.
> 
> Thanks for your report.
> Regards,
> Manuel.
> 
> Wolfgang Qual escribió:
> > Dear list,
> > some issues I ran into when trying to use gvSIG 1.9 in "real life" 
> > regarding tables, join function and event themes.
> > 
> > * JOIN Function:
> >    + if a table is loaded into gvSIG and a new column is added (edit 
> > mode), gvSIG will not accept this new column within the join dialogue as 
> > a key column. It just says: column could not be kept. Workaround: after 
> > saving the modified table, the table should be removed from the project 
> > manager. Loaded again, the new column is accepted by gvSIG.
> > * EVENT theme
> >   + it seems to be impossible to use a joined table as an input theme 
> > for the event theme dialogue. The strange error message "35" appeared. 
> > Workaround for me: export table as xls (dbf does not do the job, see 
> > below), open it in openoffice, save as dbf and load that table in gvSIG.
> >   + event theme can be created out of the dbf table described above. 
> > However, when I export that temporary layer to shapefile, all "umlauts" 
> > (ä,ü,ö,ß) will not be displayed correctly. It is not possible to correct 
> > this (using extShalom). I just failed. It did not even help to save the 
> > original table in utf-8 in open office (utf-8 is the standard encoding) 
> > and then create the event theme. EXPORT TO SHAPEFILE WILL ALWAYS RESULT 
> > IN BROKEN UMLAUTS. I would be MOST GRATEFUL, if someone would have an 
> > idea how to deal with this. ile eventtheme aus solch einer Tabelle, dann 
> > alle Umlaute defekt.
> > * Export table to dbf:
> >    + exporting tables to dbf created tables where original columns got 
> > mixed up completely. The resulting table was not usable at all. Sorry to 
> > say that.
> > * TABLES in general
> >   + it would be great, if integer values in xls/openoffice would be 
> > displayed in gvSIG also as integer values. Right now, numbers always get 
> > a ".0" at the end.
> > * LINK:
> >   + the link function is good, I would like to use it to identify false 
> > values of a key column. For me, selecting more than one records in one 
> > table was not reflected in the other table. Is this correct?
> > 
> > Any comments or ideas are appreciated very much. I hope that these 
> > issues can be reviewed within the stabilization process. I consider them 
> > as very important, as they make are cruical for my work.
> > 
> > Best,
> > Wolfgang
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
>