[REVIEW]: rmap: An R package to plot and compare tabular data on customizable maps across scenarios and time

[whedon]

Submitting author: @zarrarkhan (Zarrar Khan)
Repository: https://github.com/JGCRI/rmap
Branch with paper.md (empty if default branch):
Version: v1.0.5
Editor: @hugoledoux
Reviewers: @CamilleMorlighem, @maczokni
Archive: 10.5281/zenodo.7085969

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/4cdf462f70681bc335ddebf5868b249c"><img src="https://joss.theoj.org/papers/4cdf462f70681bc335ddebf5868b249c/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/4cdf462f70681bc335ddebf5868b249c/status.svg)](https://joss.theoj.org/papers/4cdf462f70681bc335ddebf5868b249c)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@CamilleMorlighem & @maczokni, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @hugoledoux know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Review checklist for @CamilleMorlighem

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@zarrarkhan) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @maczokni

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review. #4016

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@zarrarkhan) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[whedon]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @CamilleMorlighem, @maczokni it looks like you're currently assigned to review this paper 🎉.

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

⭐ Important ⭐

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

2. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

For a list of things I can do to help you, just type:

@whedon commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf

[whedon]

Wordcount for paper.md is 1074

[whedon]

Software report (experimental):

github.com/AlDanial/cloc v 1.88  T=0.13 s (246.4 files/s, 106346.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
R                               19           1404           2413           7675
Rmd                              1            367            512            781
Markdown                         6             62              0            200
TeX                              1             18              0            189
YAML                             5             33              0            159
-------------------------------------------------------------------------------
SUM:                            32           1884           2925           9004
-------------------------------------------------------------------------------


Statistical information for the repository '8ee264c2b9dd4723350c4830' was
gathered on 2021/12/20.
The following historical commit information, by author, was found:

Author                     Commits    Insertions      Deletions    % of changes
Khan                             2           442            442          100.00

Below are the number of rows from each author that have survived and are still
intact in the current revision:

Author                     Rows      Stability          Age       % in comments

[whedon]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[whedon]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1007/s10113-021-01775-1 is OK
- 10.1088/1748-9326/ac046c is OK
- 10.21105/joss.00054 is OK
- 10.32614/RJ-2011-006 is OK
- 10.1007/b106573 is OK
- 10.5194/gmd-12-677-2019 is OK
- 10.5334/jors.292 is OK

MISSING DOIs

- 10.18637/jss.v084.i06 may be a valid DOI for title: tmap: Thematic Maps in R
- 10.32614/rj-2018-009 may be a valid DOI for title: Simple features for R: standardized support for spatial vector data.

INVALID DOIs

- 0.1029/2020EF001970 is INVALID

[CamilleMorlighem]

Hello ! I started the review. I have a few comments already:

1. About the software paper, I think everything is there. I just noticed a spelling mistake line 17 in the summary (in the article proof) "rmap is desgined" and there are also the few missing/invalid DOIs already noticed by whedon in a previous comment.
2. I can see in the user guide that the type of license is BSD_2_clause but it does not appear in the license file on the repository, maybe it should be specified there as well ?
3. About the community guidelines, it is very clear in the user guide how third parties can contribute to the software and report issues or problems but I could not find information about seeking support.

[zarrarkhan]

Hi @CamilleMorlighem,

Thanks for the very useful feedback and comments. Here are the responses to your points:

1. We fixed the typo on line 17 and also fixed the Missing and incorrect DOIs. The updated document can be found here: http://res.cloudinary.com/hkvhhndao/image/upload/v1640793026/zeldl1tq79mt9xnk82us.pdf or in the repo: https://github.com/JGCRI/rmap/tree/main/paper
2. We updated the BSD_2_clause license file. Now when you click on the repo LICENSE file (https://github.com/JGCRI/rmap/blob/main/LICENSE) it should show the proper BSD_2_clause license.
3. We added a support tab in the user guide and setup a discussions page for rmap in the main repo. If users do not want to submit an issue then they can start a discussion instead on the discussions page. We the developers can respond there as well as have community members respond there as well.

[CamilleMorlighem]

Hi @zarrarkhan,

Thank you for your responses !

I have tested the documentation and functionality of the package. The documentation is very clear and structured and very user friendly! I just have the following comments for improvement:

1. The information link (https://confluence.pnnl.gov/confluence/display/JGCRI/GCAM+Shape+Files) in the help section of the maps mapGCAMBasins and mapGCAMReg32 is not working for me (I reach an error page).
2. I could not find a statement of need in the user guide or in the documentation on the repository.
3. I couldn't find either a list of dependencies, but when installing it proposed me to install/update required packages so maybe that's enough?
4. I found some typos in the user guide:

• In the section "Subset existing shape", I think you meant unique(shapeSubset@data$subRegion) and not unique(shapeSubset@data$states)
• In section "Read data from a shapefile", I think you meant rgdal::readOGR(dsn=exampleFolder,layer=exampleFile,use_iconv=T,encoding='UTF-8') instead of rgdal::readOGR(dsn=examplePolyFolder,layer=examplePolyFile,use_iconv=T,encoding='UTF-8').
• In subsection "Gridded Data Multi-Year Diff", both code snippets return NULL:
  mapx$map_param_xDiffAbs_2015_1990_KMEANS
mapx$map_param_xDiffPrcnt_2015_1990_KMEANS
• Same with the following code snippets in section "Gridded Data Multi-Scenario Diff":
  mapx$map_param_DiffAbs_scenario3_scenario1_KMEANS
mapx$map_param_DiffPrcnt_scenario3_scenario1_KMEANS

About the functionality, everything worked fine and I don't have any performance claims. I only have the following comments:

1. I did not get the effect of the argument scaleRangeDiffAbs (or scaleRangeDiffPrcnt) in the map function . I could not see what changed in the results when changing the values for these arguments or when simply removing them.
2. I thought that one very useful function, that is not described in the documentation, is the map_find_df function to find a suitable map for your dataframe. I think it might be very useful when you don't know the package and want to use it for a specific purpose, so maybe it is worth highlighting this function in the user-guide?

Feel free to ignore any comment if you think that's not relevant!

[whedon]

👋 @maczokni, please update us on how your review is going (this is an automated reminder).

[whedon]

👋 @CamilleMorlighem, please update us on how your review is going (this is an automated reminder).

[zarrarkhan]

@CamilleMorlighem Thanks for the detailed review and very helpful comments. Addressed as follows:

Improvements

1. All data sources referring to the restricted (https://confluence.pnnl.gov/confluence/display/JGCRI/GCAM+Shape+Files) have been updated to point to the publicly available zenodo link: https://zenodo.org/record/4688451#.YdMNTmjMJPY
2. We added statement of need to the repo and user guide landing pages based on the text in the paper.

• https://github.com/JGCRI/rmap/#statement-of-need
• https://jgcri.github.io/rmap/#statement-of-need

3. Dependencies can be found in the https://github.com/JGCRI/rmap/blob/main/DESCRIPTION file and those mentioned in the imports list are required and will be automatically installed when users install the package so it shouldn't be something a user needs to worry about outside the package.
4. Typos in user guide fixed (Thanks for catching these!):

• In the section "Subset existing shape", unique(shapeSubset@data$states) siwtched to unique(shapeSubset@data$subRegion). (https://jgcri.github.io/rmap/articles/vignette_map.html#subset-existing-shape)
• In section "Read data from a shapefile", rgdal::readOGR(dsn=examplePolyFolder,layer=examplePolyFile,use_iconv=T,encoding='UTF-8') changed to rgdal::readOGR(dsn=exampleFolder,layer=exampleFile,use_iconv=T,encoding='UTF-8') (https://jgcri.github.io/rmap/articles/vignette_map.html#read-data-from-a-shapefile)
• In subsection "Gridded Data Multi-Year Diff", code snippets adjusted to return appropriate maps. The code snippet was out of date and has been updated. (https://jgcri.github.io/rmap/articles/vignette_map.html#gridded-data-multi-year-diff)
• Same with the following code snippets in section "Gridded Data Multi-Scenario Diff" code snippets adjusted to return appropriate maps. The code snippet was out of date and has been updated. (https://jgcri.github.io/rmap/articles/vignette_map.html#gridded-data-multi-year-diff)

Functionality

1. Thanks for noting this. The code needed to be updated to implement the changes. I think with the updated changes (now that it is actually working) you can see the usefulness of this feature (i.e. highlighting different ranges for each type of map as needed). See here: https://jgcri.github.io/rmap/articles/vignette_map.html#scale-range
2. Added section on map_find_df to user_guide here: https://jgcri.github.io/rmap/articles/vignette_map.html#map-find

[maczokni]

Hello! I've hit a bit of a stumbling block when trying to follow along with some data that isn't the one in the examples (I understand the idea to be that users can upload their own .csv files and this package will allow them to easily map this?)

First note: if the column is not called "subRegion" then the error Error in rmap::map_find_df(mydata) : data must have subRegion columns is immediately thrown. Instead of requiring users to rename their column, could this not be a parameter to specify in the function itself? E.g.: map_find_df(data = mydata, regions = subRegion). I don't think it's in line with the contribution to make things easy to ask people to rename their columns!

But where I'm stuck: once I try to map my data, it will not do this. I have renamed to values, and have checked and it is numeric. Here's my code

library(dplyr)
library(geodaData)
library(rmap)
# get own data to try
ncovr <- geodaData::ncovr

mydata <- ncovr %>% select(NAME, HR60)

map_chosen <- rmap::map_find_df(mydata)
# Error in rmap::map_find_df(mydata) : data must have subRegion columns.

mydata <- ncovr %>% select(NAME, HR60) %>% rename(subRegion = NAME)
map_chosen <- rmap::map_find_df(mydata)
rmap::map(map_chosen)
# Here the value column is not used, and no error is thrown, I just get a meaningless map

mydata <- ncovr %>% select(NAME, HR60) %>% rename(subRegion = NAME, value = HR60)
map_chosen <- rmap::map_find_df(mydata)
rmap::map(map_chosen)
#  OK it might not be an issue with naming, it just doesn't work...

rmap::map(map_chosen, fillColumn = value)
# Error in rmap::map_plot(color = color, lwd = lwd, legendType = legendType,  : 
#  object 'value' not found

# the example from the vignette works
data = data.frame(subRegion = c("CA","FL","ID","MO","TX","WY"),
                  value = c(5,10,15,34,2,7))
rmap::map(data)

# both the example and my own data's value columns contain numeric variables
class(mydata$value)
class(data$value)

# From the lack of error messages and the lack of further detail in the vignette, I cannot get it to work. 

Any thoughts?

[zarrarkhan]

Hi @maczokni.

Thanks for your review and comments. Please see our responses below:

# Update rmap with latest changes
devtools::install_github("JGCRI/rmap")
library(rmap)

1. Required Column names (subRegion and Value): We have highlighted how users can identify their own column names in rmap using the subRegCol and valueCol arguments. (see end of this section: https://jgcri.github.io/rmap/articles/vignette_map.html#inputs)
2. Example data: Thanks for trying rmap with your example data. So we updated a few things and have some comments on this:

• ncovr <- geodaData::ncov gives an sf object with geometries. rmaps was intially unable to process this because it was not a pure R dataframe. Code has been updated to convert an sf object to a pure dataframe.
• mydata <- ncovr %>% select(NAME, HR60) results in a dataframe with a list of counties and corresponding data. If you sort by NAME you will see multiple entries for the same subRegion. rmap (or any other mapping package for that matter) would not know how to deal with this repeated data.

  dplyr::select(NAME,HR60) %>%
  as.data.frame() %>%
  dplyr::arrange(NAME) %>%
  head(10)

3. With the updates you can run your example as follows: Note that in general, county data is problematic because there are multiple counties with the same name in different states. In order to be more specific you can append your county names with an underscore and relevant State initials.

library(dplyr)
library(geodaData)
library(devtools)
library(rmap)

ncovr <- geodaData::ncovr

# Subset first 10 rows to avoid repeated subRegions
mydata <- ncovr %>%
  dplyr::select(NAME,HR60) %>%
  head(10); mydata

# Will give you the relevant plot but multiple counties
rmap::map(mydata,
          subRegCol = "NAME", # Set your subRegion column
          valueCol = "HR60") # Set your value column

# In the following extended example you can see all the multiple counties labelled.
# rmap appends the State Initials for you as it recognizes the counties. Although all the counties are given the same value (which is probably not the intention here).
# You can also see some of the other features of rmap at play here
# such as underLayer, zoom, labels etc.
rmap::map(mydata,
          subRegCol="NAME",
          valueCol="HR60",
          labels = T,
          labelSize = 3,
          labelRepel = T,
          underLayer = rmap::mapUS49,
          zoom=-2)

Please let us know if this helps clarify some of the issues you were having and if you have additional concerns/comments.

[maczokni]

Hi @zarrarkhan thanks for the update - sorry just getting back to this now but I have a major concern - you are right there are duplicates, as there are USA counties which share the same name. This means that the county names is not actually an appropriate column on which to join. This means that if I do want to join the full dataset (rather than the 10 subset you used) then I cannot do this with the package - is that right? And this is not just a quirk of the dataset I'm using to test, your own data (the inbuilt map: mapUS49County has duplicate values of the subRegion column):

# devtools::install_github("JGCRI/rmap")
library(rmap)
library(geodaData)
library(dplyr)
library(sf)

# get data for testing
data("ncovr")
# check any duplicate names in the county inbuilt map
thing <- rmap::mapUS49County
length(thing@data$subRegion)
length(unique(thing@data$subRegion))
as.data.frame(table(thing@data$subRegion)) %>% filter(Freq > 1)

Considering this is a primary function of the package, do you think you could take some more time to think about this problem? As I'm sure you are familiar, usually for each geography you will look for unique codes in the dataframes on which you can confidently join. Here in the UK we might use for example local authority codes or output area codes. In the US it seems to be state and county codes for example in this case, which is in the ncovr dataset as 'FIPS'.

I had a play with the data of the mapUS49County inbuilt map as an example, and by pasting the state and county code you can create a FIPS column to join.

# combine state code and county code for FIPS
thing <- rmap::mapUS49County
thing@data$FIPS <- paste0(thing@data$STATEFP, thing@data$COUNTYCODE)
joined <- left_join(ncovr, thing@data, by = c("FIPS" = "FIPS"))

# check how many would not be joined
nrow(joined %>% filter(is.na(source)))

# check these ones
not_joined <- joined %>% filter(is.na(source))

When we do that only 3 counties are not joined - i.e. only 3 would not be linked to the inbuilt map. You might want to consider printing a warning to users when this is the case, maybe with the name of the ones which did not join.

However this is only one case for one data set - I think it might be useful to think about some use cases of external data, how do these codes commonly look like, and have a few join columns on which users' data can be joined to the inbuilt geometries.

Hope this makes sense, let me know if not I can try to elaborate more!

[zarrarkhan]

@maczokni
Thanks for your comments and notes. We have addressed your comments as follows:

• US County duplicates:
  rmap::mapUS49County@data (which is from the official census.gov webpage: https://www.census.gov/geographies/mapping-files/time-series/geo/carto-boundary-file.html) had all unique rows, even though as you found, six subRegions had duplicate names in spite of being unique entries (which we had missed). Initially, since there were so many counties with the same name in different states we had attempted to address this by appending State and County names together in the subRegion column as shown below. As you can see each subRegion has a unique STATEFP & COUNTYCODE combination even though the subRegion names may have been duplicated in these 6 particular cases (Additionally COUNTYCODEs are also repeated in different states):

        subRegion       subRegionAlt STATEFP COUNTYCODE
1       Baltimore_MD    Baltimore    24        005
2       Baltimore_MD    Baltimore    24        510
3       Fairfax_VA      Fairfax      51        059
4       Fairfax_VA      Fairfax      51        600
5       Franklin_VA     Franklin     51        067
6       Franklin_VA     Franklin     51        620
7       Richmond_VA     Richmond     51        159
8       Richmond_VA     Richmond     51        760
9       Roanoke_VA      Roanoke      51        161
10      Roanoke_VA      Roanoke      51        770
11      St. Louis_MO    St. Louis    29        189
12      St. Louis_MO    St. Louis    29        510

• Duplicate subRegions in rmap::mapUS49County
  There were six subRegions in rmap::mapUS49County which had duplicated subRegion names as shown above. These occurred because each of these subRegions are classified as both cities as well as counties and are allocated their own COUNTYCODES in spite of being cities. For each of these cities we also have a county with the same name in the same state. For each city we have appended their names with _city so that we have completely unique subRegions as well as added FIPS as per your suggestion. Updated table outputs (selected columns) now show:

           subRegion subRegionAlt STATEFP COUNTYCODE  FIPS
1       Baltimore_MD    Baltimore      24        005 24005
2  Baltimore_MD_city    Baltimore      24        510 24510
3         Fairfax_VA      Fairfax      51        059 51059
4    Fairfax_VA_city      Fairfax      51        600 51600
5        Franklin_VA     Franklin      51        067 51067
6   Franklin_VA_city     Franklin      51        620 51620
7        Richmond_VA     Richmond      51        159 51159
8   Richmond_VA_city     Richmond      51        760 51760
9         Roanoke_VA      Roanoke      51        161 51161
10   Roanoke_VA_city      Roanoke      51        770 51770
11      St. Louis_MO    St. Louis      29        189 29189
12 St. Louis_MO_city    St. Louis      29        510 29510

• 3 missing FIPS when joining with ncovr dataset
  The not_joined dataframe in your example above refers to 3 counties which are out of date in the ncovr dataset. These three subRegions from the not_joined datatable are shown below. References to when their names were changed are listed after the code chunk:

not_joined %>% dplyr::select(NAME,STATE_NAME,STATE_FIPS,CNTY_FIPS,FIPS)
           NAME   STATE_NAME STATE_FIPS CNTY_FIPS  FIPS
1       Shannon South Dakota         46       113 46113
2 Clifton Forge     Virginia         51       560 51560
3          Dade      Florida         12       025 12025

(Source: https://www.ddorn.net/data/FIPS_County_Code_Changes.pdf)

1. Shannon: South Dakota, 1983: Washabaugh county (FIPS 46131) merges into
   Jackson county (FIPS 46071).
2. Clifton Forge: Virginia, 2001: The independent city of Clifton Forge (FIPS 51560) merges
   into Alleghany county (FIPS 51005).
3. Dade: Florida, 1997: Dade county (FIPS 12025) is renamed as Miami-Dade
   county (FIPS 12086).

• Broader concern: Each of our datasets provides the source for the underlying data which can be compared to user data if needed. For example the county data is from "https://www.census.gov/geographies/mapping-files/time-series/geo/carto-boundary-file.html". The datasets also contain additional columns such as FIPS and other details that were part of the original datasets to ensure unique entries. Some degree of data cleaning and checks is expected with user data.

# Checking the source of rmap maps
rmap::mapUS49County@data$source%>%unique()
# "https://www.census.gov/geographies/mapping-files/time-series/geo/carto-boundary-file.html"
rmap::mapCountries@data$source%>%unique()
# "https://www.naturalearthdata.com/downloads/"

Please let us know if this addresses some of your concerns or if you have additional comments.

[hugoledoux]

@CamilleMorlighem I see that the authors fixed your issues (statement of needs among others, see there: #4015 (comment)) but you didn't tick the boxes above. Can you let us know if you are now satisfied please?

[CamilleMorlighem]

@hugoledoux thank you for noticing it !

@zarrarkhan thank you for these improvements and answers to my comments. I think I'm done with the review. Rmap is a very nice package! I'm probably gonna use it in the future.

[zarrarkhan]

@hugoledoux Thanks for following up. Wondering if there are any additional comments we can address or get an update from the reviewers on the comments we addressed in #4015 (comment).

[hugoledoux]

@maczokni could you check the updates from the authors (#4015 (comment))? And tell us if you're satisfied?

[zarrarkhan]

@danielskatz
oops. Sorry about that. I've changed this in paper.bib which is merged into master now. I won't create a new version. Is that okay?

[danielskatz]

should be - let's see :)

[danielskatz]

@editorialbot recommend-accept

[editorialbot]

Attempting dry run of processing paper acceptance...

[editorialbot]

👋 @openjournals/joss-eics, this paper is ready to be accepted and published.

Check final proof 👉📄 Download article

If the paper PDF and the deposit XML files look good in openjournals/joss-papers#3534, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1007/s10113-021-01775-1 is OK
- 10.1088/1748-9326/ac046c is OK
- 10.18637/jss.v084.i06 is OK
- 10.21105/joss.00054 is OK
- 10.32614/RJ-2011-006 is OK
- 10.1007/b106573 is OK
- 10.1002/wics.147 is OK
- 10.1029/2020EF001970 is OK
- 10.5194/gmd-12-677-2019 is OK
- 10.5334/jors.292 is OK

MISSING DOIs

- 10.32614/rj-2018-009 may be a valid DOI for title: Simple features for R: standardized support for spatial vector data.

INVALID DOIs

- None

[danielskatz]

sorry @zarrarkhan - there is one more change needed - for the first Pebesma reference, please add doi = {10.32614/RJ-2018-009}, rather than the URL that is there now.

[zarrarkhan]

no worries! Done and merged into main.
Happy to make any other changes as needed.

[danielskatz]

@editorialbot recommend-accept

[editorialbot]

Attempting dry run of processing paper acceptance...

[editorialbot]

👋 @openjournals/joss-eics, this paper is ready to be accepted and published.

Check final proof 👉📄 Download article

If the paper PDF and the deposit XML files look good in openjournals/joss-papers#3535, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1007/s10113-021-01775-1 is OK
- 10.1088/1748-9326/ac046c is OK
- 10.18637/jss.v084.i06 is OK
- 10.21105/joss.00054 is OK
- 10.32614/RJ-2011-006 is OK
- 10.1007/b106573 is OK
- 10.32614/RJ-2018-009 is OK
- 10.1002/wics.147 is OK
- 10.1029/2020EF001970 is OK
- 10.5194/gmd-12-677-2019 is OK
- 10.5334/jors.292 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[danielskatz]

@editorialbot accept

[editorialbot]

Doing it live! Attempting automated processing of paper acceptance...

[editorialbot]

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

[editorialbot]

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.04015 joss-papers#3536
1. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.04015
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

[danielskatz]

Congratulations to @zarrarkhan (Zarrar Khan) ad co-authors!!

And thanks to @CamilleMorlighem and @maczokni for reviewing, and to @hugoledoux for editing!
We couldn't do this without you.

[editorialbot]

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.04015/status.svg)](https://doi.org/10.21105/joss.04015)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.04015">
  <img src="https://joss.theoj.org/papers/10.21105/joss.04015/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.04015/status.svg
   :target: https://doi.org/10.21105/joss.04015

This is how it will look in your documentation:

We need your help!

The Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: https://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss

[zarrarkhan]

@danielskatz @hugoledoux @maczokni @CamilleMorlighem
Thanks to all of you for the great review and very helpful feedback. We appreciate it very much!
Best
Zarrar