[Gvsig_english] gvSIG and external tables, font-encoding etc.

Thu Apr 9 15:57:21 CEST 2009

Hello Francisco,
well, thank you very much for all your messages.. and your programming work. I 
really appreciate this. So I will keep my fingers crossed.,,
I will try to test your extension more intensively. But for us as an 
administration, only official extensions will be applicable. Thanks again and 
Happy Easter!

Best,
Wolfgang

Am Dienstag 07 April 2009 14:23:20 schrieb Francisco José Peñarrubia:
> Wolfgang, I'm part of the gvSIG team (one of the developers).
>
> But now we are preparing 1.9 release, and is difficult to put new
> functionalities when stabilization period. It's not a developers
> decission, so it takes time to convince other people to do some changes
> that may introduce new bugs.
> If you think this is a bug, it may be easier, but is not clear if this
> is a new capability or not. Also, it may help it you test the extension
> and think it is safe (or find a problem and I will try to solve).
>
> Also, to put code inside an official relase, it takes time and money
> (documentation to users, developers, better user interface,
> testing....). That's why this is not an official release, is easier to
> publish and the people can test it before put in the official relase.
>
> Anyway, we are discussing about if it's good to take some risks or not.
> Maybe in a few days they will tell you if 1.9 will solve your problem.
>
> Best regards.
>
> PS: BTW, may vote is yes to include ;-)
>
> Fran Peñarrubia
> gvSIG Team.
> www.scolab.es
>
> Wolfgang Qual escribió:
> > Hi Francisco, list and: developers.
> > Great thanks to Francisco for his answers. Unfortunately, my problem is
> > not yet solved. I set the encoding on my machine to latin-1 (export
> > LANG=...), but now, it is not even possible to manually enter these
> > german umlauts. I will revert this setting.
> > I consider this encoding-issue as very important; therefore, I would like
> > to ask the gvSIG-team, whether a function (like extShalom) to set the
> > encoding will be added to gvSIG core functionality. I am really surprised
> > that I did not discover this issue before ;(
> > BTW, postGIS (@Francisco) is no option for me, as I have no
> > postGIS-installation here...
> >
> > Best,
> > Wolfgang
> >
> > ----8<----
> >
> > Am Dienstag 07 April 2009 10:26:21 schrieb Wolfgang Qual:
> >> Hi Francisco and list,
> >> maybe another important information:
> >> I tried the following:
> >> 1) create a _new empty point-shapefile_ with only one string-colum in
> >> gvSIG. 2) use the field-calculator and set all records of that column to
> >> 'tae' 3) use the replace-tool in the field calculator to replace each
> >> 'tae' with '_TÄ': replace([field1],'tae','_TÄ').
> >> However, gvSIG will not write that 'Ä', but only a little square (on two
> >> machines, one running 1.1.2 and the other 1.9 alpha something).
> >> _But_ it _is_ possible to manually write 'Ä' in the table. This is very
> >> strange...
> >> By the way: typing "echo $LANG" on the command line will give that
> >> result: de_DE.UTF-8
> >> Could this setting cause these problems? Your comments are apprecitated
> >> very much... I really do need these Umlauts....
> >>
> >> Best,
> >> Wolfgang
> >>
> >> Am Montag 06 April 2009 12:53:58 schrieb Francisco José Peñarrubia:
> >>> Hi, Wolfgang.
> >>>
> >>> gvSIG is well tested to work with ñ. The default enconding with PostGIS
> >>> and dbf tables is LATIN1 (ISO-8859-1). To operate with dbf tables in
> >>> different encodings, you may need to install extShalom plugin (from
> >>> non-official extensions repository).
> >>>
> >>> https://gvsig.org/plugins/downloads/extshalom
> >>>
> >>> Best regards.
> >>>
> >>> Fran Peñarrubia
> >>> www.scolab.es
> >>>
> >>> Wolfgang Qual escribió:
> >>>> Good morning everyone.
> >>>> I will continue to report about my little (serious!) problems
> >>>> regarding german umlauts and modifiying attribute tables in gvSIG. My
> >>>> table contains values like '2344_TÄ' and I would like to replace that
> >>>> '_TÄ' with 'tae'. The strange thing is that it is _possible_ to select
> >>>> these values using the filter function with the expression
> >>>> [column_name] like '%_TÄ'; all those values are selected - wonderful.
> >>>> However, when trying to replace the questioned values using the field
> >>>> calculator, gvSIG fails: nothing is replaced. It is only possible to
> >>>> replace the umlauts manually. I do not understand this (reaction of
> >>>> gvSIG). Therefore, I would be most grateful for some comments or _any_
> >>>> ideas on how to solve this. BTW, do you have the same problem with the
> >>>> spanish 'ñ'?
> >>>>
> >>>> Best regards,
> >>>> Wolfgang
> >>>>
> >>>> ----8<------
> >>>>
> >>>> -------- Original-Nachricht --------
> >>>>
> >>>>> Datum: Thu, 2 Apr 2009 13:50:47 +0200
> >>>>> Von: Wolfgang Qual <wolfgang.qual at gmx.net>
> >>>>> An: Users list <gvsig_internacional at runas.cap.gva.es>
> >>>>> Betreff: [Gvsig_english] gvSIG and external tables, font-encoding
> >>>>> etc.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hi list,
> >>>>> I have some remarks/questions on external tables and font-encoding
> >>>>> regarding
> >>>>> gvSIG 1.1.2 and the coming versions of gvSIG.
> >>>>>
> >>>>> * currently, it is not possible to edit external tables that were
> >>>>> imported from csv. It seems, as if only dbf-files can be edited in
> >>>>> gvSIG. You might say: well, do this conversion within openoffice.
> >>>>> Right. But on my computer, I
> >>>>> only have openoffice 2.3 installed (the official computer of my
> >>>>> office) - and
> >>>>> this version of calc is not able to write me a dbf-file. It simply
> >>>>> crashes.
> >>>>> This strange behaviour is reported as a bug in calc. I can also
> >>>>> convert this
> >>>>> file in excel (currently, excel is still available..), but there, I
> >>>>> do not have any possibility to modify/set the font encoding.
> >>>>> * Font-encoding: I do not know, which font-encoding gvSIG accepts. I
> >>>>> imported
> >>>>> a dbf-file that was created in Excel. This table has some values
> >>>>> (text) which
> >>>>> needs to be processed. To be more precise: I need to convert
> >>>>> substrings like 'ae' into Ä (german umlaut). I found the function
> >>>>> (replace) in the field
> >>>>> calculator of gvSIG. But this will not create an 'Ä' but only a
> >>>>> square-shaped
> >>>>> character - I think that the font-encoding is the reason for this.
> >>>>>
> >>>>> Therefore, I would be really happy, if you could answer me the
> >>>>> following questions:
> >>>>>
> >>>>> * how do you work with csv-files in gvSIG: is it really true that
> >>>>> only dbf can
> >>>>> be edited? Which software are you using to save files as dbf?
> >>>>> * which font-encoding is used within gvSIG? Or: which encoding do you
> >>>>> use when
> >>>>> exporting a file from openoffice into a different format?
> >>>>> * will there be a possiblity to edit tables derived from csv/txt in
> >>>>> gvSIG?
> >>>>>
> >>>>> Best regards,
> >>>>> Wolfgang
> >>>>>
> >>>>> _______________________________________________
> >>>>> Gvsig_internacional mailing list
> >>>>> Gvsig_internacional at runas.cap.gva.es
> >>>>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> >>>
> >>> _______________________________________________
> >>> Gvsig_internacional mailing list
> >>> Gvsig_internacional at runas.cap.gva.es
> >>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> >>
> >> _______________________________________________
> >> Gvsig_internacional mailing list
> >> Gvsig_internacional at runas.cap.gva.es
> >> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> >
> > _______________________________________________
> > Gvsig_internacional mailing list
> > Gvsig_internacional at runas.cap.gva.es
> > http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional