Joss-reviews: [REVIEW]: Vizumap: an R package for visualising uncertainty in spatial data

[whedon]

Submitting author: @lydialucchesi (Lydia Lucchesi)
Repository: https://github.com/lydialucchesi/Vizumap
Version: v1.2.0
Editor: @bstabler
Reviewers: @nuest, @GISerDaiShaoqing
Archive: Pending

:warning: JOSS reduced service mode :warning:

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/3caaea5389aa90e287f459bf621c8645"><img src="https://joss.theoj.org/papers/3caaea5389aa90e287f459bf621c8645/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/3caaea5389aa90e287f459bf621c8645/status.svg)](https://joss.theoj.org/papers/3caaea5389aa90e287f459bf621c8645)

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

@nuest & @GISerDaiShaoqing, 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 @bstabler know.

✨ Please try and complete your review in the next six weeks ✨

Review checklist for @nuest

Conflict of interest

• [x] 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

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

General checks

• [x] 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 (@lydialucchesi) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [ ] Functionality: Have the functional claims of the software been confirmed?
• [x] 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?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] 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

• [x] 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: Do the authors clearly state 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?
• [x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• [x] 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 @GISerDaiShaoqing

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 (@lydialucchesi) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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: Do the authors clearly state 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. @bstabler it looks like you're currently assigned to review this paper :tada:.

:warning: JOSS reduced service mode :warning:

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.

:star: Important :star:

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:

1. 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]

Reference check summary:

OK DOIs

- 10.1002/sta4.150 is OK
- 10.1071/MF17237 is OK
- 10.1214/16-AOAS950 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[bstabler]

Hi @lydialucchesi, thanks for the submittal. This is my first review so please be patient as I learn the system. I prematurely created this issue since I'm not suppose to assign myself as both an editor and reviewer. I'm working on getting us another editor and/or reviewer. Thanks.

[bstabler]

@whedon remove @bstabler as reviewer

[whedon]

OK, @bstabler is no longer a reviewer

[bstabler]

@whedon add @nuest as reviewer

[whedon]

OK, @nuest is now a reviewer

[bstabler]

@whedon add @mikejohnson51 as reviewer

[whedon]

OK, @mikejohnson51 is now a reviewer

[nuest]

Thanks for the chance to contribute to JOSS!

I'll likely give this a go middle of next week.

[lydialucchesi]

Hi Ben,

Thanks for the update and finding us several reviewers.

Cheers,
Lydia

On Tue, Jun 30, 2020 at 4:06 PM Ben Stabler [e-mail]
wrote:

Hi @lydialucchesi https://github.com/lydialucchesi, thanks for the
submittal. I goofed this up since I'm not supposed to assign myself both
editor and reviewer. I'm working on getting us another editor and/or
reviewer. Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/2409#issuecomment-651562383,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE26ML7EPRXNUHS5G6JARRTRZF6F5ANCNFSM4OLXXBFA
.

[lydialucchesi]

Hi Daniel,

Sounds great - thanks for letting me know.

Best,
Lydia

On Thu, Jul 2, 2020 at 6:52 PM Daniel Nüst [e-mail] wrote:

Thanks for the chance to contribute to JOSS!

I'll likely give this a go middle of next week.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/2409#issuecomment-652879144,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE26ML6ISPXD5NJAZBW2PETRZRDFVANCNFSM4OLXXBFA
.

[bstabler]

hi @nuest & @mikejohnson51, how's the review coming along? Thanks!

[mikejohnson51]

Hi @bstabler & @lydialucchesi,

I hope to have this done early next week if that is acceptable. Thanks!

[nuest]

Will work on it tomorrow - apologies for the delay.

[nuest]

First review notes

General

• Authorship
  
  
  
  • The first author @lydialucchesi has primarily contributed to the JOSS paper - at least judging from the commits. Major code contributions were made by @pkuhnert. The third author has not made any contribution to the software himself, but I assume there is a significant contribution in algorithm design and the idea behind the package. I assume the contributors discussed this, but IMO it would be best to capture this with a short comment by @pkuhnert and Christopher K. Wikle (does not seem to be on GitHub) ? @bstabler what's your take on this?
  
  
