clarify what targetopia packages do

proposal/proposal.Qmd

@@ -19,7 +19,8 @@ At a high-level address what your proposal is and how it will address the proble
 
 Our goal is to create a package that makes using `targets` for geospatial analysis in R as seamless as possible.
 To that end, `geotargets` will provide custom functions for defining geospatial targets that take care of translating and saving R objects for the user.
-In addition, we will create vignettes demonstrating how to use various geospatial R packages with `targets`. Where appropriate, we will identify contributions to existing R packages to make them easier to use with `targets` and `geotargets`.
+In addition, we will create vignettes demonstrating how to use various geospatial R packages with `targets`.
+Where appropriate, we will identify contributions to existing R packages to make them easier to use with `targets` and `geotargets`.
 
 ## Detail
 
@@ -34,14 +35,16 @@ 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 extend `targets` by providing additional `tar_*()` functions with custom storage formats or that are "target factories" (targets that create targets on runtime).
+Targetopia packages provide additional `tar_*()` functions that extend `targets` primarily in two ways: by providing custom storage formats or by acting as "target factories" (targets that create multiple targets on runtime).
 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 marshaling, writing, reading, and unmarshaling `terra` `SpatRaster` objects.
-In this case, marshaling/unmarshaling involves running `terra::wrap()` and `terra::unwrap()`, respectively, to make the R object "self-contained" rather than just containing a pointer to external data.
+In this case, marshaling/unmarshaling involves running `terra::wrap()` and `terra::unwrap()`, respectively, to make the R object "self-contained" rather than just containing a C++ pointer to the data.
 This is especially necessary for parallel computing with `targets` since `SpatRaster` objects don't work outside of the R session they were created in without `wrap()`ing them first.
 
 As a minimum viable product, we hope to deliver an R package, hosted on GitHub, supporting raster and vector data objects from the `terra` and `sf` packages with custom target functions.
 Support for additional geospatial packages will be added based on feedback from the user community and through consultation with geospatial specialists.
-In initial development we will choose sensible defaults for what file types targets will be stored as (e.g. GeoTIFF for raster data). In the future we will develop a `filetype` argument for each `tar_*` function, since there are many options for how geospatial data can be stored on disk by these packages. For example, "netCDF", "HEIF", and "BMP", and 161 other options listed in the [GDAL raster driver](https://gdal.org/drivers/raster/index.html).
+In initial development we will choose sensible defaults for what file types targets will be stored as (e.g. GeoTIFF for raster data).
+In the future we will develop a `filetype` argument for each `tar_*` function, since there are many options for how geospatial data can be stored on disk by these packages.
+For example, "netCDF", "HEIF", and "BMP", and 161 other options listed in the [GDAL raster driver](https://gdal.org/drivers/raster/index.html).
 This will offer flexibility in light of trade-offs between file size, read/write speed, and dependency requirements similar to the existing options for how objects are stored by the `targets` package (i.e. default '.rds' with options for faster/smaller file types).