minor edits

proposal/problemdefinition.Qmd

@@ -28,7 +28,7 @@ However, geospatial packages like `terra` and `sf` don't work well with `targets
 One notable difficulty is that `targets` saves the R objects generated by computational steps to disk, by default to an .rds file.
 However, R objects generated by the `terra` package contain a C++ pointer to the data, rather than the data itself.
 When one of these `terra` objects is saved (e.g. as a .rds) and read back into R, it loses information about the data it represents and no longer works.
-To make these R objects portable and suitable for use with `targets` they need to be "marshaled" and "unmarshaled" requiring more complex code, for a custom format.
+To make these R objects portable and suitable for use with `targets` they need to be "marshaled" and "unmarshaled" requiring more complex code for a custom format.
 
 A second obstacle is that often geospatial data is written in multiple files.
 For example, [shapefiles](https://en.wikipedia.org/wiki/Shapefile) are actually a collection of up to 12 files with different extensions.

proposal/proposal.Qmd

@@ -35,7 +35,10 @@ Depending on project type the detail section should include:
 -->
 
 In the `targets` package, analysis steps, or "targets", are defined with the `tar_target()` function.
-Targetopia packages provide additional `tar_*()` functions that extend `targets` by providing target archetypes for specialized workflows. A new `tar_*()` function requires that you specify reading, writing, marshalling, and unmarshaling of these new formats. Briefly, reading and writing could be thought of as functions that read and write data, like `read.csv()` and `write.csv()`. Marshalling and unmarshalling are to do with handling the objects as serialised data - similar to read write.
+Targetopia packages provide additional `tar_*()` functions that extend `targets` by providing target archetypes for specialized workflows.
+A new `tar_*()` function requires that you specify reading, writing, marshaling, and unmarshaling of these new formats.
+Briefly, reading and writing could be thought of as functions that read and write data, like `read.csv()` and `write.csv()`.
+Marshaling and unmarshaling are to do with handling the objects as serialised data—similar to read write.
 The main contribution of `geotargets` will be a series of alternative `tar_*()` functions that create targets with pre-defined formats that take care of the details of how these R objects are written out and read in by downstream targets.
 For example, to write a target that creates a raster using the `terra` package, one would use `geotargets::tar_terra_rast(name, command)`.
 `tar_terra_rast()` would provide a pre-defined format created with `targets::tar_format()` with functions for reading, writing, marshaling, and unmarshaling `terra` `SpatRaster` objects.

proposal/requirements.Qmd

@@ -15,6 +15,7 @@ An idea of what is required to make the project actually happen
 
 Nicholas Tierney and Eric Scott will take the lead in developing code for this project.
 Both have experience developing R packages and working with `targets` as well as some experience with geospatial analysis in R.
+Both Nicholas and Eric are familiar with the rOpenSci package review process and have published R packages on CRAN.
 Additionally we plan to consult with geospatial experts who are more familiar with the "rough edges" related to doing geospatial analysis in R and with the `targets` package.
 
 ## Processes
@@ -34,7 +35,8 @@ We request funding to pay for the time of the personnel working on this project.
 -   Eric Scott, 108 hours totaling \$5,184
 -   Nicholas Tierney, 108 hours totaling \$7,128
 
-Additionally, we plan to arrange several meetings with geospatial experts to discuss less well understood aspects of geospatial software, such as interfaces to GDAL, and components like the "vsizip" API. We would like to pay the experts for their time, and also offer to pay them to assist us in implementing certain features. 
+Additionally, we plan to arrange several meetings with geospatial experts to discuss less well understood aspects of geospatial software, such as interfaces to GDAL, and components like the "vsizip" API.
+We would like to pay the experts for their time, and also offer to pay them to assist us in implementing certain features.
 
 -   Consulting, 36 hours totaling \$3600
 
@@ -48,8 +50,9 @@ For a total of: \$15,912
 
 ## Summary
 
+```{=html}
 <!--
 A summary of the requirements that contextualises the costs
 -->
-
+```
 These costs are a one-time investment to pay for initial development of the `geotargets` package totaling \$15,912.

proposal/success.Qmd

@@ -20,27 +20,33 @@ What does success look like?
 -->
 
 Success in the `geotargets` project looks like supporting fundamental geospatial raster and vector operations for the `terra` and `sf` packages.
-We will include examples of using these targets workflows for `terra` and `sf` in the form of vignettes, as well as link to existing repositories that demonstrate varying degrees of complexity in usage of `geotargets`. See for example [demo-geotargets](https://github.com/njtierney/demo-geospatial-targets), and [map-ir-pipeline](https://github.com/idem-lab/map-ir-pipeline).
+We will include examples of using these targets workflows for `terra` and `sf` in the form of vignettes, as well as link to existing repositories that demonstrate varying degrees of complexity in usage of `geotargets`.
+See for example [demo-geotargets](https://github.com/njtierney/demo-geospatial-targets), and [map-ir-pipeline](https://github.com/idem-lab/map-ir-pipeline).
 
 ## Measuring success
 
+```{=html}
 <!-- 
 How will we know when success is achieved, what markers can we use along the way 
 -->
-
-We will use github issues to identify key tasks that require completing.
+```
+We will use GitHub issues to identify key tasks that require completing.
 For example, identifying target components for rasters and vectors for the `terra` package were outlined in <https://github.com/njtierney/geotargets/issues/12>.
 The pull requests that resolved this were linked in the issue.
 
 We will ensure the package is has high test coverage of over 80% (currently test coverage is 97%).
 This will make the package easier to maintain, as any breaking changes will be identified early.
-We will use github actions to ensure `geotargets` can be installed on windows, macOS, and linux.
-High test coverage and github actions together will indicate to users this package is reliable and well maintained, which will hopefully improve trust and user takeup.
+We will use GitHub actions to ensure `geotargets` can be installed on windows, macOS, and linux.
+High test coverage and GitHub actions together will indicate to users this package is reliable and well maintained, which will hopefully improve trust and user takeup.
 
-Another way we will measure success is by community uptake. If the project is used by the community then we will know that the project is successful, because it means it is solving a real need for the people using it.
-We can measure this success via a few metrics such as GitHub stars, downloads from CRAN, and citations to the software. Currently the project was created on 2024-03-03, and as of 2024-03-22 it has 35 stars. This indicates that the project is already gathering interest from the community.
+Another way we will measure success is by community uptake.
+If the project is used by the community then we will know that the project is successful, because it means it is solving a real need for the people using it.
+We can measure this success via a few metrics such as GitHub stars, downloads from CRAN, and citations to the software.
+Currently the project was created on 2024-03-03, and as of 2024-03-22 it has 35 stars.
+This indicates that the project is already gathering interest from the community.
 
-We will regularly engage with the community to see that we are meeting their needs in geospatial workflow management. For example, posting on mastodon, responding to issues and discussions on github, and delivering talks on using geotargets to local R communities.
+We will regularly engage with the community to see that we are meeting their needs in geospatial workflow management.
+For example, posting on mastodon, responding to issues and discussions on GitHub, and delivering talks on using `geotargets` to local R communities.
 
 ## Future work