• License
  
  
  
  • The README says "The package Vizumap version 1.1.0 is licensed under GPL-3 (see LICENSE file)", yet the LICENSE file contains a "CSIRO Open Source Software License Agreement (GPLv3)", which does not contain the full text of said license, and also references another software (asremlREplot) - please clarify in the README, and suggest to include full license text.
  
  
  • This license is AFAICT not OSI-approved
  
  
  • I assume there is no way around a non-standard license for you because of funding?
  
  
  • The license statement reads strange because it includes the version. Are other versions released under different licenses? The version 1.1.0 also does not match the release version on GitHub (1.0.0) nor the version in the DESCRIPTION file (1.2.0) - please clarify/fix.
  
  

Documentation

• I personally prefer to suggest installation via remotes, because it is much quicker to install than devtools. Just an idea for the README.
• Both papers referenced in the README are not open access - maybe you can add links to postprints or otherwise deposited copies of the PDFs? I cannot read them.
• The README and papers mention four methods, the vignette mentions only three. Please adjust/clarify.
• The reference in the README uses two different Zenodo DOIs, please fix.
• The commands in the vignette work :+1: There was a slight problem with plotting though on my machine, see sessionInfo output below: The worl map boundaries of Mexico are plottet over Alaska:
• I get a warning then running the pixelate example in the vignette. _Is that expected?_

> pix <- pixelate(ca_geo, id = "region")
Warning message:
In spTransform(shapefile, CRS("+proj=longlat +datum=WGS84")) :
  NULL source CRS comment, falling back to PROJ string

• ca_data$region %in% pix$region in the vignette would have a shorter output if wrapped with all(..)
• Excellent job mentioning which commands might take a bit longer to run in the vignette!
• The vignette assumes readers execute commands from top to bottom, also with the naming of variables. I suggest to use longer variable names for better understandability and readability (not map and map2)
• In the examples, use \dontrun{ instead of commenting out lines of code, so that users can copy and paste the non-running examples.
• Community guidelines are missing AFAICS. The usethis package can be very helpful to add these.
• Automated tests are missing AFAICS. I know tests for visualisations are hard, but you could, and should, have tests for the data preparations functions.

Paper

• Statement of need: could you clarify the targeted users of your package? You mention decision makers as the readers of the created maps, but who creates them? (minor suggestion)
• State of the field: please clarify if on other packages (in R) exist.
• "finding methods that add additional elements" - you probably mean more something like "finding methods that can communicate additional elements in an understandable and meaningful way"? You can easily add more elements, but adding userful once seems to be what your methods do.
• "functions can be found inthe package download" - suggest to rephrase to "is available after package installation". It's pretty straightforward these days to get a GitHub pages website for an R package (pkgdown, tic can help), so if you don't plan to submit the package to CRAN, then having a little website would be great for users. _This is of course unrelated to the JOSS submission_.
• Can you add links to the code that produces the examples in the paper?
• You really have to zoom into the pixel map example to see the pixels. I strongly suggest to show a zoomed in area of the map only, to make the pixel immediately visible for the reader.

Code

• DESCRIPTION file
  
  
  
  • Double field Maintainer: Maintainer:
  
  
  • Description field is very short.
  
  
  • Authors@R does not match the JOSS paper authors - please clarify.
  
  
  • Since the authors are academic, I strongly suggest you add ORCIDs to the authors list! You could also use the contributor roles here to clarify the different contributions (e.g. of Wikle)
  
  
• pixelate
  
  
  
  • The function paramter and documentation use "shapefile", which is misleading, because it takes sf objects as inputs, which could come from any vector file/database format. Suggest to rephrase/rename. This actually applies to the vignette, too. "Map data" would make more sense than "shapefile", right?
  
  
  • You do some projection changing in the background - mention this in the functions docs. _What about users who want to use another projection in their visualisation?_
  
  
• I like that you have a lot of developer comments explaining why you do something in the code :+1:
• I could install the package from source. :+1:
• devtools::check() completes with one Note (good job!): you should add paper directory to .Rbuildignore

_I'd be happy to take another look at the source code, if the more general comments are resolved._ :smiley:

Potentially going beyond JOSS review

• Did you consider integrating with any color-scheme packages in R to help build "good" palettes?
• What does the "uv" in read.uv stand for? Maybe a longer function name makes it more memorable/understandable?
• sp is the "old way", the current way to work with vector data is the package sf. In the paper you write " and we will continue to improve the toolkit to enhance its utility" - it would be great if you could update your functions (or test them, automatic coercion might make a lot of things work already) to play nicely with sf objects.
• Is it possible to export an anmination as a GIF? Would be cool to have that in the README or vignette...

My session info

> sessionInfo()
R version 4.0.2 (2020-06-22)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=de_DE.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=de_DE.UTF-8    LC_MESSAGES=en_US.UTF-8    LC_PAPER=de_DE.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] Vizumap_1.2.0

