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

Mon Aug 17 17:26:46 CEST 2009

Hi Manuel, list,
I have some more comments on version 1243. In the meantime, another 
build has been published, but I had no time to install that one.

* even if a custom font encoding is set within the preferences dialogue, 
gvSIG will ignore that setting. I still had to manually set the font 
encoding to a new table using the extShalom Dialogue. This is not that 
hard,
but it would be even better, if I had not to do so.
* the summarize function did not work for me; within the dialogue, I 
could set the desired settings, but once I pressed OK (or calculate or 
execute - I just forgot the name),  the error message "summarize: feld 
existiert nicht" (translated: summarize: field does not exist). items 
that should be included contained only integer values - I may have done 
something wrong, but I do not what this should be...
* Shapefile with tables which contain joined fields can be exported to 
another shapefile. This is a cool feature, as it makes it possible to 
make the joined table _permanent_. However, gvSIG adds a "link_" prefix 
to each joined field. As the number of allowed characters in a table is 
limited to 10 (?) characters, the field name gets truncated and useful 
information is lost. Instead, fields get this "link"-prefix information 
which is not really necessary.  Example: "a_testfield" will become 
"link_testf".
I would suggest to add an option "save with link prefix" which can be 
deactivated by the user.
* the join-dialogue allows the user to set field prefixed which can be 
very useful. However, the custom field prefix will be lost or replaced 
by the above mentioned "link_" prefix, once the shapefile with the 
joined table is exported to a new one (in order to make the join permanent).
* the query builder (filter?) get's little bit slow sometimes (as it 
lists all possible values of a selected column). Wish: option to 
deactivate the listing in order to save time.
* rename fields (within edit mode): wish: deactivate the mechanism to 
sort fields according their position in the alphabet. It's just 
confusing (at least for me and for my fields that were so similar: 
link_kind, link_kindp, ...link_something).

That's all for today ;) . Hope that this information is useful for you.
Best,
Wolfgang

Manuel Madrid schrieb:
> Hello Wolfgang.
>
> You're right. It's suposed that a stable version don't have this kind of 
>   errors. The problem is that some of this bugs, specially the ones 
> regarding data acces (e.g. tables), are very difficult to fix (even 
> impossible some times) in gvSIG 1.9. This is because we're doing a 
> strong refactoring in gvSIG 2.0. In fact, some errors needs the 
> refactoring to be fixed.
>
> Anyway, let us have a look, Ok?
>
> Nasty? not so much ;) Be sure we really apreciate your contribution.
>
> Best regards,
> Manuel.
>
>
>
> Wolfgang Qual escribió:
>   
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>
>>     
>
>   

-- 

	*Wolfgang Qual

* *Referat für Gesundheit und Umwelt*
Umweltschutz
Umweltvorsorge
RGU-UW 11

Bayerstraße 28a
80335 München

Telefon +49 - 89 - 233 - 4 77 17
Telefax +49 - 89 - 233 - 4 77 05

http://www.muenchen.de/umweltatlas
uw11.rgu at muenchen.de
Bitte beachten Sie die Hinweise zur elektronischen
Kommunikation mit der Landeshauptstadt München:
http://www.muenchen.de/ekomm