JOSS Review: Improve Statement of need / description of use-cases

[Jo-Schie]

It seems to me, that the statement of need in the paper and/or the introduction part in the documentation could be a little clearer.

My understanding is this: The wdpar package can help users of the wdpa and wdoecm to work more effectively with the data, in a broad sense by allowing user automated download and preprocessing according to scientific recommendations. You talk a lot about "data cleaning procedures" which are difficult to implement, but the link to the final use-cases is still a bit blurry from my perspective (you do though describe them a bit in the "research application" part.)

For me, the question arises whether wdpar is "only" intended to serve as a planning and reporting tool (i.e. display and quantification of protected area coverage & reducing over-estimations).

-> I guess this is/was the main concern when you developed the package...

or whether wdpar could also serve other "final" purposes, such as monitoring and evaluation of protected areas' effectiveness.

-> this is probably what others have turned it into by using it for their own types of analysis

Is this interpretation correct? If so, then it could make sense to inform users about that because the wdpa_clean function with its default settings is really focussed on area estimations.

Maybe you could write something along the line of: the primary intent of the package is to calculate protected area coverage to e.g. report on the Aichi policy progress, nevertheless, part of the downloading and preprocessing routines can also be helpful in other contexts such as spatial analysis of protected area effectiveness. If the final use-case is different from official PA coverage reporting, then users should be aware of the settings in the wdpa_clean function and fine-tune them to their needs. For monitoring, it might make sense e.g. to "retain a specific PA status", to "not exclude Unesco sites" or to "increase the geometrical precision" of the data-cleaning functions to have better area estimations at local level.

Link to the review threat.

[jeffreyhanson]

Yeah - this an excellent point - thank you! I'll update the manuscript to incorperate your suggestion.

[jeffreyhanson]

@Jo-Schie, I've submitted a PR which aims to incorperate your feedback provided in this issue. When you get a chance, could you please take a look (see #54)?

EDIT: please ignore this comment, I'll add another PR which address this comments as well as #53.

[jeffreyhanson]

@Jo-Schie, I've submitted a PR which aims to incorperate feedback on both your issues (see #57). Specifically, this PR adds the following paragraph to address your comments. This paragraph makes it clear that the package has defaults which are designed specifically for national-scale protected area coverage assesments, and that these defaults can be customized (if desired) for other purposes. Thanks for proving an example paragraph as a starting point - I found that really helpful! How does that sound?

The \texttt{wdpar} \texttt{R} package is designed to provide a reproducible tool for downloading and cleaning the WDPA and WDOECM. Although the default settings for the data cleaning procedures are well-suited for national scale reporting of protected area coverage, they can be customized for other applications. For example, the precision of spatial data processing procedures can be increased so that they are suitable for local scale analyses. This is especially important because the default precision may remove smooth edges at fine scales. Additionally, the data cleaning procedures can be customized to retain protected areas regardless of their status which, in turn, could be useful for monitoring and evaluation of protected area effectiveness.

[jeffreyhanson]

@Jo-Schie, I just wanted to follow up and ask if the PR address your concerns on this issue?

[jeffreyhanson]

@Jo-Schie, if you get a moment, could you please check whether the PR addresses this issue too?

[Jo-Schie]

yep. I am on it. Is there any link to the new manuscript of the paper? I can only find the old one.

[jeffreyhanson]

Brilliant - thank you! Yeah, here's the .Rmd file (https://github.com/prioritizr/wdpar/blob/joschie-review/paper/paper.Rmd) and the PDF version (https://github.com/prioritizr/wdpar/blob/joschie-review/paper/paper.pdf).

[Jo-Schie]

okay. thanks. One question. I do have the feeling that the manuscript is very short, and you do neither show a little snippet of the code of the package nor do you show any output of an example application. I have checked a couple of paper in JOSS who all do that see e.g. here, here or here for papers published just lately.

Now I do understand, that showing code and outputs is not a strict precondition to publish the paper, so I am happy to close the issue also as is. Nevertheless, I suggest that you could add a little bit of the code snippets from your quick-start and maybe a plot to it. I think it could improve the overall quality of the paper since readers will already see what they can expect, but it is up to you if you want to do that or not.

so just give it a thought and comment back so I know when to close the issue.

[Jo-Schie]

The rest seems fine to me btw.

[jeffreyhanson]

Awesome - thank you very much! Yeah, I wasn't sure if papers were supposed to include coding examples or not. Yeah, I can put in a small demo and include a figure.

[jeffreyhanson]

Just to keep you in the loop, the PhantomJS web driver used by Rselenium no longer works - so the downloading functionality of the package is now broken. So I need to do some updating to wdpar so that it works again. So, I'm going to merge the PR that I've been working on with the changes to adress your feedback so I don't get into merge conflict hell. This will mean that some of your issues will be addressed, and some of them weren't. After merging the PR, I'lll then work on updating the package to fix the web driver issues, and then open a new PR to address your remaining issues. Sorry about this.

[jeffreyhanson]

Actually, it turns out the fix is very straightforward (replacing Rselenium with webdriver), so I'll just lump the fix into the PR.

[jeffreyhanson]

@Jo-Schie, I've just pushed a commit to PR #57 so that the manuscript now contains a short case study and a map showing some protected areas. When you get a chance, could you please take a look? This PR also contains updates to address the web driver data download issues too. To help make it easier to review, I've attached the PDF for the updated manuscript to here: paper.pdf. If the case study is satisfactory, my understanding is that merging the PR would address all your concerns - is that right? I just want to make sure I haven't missed anything.

[Jo-Schie]

I guess you could also Show also some Areal statistics eg sqkm in each iucn category to show the purpose of cleaning the dataset... but that's up to you. @jeffreyhanson i will close This issue so you can merge your changes.

[jeffreyhanson]

Thanks! Yeah, I wanted to keep the case study simple. Although I like the idea of providing aerial statistics, I worry that this is difficult to do without adding too much extra code that would require explanation (e.g., calculating aerial statistics would probably be best done using dplyr + sf). I suppose there are base package alternatives (e.g., using base::aggregate), but I wouldn't want to recommend these as best practice (and tidyverse users might find this concercing/confusing). Since I can't think of a simple way to do this, I'll just keep the current stats.

[jeffreyhanson]

Thanks so much @Jo-Schie for your amazing review! I really appreciate the time you've taken to provide such thorough and constructive feedback!