loaded via a namespace (and not attached):
 [1] spbabel_0.5.1        httr_1.4.2           maps_3.3.0           pkgload_1.1.0        tidyr_1.1.0         
 [6] bit64_0.9-7          jsonlite_1.7.0       assertthat_0.2.1     sp_1.4-2             animation_2.6       
[11] blob_1.2.1           remotes_2.1.1        sessioninfo_1.1.1    pillar_1.4.6         RSQLite_2.2.0       
[16] backports_1.1.8      lattice_0.20-41      glue_1.4.1           digest_0.6.25        colorspace_1.4-1    
[21] plyr_1.8.6           clisymbols_1.2.0     pkgconfig_2.0.3      devtools_2.3.0       broom_0.7.0         
[26] purrr_0.3.4          scales_1.1.1         processx_3.4.3       jpeg_0.1-8.1         ggmap_3.0.0         
[31] tibble_3.0.3         farver_2.0.3         generics_0.0.2       cranlike_1.0.2       ggplot2_3.3.2       
[36] usethis_1.6.1        ellipsis_0.3.1       withr_2.2.0          cli_2.0.2            magrittr_1.5        
[41] crayon_1.3.4         memoise_1.1.0        maptools_1.0-1       ps_1.3.3             fs_1.4.2            
[46] fansi_0.4.1          crancache_0.0.0.9001 parsedate_1.2.0      foreign_0.8-79       pkgbuild_1.1.0      
[51] tools_4.0.2          prettyunits_1.1.1    RgoogleMaps_1.4.5.3  lifecycle_0.2.0      stringr_1.4.0       
[56] munsell_0.5.0        geoaxe_0.1.0         callr_3.4.3          compiler_4.0.2       rlang_0.4.7         
[61] debugme_1.1.0        grid_4.0.2           rstudioapi_0.11      rjson_0.2.20         rappdirs_0.3.1      
[66] prompt_1.0.0         labeling_0.3         bitops_1.0-6         testthat_2.3.2       gtable_0.3.0        
[71] dadjoke_0.1.2        DBI_1.1.0            curl_4.3             reshape2_1.4.4       rematch2_2.1.2      
[76] R6_2.4.1             gridExtra_2.3        rgdal_1.5-12         dplyr_1.0.0          rgeos_0.5-3         
[81] bit_1.1-15.2         rprojroot_1.3-2      desc_1.2.0           stringi_1.4.6        Rcpp_1.0.5          
[86] vctrs_0.3.2          png_0.1-7            tidyselect_1.1.0   

[lydialucchesi]

Hi Dr. Nüst (@nuest),

Thank you for reviewing the Vizumap paper and package. I will start
working on the revisions. Is there a date that I should have the
revisions completed by (@bstabler)?

Following is clarification regarding author contributions and licensing.

Chris and I collaborated on the development of three Vizumap
visualisation methods. Chris helped design the first three map types
and provided advice on method implementation (e.g., using the rotation
matrix to implement the glyph map). These maps are described in the
first paper referenced, which can be accessed here:
http://faculty.missouri.edu/~wiklec/LucchesiWikle2017Stat.
Accompanying that paper is a supplementary R vignette that includes
the code I wrote to produce the paper figures:
http://faculty.missouri.edu/~wiklec/sta4150-sup-0001-supplementary.

Petra and I then started a collaboration in 2017 where we translated
the methods and code from the Stat paper into an R package, and this
was housed in a CSIRO Bitbucket repository. Petra made contributions
towards speed up and design of the code to make it more user friendly
and efficient. Petra also contributed the 4th visualisation method in
the package (the exceedance probability map), which was outlined in
the second paper we reference. We are working on creating an
open-access link for this paper.

