Skip to content
Prev 250 / 29559 Next

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

On Mon, 1 Nov 2004, Susumu Tanimura wrote:

            
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?
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.
This is possible, but all input is helpful here, also because R will 
migrate towards multi-character support at some stage.
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:
Loading required package: foreign
function (file, as.is = FALSE) 
{
....
    df
}
<environment: namespace:foreign>

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

Roger Bivand