It is my pleasure to announce the release of version 0.7.0 of the RQDAassist package. A lot of work has gone into making it even easier for would-be users of RQDA to download and install that package along with its dependencies. In this update, I have focused on making R and Rtools more accessible to users, and as such, if one wants to properly install any of the two, the heavy lifting will be done for you.
Installation of R and Rtools
One of the current problems with installing RQDA is the introduction of UCRT in R 4.2. RQDA dependencies like RGtk2 and cairoDevice cannot be installed as the available binaries were not built with UCRT. They also cannot be built locally with the current version of their source files. So, for now, the use of RQDA will be restricted to R versions lower than 4.2.
RQDAassist was made to work on versions between 4.0 and 4.1, the latest of which is R 4.1.3. Prior to this update, if you were using R 4.2 you would have to separately download the compatible installer from CRAN (using this link), which would then have to be run to install R. Similarly if the user didn’t have Rtools40, that too had to be downloaded by the user from here and installed.
These operations can now be carried out almost automatically using the install function. It will detect if a compatible version of R or Rtools is not on the system, and if necessary, download these for the user to install. The user only needs to accept the Windows Smart Screen prompt to allow the software to be installed. If a previously downloaded copy of any of these is in the default download location, the download step is skipped and that local copy is installed.
Related developments
I’ve been following developments on the RGtk2 repository to see whether there will be a return of RGtk2 to CRAN; this would effectively solve the problem of version compatibility, and even render this package obsolete. There’s been some recent activity there, so I am hopeful that the project will progress beyond this hurdle.
Conclusion
RQDAassist now allows you to set up the R environment as well as Rtools which makes it easier to install RQDA. Visit the GitHub repository and post any issues that may be encountered and the package will be made to serve the community even better.
A new version of the naijR package was released last weekend on CRAN, comprising internal changes that modify certain behaviour. I will try to quickly outline them in this post, but because the update followed soon after the last minor revision, it might be useful to look at the last blog post on v0.5.0.
User-visible Changes
Interactivity on Windows
As stated in previous articles, the function `fix_region()` provides 2 ways (automatic and interactive) to repair misspelt Local Government Areas (LGAs), a problem that is quite common when working with raw data containing this subnational division. Previously, any interactive work was done solely in the R console. Beginning with this version, Windows users have the benefit of using the native windowing system by way of dialogs, text controls, and message boxes, which should be more intuitive. On other platforms, the interaction still defaults to the Console. For details on how this works, read the vignette on the package website or locally via the package documentation.
Handling of the Federal Capital Territory
There are peculiarities with data that involve the Federal Capital Territory (FCT). First, it is not a State but is usually lumped along with States in most data sets. Also, it is either used as a whole or as an acronym. Recently, a researcher requested my support in plotting data on a map—one of the issues I realized he was facing was that the word “Abuja” (the capital city) was used to represent FCT, and as a State. Going forward, whenever the term Abuja is used as a State, a warning will be issued to the user.
Suppression of A Superfluous Warning
When the function `lgas` is given a string that is not a valid (i.e. correctly spelled) LGA, a warning is signaled. In a nested call to `fix_region()`, this warning becomes unnecessary and, quite frankly, irritating. So, the function was updated to recognize and suppress the warning whenever these 2 functions are used together. To be clear, in the old version this code signals a warning
lg <- c("Bwari", "Buari", "Kwali", "Kuali")
fix_region(lgas(lg))
## Successful fix(es):
## -------------------
## * Buari => Bwari
## * Kuali => Kwali
## Warning message:
## One or more items is not an LGA. Spelling error?
The warning doesn’t make sense here, since the spelling mistake has been fixed; but it came from the call to lgas(), not fix_region(). In the update, the fix is reported on but without the warning.
Modifying Map Labels
An oversight was spotted, in that the size of region labels in the map could not be changed—a bug that was introduced during an earlier stage of development. This has now been fixed. The default character expansion factor (`cex`) is 0.75, adopted from the `maps` upon which this version of naijR depends. To adjust this, we can now simply use the undocumented `cex` argument which is used by `map_ng()` via its `…` parameter.
map_ng(show.text = TRUE)
We now reduce the text size:
map_ng(show.text = T, cex = .5)
Conclusion
To get more information on how to use the package, visit the GitHub page or the website. Feedback and/or contributions of code are also welcome.
A new version of this R package has been released on CRAN, the Comprehensive R Archive Network. It introduces a number of updates that will be described in somewhat detail in this blog post. For a synopsis, read the release notes.
New methods
Methods for some common generic R functions were included in the update. Some of these include c(), [, [[, na.exclude, to mention a few. This confers consistent behaviour to some of the **naijR** objects. For example, when concatenating 2 objects that represent the Nigerian States, we have the following:
Similarly, when indexing, the output formatting is retained:
s3[1]
## States
## ------
## * Imo
Other methods added are as follows:
head.regions
tail.regions
print.regions
na.exclude.regions
na.omit.regions
Mobile numbers
The function fix_mobile can now repair phone numbers where zeros (0) are mistakenly replaced with the letter O (whether upper or lower case). As an example:
nums <- c("8034510441", "070304", "09O14358956")
# nums[3] has a letter 'O' in it and is fixed by the function
fix_mobile(nums)
[1] "08034510441" NA "09014358956"
Map legends
Changes were made to the arguments that control how legends are displayed in the maps, particularly choropleths. The way the argument legend.text works is similar to that of the barplot function (from the **graphics** package). Only when this argument is TRUE will the legend be plotted. Also, other arguments that were used for fine-tuning were deprecated – leg.x, leg.y, and leg.orient. Going forward, any low-level legend manipulations should be done with graphics::legend().
As an example, let us create a 2-column data frame with hypothetical data on the
# Create a factor
set.seed(12)
x <- states() |>
length() |>
rnorm(100, 10) |>
round() |>
sample() |>
cut(
breaks = c(80, 89, 99, 109, 119, 129),
labels = c("80-89", "90-99", "100-109", "110-119", "120+"),
include.lowest = TRUE
)
# Make a 2-column data frame and take a look at it
df <- data.frame(state = states(), x)
head(df)
Now, we will use this data frame to create a choropleth map. One of the improvements in this version is that the function map_ng(), when given a two-column data frame will inspect each column, and if one column has valid States or LGAs and the other is a factor, it will automatically create the choropleth visualization. So using our data frame df,
map_ng(data = df)
With the new control given in the current version, we can do away with the legend.
Due to the shape of the map, the best place to place any legend is in the bottom right corner. However, if the user wants to place it elsewhere, we can now use the Base R plotting constructs to do fine-grained touch-ups. This, of course, is for users who are more comfortable coding in R. As an example,
# Create objects containing the factor levels and then the colours
# map_ng() uses RColorBrewer internally, so we are using this
# to manually define the colours for the legend itself
categories <- levels(df$x)
colors <- RColorBrewer::brewer.pal(length(categories), "Greys")
# The legend's data, colours, orientation, justification, size and spacing are defined
res <- map_ng(data = df, legend = FALSE)
legend("top", categories, fill = colors, horiz = TRUE, xjust = .8, cex = .55, x.intersp = .5)
So much more can be done with this; details can be found in the documentation via ?legend.
Installation
The new version of the package can be installed from CRAN with the following code:
This is to introduce a new iteration of the RQDAassist package (version 0.5.0). This version comes with the possibility of installing RGtk2 and cairoDevice via their archived binaries, instead of solely installing source tarballs. The advantage is the installation is much quicker and the interactions with the GTK distribution are much more easily handled. The downside of the binary installation is that it can only be done reliably during an interactive R session.
The binary installation option is the default. Thus, to install RQDA, we run
RQDAassist::install()
To install via source, we change the arguments:
RQDAassist::install(type = "source")
When doing the binary installation, if RGtk2 is newly installed and GTK does not exist on the machine, the function stops at some point and the user is invited to install GTK. This is done by first attaching the package
library(RGtk2)
The user is then prompted with a dialog, for the installation of Gtk+.
Dialog for GTK+ installation
After GTK+ is installed, one may see an error message in the console–ignore this. Once done, run RQDAassist::install() again, and the remaining packages will be installed.
For more information about this version, please visit the package’s GitHub page. Let me know your thoughts in the comments.
The other day I got an email from a researcher who is using the naijR package, which, among other things, helps with the drawing of plot maps of Nigeria. He was having trouble drawing maps of the geopolitical zones (GPZ) of the country.
Admittedly, this is an omission from the package, but a deliberate one. I had actually toyed with the idea of baking this feature in, but since the GPZ is not “officially” recognized, I opted for the package to be relatively silent, as only States and Local Government Areas are recognized in the Nigerian Constitution.
Anyway, after a few emails back and forth, I was able to help him resolve the issue. Basically, since the states() function can extract the States by GPZ (via the gpz argument), we can use this little dearie to extract the States of a GPZ and pass it to the region argument of map_ng(). For the Northeast GPZ, this gives us a map that might look like this:
Delineating all the GPZ on a country map is a little trickier and we have to do some functional programming. One approach is to generate a data frame with the contiguous States matched to a factor that represents each GPZ. Then, we draw a choropleth map by passing that data frame to the data argument of map_ng(), while the factor is passed to the x argument. Information for using these arguments can be found in ?map_ng(). In the output below, I chose reddish colouring for the map.
Problem solved. The code for this solution can be found in this GitHub Gist. To get the raw script, follow this link. I think I’m going to have to review the decision on not implementing a native drawing of GPZ maps in naijR.
The Opportunist 