When we decided to port this code to GitHub and make it public, we had
trouble getting a CSIRO Bitbucket repository transferred to GitHub. We
therefore created a new GitHub repository that unfortunately does not
contain all of the history of commits. If it would be helpful, we can
make the original Bitbucket repository available to you as a separate
repository so you can see the version history and history of commits
to validate contributions.

The License file should not appear in that repository, and the
Description file should just include a reference to GPLv3 only. My
apologies for the error and causing confusion. I will push a change to
the repo to fix this.

Thank you for providing helpful feedback that will improve the paper
and the package.

Best regards,
Lydia

On Mon, Jul 27, 2020 at 2:13 AM Daniel Nüst [e-mail] wrote:
>

First review notes

General

Authorship

The first author @lydialucchesi has primarily contributed to the JOSS paper - at least judging from the commits. Major code contributions were made by @pkuhnert. The third author has not made any contribution to the software himself, but I assume there is a significant contribution in algorithm design and the idea behind the package. I assume the contributors discussed this, but IMO it would be best to capture this with a short comment by @pkuhnert and Christopher K. Wikle (does not seem to be on GitHub) ? @bstabler what's your take on this?

License

The README says "The package Vizumap version 1.1.0 is licensed under GPL-3 (see LICENSE file)", yet the LICENSE file contains a "CSIRO Open Source Software License Agreement (GPLv3)", which does not contain the full text of said license, and also references another software (asremlREplot) - please clarify in the README, and suggest to include full license text.
This license is AFAICT not OSI-approved
I assume there is no way around a non-standard license for you because of funding?
The license statement reads strange because it includes the version. Are other versions released under different licenses? The version 1.1.0 also does not match the release version on GitHub (1.0.0) nor the version in the DESCRIPTION file (1.2.0) - please clarify/fix.

Documentation

I personally prefer to suggest installation via remotes, because it is much quicker to install than devtools. Just an idea for the README.
Both papers referenced in the README are not open access - maybe you can add links to postprints or otherwise deposited copies of the PDFs? I cannot read them.
The README and papers mention four methods, the vignette mentions only three. Please adjust/clarify.
The reference in the README uses two different Zenodo DOIs, please fix.
The commands in the vignette work There was a slight problem with plotting though on my machine, see sessionInfo output below: The worl map boundaries of Mexico are plottet over Alaska:
I get a warning then running the pixelate example in the vignette. Is that expected?

pix <- pixelate(ca_geo, id = "region")

Warning message:

In spTransform(shapefile, CRS("+proj=longlat +datum=WGS84")) :

NULL source CRS comment, falling back to PROJ string

ca_data$region %in% pix$region in the vignette would have a shorter output if wrapped with all(..)
Excellent job mentioning which commands might take a bit longer to run in the vignette!
The vignette assumes readers execute commands from top to bottom, also with the naming of variables. I suggest to use longer variable names for better understandability and readability (not map and map2)
Community guidelines are missing AFAICS. The usethis package can be very helpful to add these.
Automated tests are missing AFAICS. I know tests for visualisations are hard, but you could, and should, have tests for the data preparations functions.

Paper

Statement of need: could you clarify the targeted users of your package? You mention decision makers as the readers of the created maps, but who creates them? (minor suggestion)
State of the field: please clarify if on other packages (in R) exist.
"finding methods that add additional elements" - you probably mean more something like "finding methods that can communicate additional elements in an understandable and meaningful way"? You can easily add more elements, but adding userful once seems to be what your methods do.
"functions can be found inthe package download" - suggest to rephrase to "is available after package installation". It's pretty straightforward these days to get a GitHub pages website for an R package (pkgdown, tic can help), so if you don't plan to submit the package to CRAN, then having a little website would be great for users. This is of course unrelated to the JOSS submission.
Can you add links to the code that produces the examples in the paper?
You really have to zoom into the pixel map example to see the pixels. I strongly suggest to show a zoomed in area of the map only, to make the pixel immediately visible for the reader.

Code

DESCRIPTION file

