search

ggobi / cranvas

Interactive graphics in R using Qt interfaces, a descendant of ggobi software
https://ggobi.github.io/cranvas.org/
80 stars 12 forks source link

an algoritm to construct continuous area cartograms #210

Open yihui opened 10 years ago

yihui commented 10 years ago

this does not seem to be entirely difficult to implement in R (people did that in 1980's): http://lambert.nico.free.fr/tp/biblio/Dougeniketal1985.pdf

may be worth hacking a bit on it so that we can remove the dependency on Duncan TL's Rcartogram package, which seems not trivial to install on Windows (needs fftw headers) and it has not been updated for two years...

heike commented 10 years ago

Yihui,

there's another package in R that does cartograms quite nicely without the fft dependency … I used cart before you switched to Rcartogram and yes, the algorithms have been around for a while ….

On Oct 10, 2013, at 5:09 PM, Yihui Xie notifications@github.com wrote:

this does not seem to be entirely difficult to implement in R (people did that in 1980's): http://lambert.nico.free.fr/tp/biblio/Dougeniketal1985.pdf

may be worth hacking a bit on it so that we can remove the dependency on Duncan TL's Rcartogram package, which seems not trivial to install on Windows (needs fftw headers) and it has not been updated for two years...

— Reply to this email directly or view it on GitHub.

yihui commented 10 years ago

Yes, I remember that. Actually both cart and Rcartogram were using the same algorithm (by Mark Newmans), which depends on FFTW. For instance, you can see #include <fftw3.h> here: https://r-forge.r-project.org/scm/viewvc.php/pkg/src/cart.c?view=markup&root=cart

There are pros and cons about both packages. cart depends on SpatialPolygonsDataFrame, and that will introduce the dependency on the sp package; I think it may be possible to strip off this dependency and make sp optional. On the other hand, the dependency on sp can make things easier, and that is exactly why Rcartogram is bad (it took me a really long time to understand what was going on because Rcartogram does not use polygons at all; the input data for Rcartogram is very weird).

Neither cart nor Rcartogram is well maintained; both are two years old now, although they may still be working. We need to work out a lightweight R package, and submit it to CRAN.

I believe the paper I mentioned above is a low-hanging fruit for Xiaoyue (our cartogram expert who studies cartograms hard last year). The algorithm is based on polygon coordinates instead of the weird input format in Newmans' paper (point grid with weights). It will benefit the R community when neither cart nor Rcartogram was able to make the way to CRAN.