Susumu Tanimura wrote on 02-nov-04:

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?


Yes, quite right. If users find that spdep and/or maptools fail to load after updating, the reason it likely to be the dependence of maptools on the newest foreign package. We have tried to complete these changes before the release of R 2.0.1 in a short time - the new R release will of course include the new foreign package.

Roger


Thanks.

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

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


	[[alternative HTML version deleted]]