Double field Maintainer: Maintainer:
Description field is very short.
Authors@R does not match the JOSS paper authors - please clarify.
Since the authors are academic, I strongly suggest you add ORCIDs to the authors list! You could also use the contributor roles here to clarify the different contributions (e.g. of Wikle)

pixelate

The function paramter and documentation use "shapefile", which is misleading, because it takes sf objects as inputs, which could come from any vector file/database format. Suggest to rephrase/rename. This actually applies to the vignette, too. "Map data" would make more sense than "shapefile", right?
You do some projection changing in the background - mention this in the functions docs. What about users who want to use another projection in their visualisation?

I like that you have a lot of developer comments explaining why you do something in the code
I could install the package from source.
devtools::check() completes with one Note (good job!): you should add paper directory to .Rbuildignore

I'd be happy to take another look at the source code, if the more general comments are resolved.

Potentially going beyond JOSS review

Did you consider integrating with any color-scheme packages in R to help build "good" palettes?
What does the "uv" in read.uv stand for? Maybe a longer function name makes it more memorable/understandable?
sp is the "old way", the current way to work with vector data is the package sf. In the paper you write " and we will continue to improve the toolkit to enhance its utility" - it would be great if you could update your functions (or test them, automatic coercion might make a lot of things work already) to play nicely with sf objects.
Is it possible to export an anmination as a GIF? Would be cool to have that in the README or vignette...

My session info

sessionInfo()

R version 4.0.2 (2020-06-22)

Platform: x86_64-pc-linux-gnu (64-bit)

Running under: Ubuntu 20.04 LTS

Matrix products: default

BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3

LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3

locale:

