About dealing 2-byte code characters(ex. Japanese) in new maptools

Dear Ono-san and Professor Bivand,

In my environment, Japanese characters in your example works fine with
read.dbf() in maptools ver. 0.4-8.

Thank you for this contribution - it is not easy to debug
platform-dependent issues like this. I think having a corpus of files
would also help - as you mention below, the coding standard may differ as
does the platform. Having a small collection of DBF files known not to
behave the same across platforms should help, I hope - I can host them, or
maybe one of those of you close to the 2-byte character problem could host
them?

My environment: VineLinux3.0, R-2.0.0_ja-1vl1, maptools ver. 0.4-8

which also means foreign_0.8-0, because maptools_0.4-8 depends on it. Note 
that the problem was on Windows XP, I think with the standard binary R 
from CRAN.

I am afraid that it is due to EUC-JP encoded DBF file and R localized
into Japanese, though. 

This is possible, but all input is helpful here, also because R will 
migrate towards multi-character support at some stage.

Availing myself of this question, let me ask a way to confirm if
read.dbf() has been surely replaced by maptools.  I have just done
"update.packages()" for obtaining the latest foreign and maptools.

The internal function dbf.read(), accessed as maptools:::dbf.read() in 
maptools up to 0.4-6, and as dbf.read() in maptools 0.4-7 is not present 
at all in maptools 0.4-8. If you just type the names of the functions at 
the prompt, the final line shows which namespace they live in:

library(maptools)

Loading required package: foreign

read.dbf

function (file, as.is = FALSE) 
{
....
    df
}
<environment: namespace:foreign>

shows that read.dbf() from foreign is being used.

Roger Bivand

--
Susumu Tanimura
Dept. of Socio-environmental Medicine
Inst. of Tropical Medicine, Nagasaki University

_______________________________________________
R-sig-Geo mailing list
R-sig-Geo at stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no

My name is Jakob Petersen. I am about to prepare a thesis in GISc at Birkbeck,
University of London, and would like to get started with R. I will be working
with the index of multiple deprivation in the UK and some economic indicators
from various sources.
I would be grateful for any references to R litterature and webs. Thank you.

Dear  Professor Bivand,

My environment: VineLinux3.0, R-2.0.0_ja-1vl1, maptools ver. 0.4-8

which also means foreign_0.8-0, because maptools_0.4-8 depends on it.
Note that the problem was on Windows XP, I think with the standard
binary R from CRAN.

Yes, the problem was on WinXP but I wanted to suggest not all platform
had the problem.  And I knew Ono-san use Japanized one, too, it may
not be always though.

Availing myself of this question, let me ask a way to confirm if
read.dbf() has been surely replaced by maptools.  I have just done
"update.packages()" for obtaining the latest foreign and maptools.

The internal function dbf.read(), accessed as maptools:::dbf.read() in 
maptools up to 0.4-6, and as dbf.read() in maptools 0.4-7 is not present

at all in maptools 0.4-8. If you just type the names of the functions at

the prompt, the final line shows which namespace they live in:

library(maptools)

Loading required package: foreign 

read.dbf

function (file, as.is = FALSE) 
{
....
    df
}
<environment: namespace:foreign>

shows that read.dbf() from foreign is being used.

All right.  I realized my misunderstanding. The old functions such as
dbf.read() and dbf.write() have gone to the foreign 0.8-0 packages
with changing the name as read.dbf() and write.dbf(), haven't they?

Thanks.

--
Susumu Tanimura
Dept. of Socio-environmental Medicine
Inst. of Tropical Medicine, Nagasaki University

Hi there,

Examination of the problem with both Shift-JIS encoded and EUC-JP
encoded DBF in R-2.0 on win98 reminded me that no Japanese characters
can display in the original R for windows from CRAN. 

On R localized to Japanese, downloadable from
http://r.nakama.ne.jp/R-2.0.0/binary/win32/, I succeeded to display
Japanese characters with read.dbf() from foreign 0.8-0 on R-2.0, win98
when Shift-JIS encoded DBF is tested.  Since we cannot basically deal with EUC-JP
in windows system, trial with EUC-JP encoded DBF failed.

Because I do not have WinXP, I could not examine on WinXP.  If WinXP works
only with unicode and dose not work with Shit-JIS, conventional
encoding for windows, this could be essential issue.

I hope this helpful. 


--
Susumu Tanimura
Dept. of Socio-environmental Medicine
Inst. of Tropical Medicine, Nagasaki University