[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=de_DE.UTF-8 LC_COLLATE=en_US.UTF-8

[5] LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=C

[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C

attached base packages:

[1] stats graphics grDevices utils datasets methods base

other attached packages:

[1] Vizumap_1.2.0

loaded via a namespace (and not attached):

[1] spbabel_0.5.1 httr_1.4.2 maps_3.3.0 pkgload_1.1.0 tidyr_1.1.0

[6] bit64_0.9-7 jsonlite_1.7.0 assertthat_0.2.1 sp_1.4-2 animation_2.6

[11] blob_1.2.1 remotes_2.1.1 sessioninfo_1.1.1 pillar_1.4.6 RSQLite_2.2.0

[16] backports_1.1.8 lattice_0.20-41 glue_1.4.1 digest_0.6.25 colorspace_1.4-1

[21] plyr_1.8.6 clisymbols_1.2.0 pkgconfig_2.0.3 devtools_2.3.0 broom_0.7.0

[26] purrr_0.3.4 scales_1.1.1 processx_3.4.3 jpeg_0.1-8.1 ggmap_3.0.0

[31] tibble_3.0.3 farver_2.0.3 generics_0.0.2 cranlike_1.0.2 ggplot2_3.3.2

[36] usethis_1.6.1 ellipsis_0.3.1 withr_2.2.0 cli_2.0.2 magrittr_1.5

[41] crayon_1.3.4 memoise_1.1.0 maptools_1.0-1 ps_1.3.3 fs_1.4.2

[46] fansi_0.4.1 crancache_0.0.0.9001 parsedate_1.2.0 foreign_0.8-79 pkgbuild_1.1.0

[51] tools_4.0.2 prettyunits_1.1.1 RgoogleMaps_1.4.5.3 lifecycle_0.2.0 stringr_1.4.0

[56] munsell_0.5.0 geoaxe_0.1.0 callr_3.4.3 compiler_4.0.2 rlang_0.4.7

[61] debugme_1.1.0 grid_4.0.2 rstudioapi_0.11 rjson_0.2.20 rappdirs_0.3.1

[66] prompt_1.0.0 labeling_0.3 bitops_1.0-6 testthat_2.3.2 gtable_0.3.0

[71] dadjoke_0.1.2 DBI_1.1.0 curl_4.3 reshape2_1.4.4 rematch2_2.1.2

[76] R6_2.4.1 gridExtra_2.3 rgdal_1.5-12 dplyr_1.0.0 rgeos_0.5-3

[81] bit_1.1-15.2 rprojroot_1.3-2 desc_1.2.0 stringi_1.4.6 Rcpp_1.0.5

[86] vctrs_0.3.2 png_0.1-7 tidyselect_1.1.0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[nuest]

Just Daniel, please - no "Dr." yet :man_shrugging:

Thanks for the clarification! All makes sense - for me a short comment about the project history, e.g. in the contributors documentation, or the README, would suffice to make this clear to future users/readers.

[bstabler]

@lydialucchesi - no hurry, the pace is up to you

[bstabler]

@nuest wrote "The first author @lydialucchesi has primarily contributed to the JOSS paper - at least judging from the commits. Major code contributions were made by @pkuhnert. The third author has not made any contribution to the software himself, but I assume there is a significant contribution in algorithm design and the idea behind the package. I assume the contributors discussed this, but IMO it would be best to capture this with a short comment by @pkuhnert and Christopher K. Wikle (does not seem to be on GitHub) ? @bstabler what's your take on this?"

I agree, it would be nice to document the contribution in some traceable way.

[lydialucchesi]

@nuest @bstabler great, I will make sure to add information about contributions as I complete the package revisions.

[bstabler]

@whedon remind @mikejohnson51 in 1 day

[whedon]

Reminder set for @mikejohnson51 in 1 day

[lydialucchesi]

Following is an open-access link to the second reference in the paper: https://publications.csiro.au/publications/#publication/PIcsiro:EP168206. Best, Lydia

[whedon]

:wave: @mikejohnson51, please update us on how your review is going.

[nuest]

Just FYI: I'll be on vacation next week, back Sep 15.

[lydialucchesi]

I am working on revisions and have a running list of what has been done so far saved in the paper folder in the Vizumap repo: https://github.com/lydialucchesi/Vizumap/blob/master/paper/revisionList.docx.

[bstabler]

I think @mikejohnson51 must be too busy or something so we need another reviewer. Let me unassign him and look for another reviewer.

[bstabler]

@whedon remove @mikejohnson51 as reviewer

[whedon]

OK, @mikejohnson51 is no longer a reviewer

[nuest]

@lydialucchesi Thanks for the update!

I strongly recommend not to put docx files under version control - it is effectively a ZIP archive that git cannot effectively track changes over time with. Why not use a plain text file, with Markdown formatting?

[lydialucchesi]

@nuest Good idea. I have made the switch, and the new file can be found here: https://github.com/lydialucchesi/Vizumap/blob/master/paper/revisions.md. Thanks, Lydia

[lydialucchesi]

Hi @bstabler and @nuest, we have addressed and incorporated all of revisions from the first review (https://github.com/lydialucchesi/Vizumap/blob/master/paper/revisions.md). Please let me know if there is any additional information I can provide regarding the changes made.

Should we update the versioning from 1.0.0 to 2.0.0 given the major changes? Version 1.0.0 is from the original package release in 2017, and the name of the package at that time was VizU.

@nuest, thank you for your thoughtful, constructive feedback in the review. We are so excited with the improved state of the package and paper.

Kind regards, Lydia

[nuest]

@lydialucchesi Thanks! Will take look early next week. Could you be so kind and provide a comparison link between the version first submitted and the updated one? Thanks!

@bstabler What's your take on the version number?

I'd suggest to stick with semantic versioning and not make it a major change if there were not breaking changes.

[nuest]

@whedon generate pdf

[whedon]

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

[lydialucchesi]

@nuest, below is a link comparing the version that was reviewed (I pushed a few minor fixes after we submitted to JOSS and prior to your review) and the updated version of Vizumap.
https://github.com/lydialucchesi/Vizumap/compare/75628e…059c21d

Here is a link to the repository prior to the revisions.
https://github.com/lydialucchesi/Vizumap/tree/75628e28b79c52355b574e699688f53a0d9f284d

[bstabler]

Hi @jsta, @jayrobwilliams, @mikerspencer, @GISerDaishaoqing - we lost one of our reviewers so I'm wondering if you would be interested in reviewing? Thanks!

[GISerDaiShaoqing]

@bstabler Thanks for the invitation. I'm pleased to review this paper.

[bstabler]

@whedon add @GISerDaiShaoqing as reviewer

[whedon]

OK, @GISerDaiShaoqing is now a reviewer

[nuest]

@bstabler @lydialucchesi I'll do the second round of my reviews early next week. Looking forward to see what @GISerDaiShaoqing thinks! Welcome!