From 02bad366f504a8f91759780e3fefaf1597c12fbc Mon Sep 17 00:00:00 2001 From: Eric Scott Date: Mon, 11 Mar 2024 16:18:06 -0700 Subject: [PATCH 01/11] initial notes, will flesh out later --- proposal/problemdefinition.Qmd | 7 ++++++- proposal/proposal.Qmd | 7 ++++++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/proposal/problemdefinition.Qmd b/proposal/problemdefinition.Qmd index f6f8157..7553407 100644 --- a/proposal/problemdefinition.Qmd +++ b/proposal/problemdefinition.Qmd @@ -19,4 +19,9 @@ It is important to cover: - [ ] Why it should be tackled --> ``` -An example in-text citation [@wickham2016]. + +- geospatial data is big and computationaly intensive (slow) +- targets is built for better handling big slow steps +- geospatial data doesn't work with targets "out of the box" + - R objects don't actually contain data (just memory pointers) + - File formats often consist of multiple files---not allowed for targets diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index e1dfc09..9847126 100644 --- a/proposal/proposal.Qmd +++ b/proposal/proposal.Qmd @@ -23,4 +23,9 @@ Depending on project type the detail section should include: - [ ] Minimum Viable Product - [ ] Architecture - [ ] Assumptions ---> \ No newline at end of file +--> + +- Community feedback about features needed +- Identify shortcomings in existing packages that we could contribute to to make them work better with `targets` (e.g. gadm not returning filepath, so doesn't work with `tar_file()`). +- Package that integrates with terra and sf +- Filetype backend independent of pacakge somewhat with `filetype` argument From 1dc3afab5df40debd5eb0dedfb1fed4bbb6447bf Mon Sep 17 00:00:00 2001 From: Eric Scott Date: Mon, 11 Mar 2024 16:55:52 -0700 Subject: [PATCH 02/11] draft of problem definition --- proposal/problemdefinition.Qmd | 26 ++++++++++++++++-------- references.bib | 37 +++++++++++++++++++++++++++------- 2 files changed, 48 insertions(+), 15 deletions(-) diff --git a/proposal/problemdefinition.Qmd b/proposal/problemdefinition.Qmd index 7553407..f80bed9 100644 --- a/proposal/problemdefinition.Qmd +++ b/proposal/problemdefinition.Qmd @@ -1,5 +1,4 @@ --- -bibliography: references.bib editor: markdown: wrap: sentence @@ -7,7 +6,6 @@ editor: # The Problem -```{=html} -``` -- geospatial data is big and computationaly intensive (slow) -- targets is built for better handling big slow steps -- geospatial data doesn't work with targets "out of the box" - - R objects don't actually contain data (just memory pointers) - - File formats often consist of multiple files---not allowed for targets +Geospatial computations in R are made possible by a group of R packages aimed at [spatial](https://cran.r-project.org/web/views/Spatial.html) and [spatio-temporal](https://cran.r-project.org/web/views/SpatioTemporal.html) data such as `terra`, `sf`, and `stars` [@pebesma2023; @hijmans2024]. +Computations on spatial or spatio-temporal data can often be computationally intensive and slow when the underlying data is large (e.g. high-resolution global rasters). +Managing complex geospatial workflows can be confusing and re-running entire data pipelines is likely to be very time-consuming. +The `targets` R package aims to aid with confusing and long-running workflows by automatically detecting dependencies among steps and only re-running steps that need to be re-run [@landau2021]. +This seems like a natural fit for complex geospatial workflows in R. +However, geospatial packages like `terra` and `sf` don't work well with `targets` without extensive customization. + +One notable difficulty is that `targets`, by default, saves R objects generated by computational steps, but R objects generated by the `terra` package possibly do not actually contain the data itself but rather a pointer to the data. +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 complicated code for a custom format. + +A second obstacle is that often geospatial data is written in multiple files—for example, [shapefiles](#0), which are actually a collection of up to 12 files with different extensions. +This limits compatibility with `targets` because the intermediate objects stored in a `targets` pipeline are required to be single files with no file extension. + +Both of these challenges (and others) have been solved but none of these solutions have been formalized into an R package. +Other packages exist as part of a "[targetopia](https://wlandau.github.io/targetopia/)" that extend `targets` to work for specialized needs. +We hope that `geotargets` can join the "targetopia" and simplify geospatial data analysis with `targets`. +We belive this will unlock a powerful workflow management tool for a large group of R users that have previously been unable (or unwiling) to use it because of these challenges. diff --git a/references.bib b/references.bib index 6a803f0..023d948 100644 --- a/references.bib +++ b/references.bib @@ -1,9 +1,32 @@ -@book{wickham2016, - title = {ggplot2: Elegant graphics for data analysis}, - author = {Wickham, Hadley}, - year = {2016}, - date = {2016}, - publisher = {Springer-Verlag New York}, - url = {https://ggplot2.tidyverse.org} +@article{landau2021, + title = {The targets R package: a dynamic Make-like function-oriented pipeline toolkit for reproducibility and high-performance computing}, + author = {Landau, William}, + year = {2021}, + month = {01}, + date = {2021-01-15}, + journal = {Journal of Open Source Software}, + pages = {2959}, + volume = {6}, + number = {57}, + doi = {10.21105/joss.02959}, + url = {http://dx.doi.org/10.21105/joss.02959} +} + +@article{pebesma2023, + title = {{Spatial Data Science: With applications in R}}, + author = {Pebesma, Edzer and Bivand, Roger}, + year = {2023}, + date = {2023}, + pages = {352}, + doi = {10.1201/9780429459016}, + url = {https://r-spatial.org/book/} +} + +@article{hijmans2024, + title = {terra: Spatial Data Analysis}, + author = {Hijmans, Robert J.}, + year = {2024}, + date = {2024}, + url = {https://CRAN.R-project.org/package=terra} } From 3dfb360667fa8dcec0a670cabb253dc62f1c24a7 Mon Sep 17 00:00:00 2001 From: Eric Scott Date: Mon, 11 Mar 2024 17:15:35 -0700 Subject: [PATCH 03/11] draft of details --- proposal/proposal.Qmd | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index 9847126..50ebcce 100644 --- a/proposal/proposal.Qmd +++ b/proposal/proposal.Qmd @@ -4,17 +4,25 @@ editor: markdown: wrap: sentence --- + # The proposal + ## Overview + +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 hope to create vignettes demonstrating how to use various geospatial R packages with `targets` and to identify ways we can contribute to existing R packages to make them easier to use with `targets` and `geotargets`. + ## Detail + -- Community feedback about features needed -- Identify shortcomings in existing packages that we could contribute to to make them work better with `targets` (e.g. gadm not returning filepath, so doesn't work with `tar_file()`). -- Package that integrates with terra and sf -- Filetype backend independent of pacakge somewhat with `filetype` argument +In the `targets` package, analysis steps, or "targets", are defined with the `tar_target()` function. +The main contribution of `geotargets` will be a series of alternative `tar_*()` functions that create targets where the methods for reading and writing geospatial R objects is pre-defined, yet flexible. +For example, when a target creates a raster using the `terra` package, one would use `geotargets::tar_terra_rast()`. +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), but we plan to add a `filetype` argument since there are many options for how geospatial data can be stored on disk by these packages. +This will offer flexibility in light of tradeoffs 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). From 87d78248c5d651d93b55fcf5d5749da1bc7cc5ba Mon Sep 17 00:00:00 2001 From: Eric Scott Date: Mon, 11 Mar 2024 17:29:36 -0700 Subject: [PATCH 04/11] add more details about implementation --- proposal/proposal.Qmd | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index 50ebcce..b0dd79d 100644 --- a/proposal/proposal.Qmd +++ b/proposal/proposal.Qmd @@ -34,8 +34,13 @@ Depending on project type the detail section should include: --> In the `targets` package, analysis steps, or "targets", are defined with the `tar_target()` function. -The main contribution of `geotargets` will be a series of alternative `tar_*()` functions that create targets where the methods for reading and writing geospatial R objects is pre-defined, yet flexible. -For example, when a target creates a raster using the `terra` package, one would use `geotargets::tar_terra_rast()`. +Targetopia packages extend `targets` by providing additional `tar_*()` functions with custom storage formats or that are "target factories" (targets that create 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. +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), but we plan to add a `filetype` argument since there are many options for how geospatial data can be stored on disk by these packages. From c3a8d39130d2c47e2e84c684b07e7c4d3120979d Mon Sep 17 00:00:00 2001 From: Eric Scott Date: Wed, 13 Mar 2024 14:46:21 -0700 Subject: [PATCH 05/11] edits --- proposal/problemdefinition.Qmd | 6 +++--- proposal/proposal.Qmd | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/proposal/problemdefinition.Qmd b/proposal/problemdefinition.Qmd index f80bed9..ccd3fc3 100644 --- a/proposal/problemdefinition.Qmd +++ b/proposal/problemdefinition.Qmd @@ -24,14 +24,14 @@ The `targets` R package aims to aid with confusing and long-running workflows by This seems like a natural fit for complex geospatial workflows in R. However, geospatial packages like `terra` and `sf` don't work well with `targets` without extensive customization. -One notable difficulty is that `targets`, by default, saves R objects generated by computational steps, but R objects generated by the `terra` package possibly do not actually contain the data itself but rather a pointer to the data. +One notable difficulty is that `targets`, by default, saves R objects generated by computational steps, but R objects generated by the `terra` package may not actually contain the data itself but rather a pointer to the data. 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 complicated code for a custom format. A second obstacle is that often geospatial data is written in multiple files—for example, [shapefiles](#0), which are actually a collection of up to 12 files with different extensions. This limits compatibility with `targets` because the intermediate objects stored in a `targets` pipeline are required to be single files with no file extension. -Both of these challenges (and others) have been solved but none of these solutions have been formalized into an R package. +Both of these challenges (and others) have been solved in bespoke ways for individual projects, but to date these solutions have not been formalized and distributed as an R package. Other packages exist as part of a "[targetopia](https://wlandau.github.io/targetopia/)" that extend `targets` to work for specialized needs. We hope that `geotargets` can join the "targetopia" and simplify geospatial data analysis with `targets`. -We belive this will unlock a powerful workflow management tool for a large group of R users that have previously been unable (or unwiling) to use it because of these challenges. +We believe this will unlock a powerful workflow management tool for a large group of R users that have previously been unable (or unwilling) to use it because of these challenges. diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index b0dd79d..35d4b0f 100644 --- a/proposal/proposal.Qmd +++ b/proposal/proposal.Qmd @@ -43,5 +43,5 @@ This is especially necessary for parallel computing with `targets` since `SpatRa 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), but we plan to add a `filetype` argument since there are many options for how geospatial data can be stored on disk by these packages. -This will offer flexibility in light of tradeoffs 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). +In initial development we will choose sensible defaults for what file types targets will be stored as (e.g. GeoTIFF for raster data), but we plan to 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. +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). From af38771a84f5d1c4ea39ce7975136a615b4507f8 Mon Sep 17 00:00:00 2001 From: "Eric R. Scott" Date: Thu, 14 Mar 2024 14:24:08 -0700 Subject: [PATCH 06/11] Update proposal/problemdefinition.Qmd Co-authored-by: Nicholas Tierney --- proposal/problemdefinition.Qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposal/problemdefinition.Qmd b/proposal/problemdefinition.Qmd index ccd3fc3..813cbae 100644 --- a/proposal/problemdefinition.Qmd +++ b/proposal/problemdefinition.Qmd @@ -18,7 +18,7 @@ It is important to cover: --> Geospatial computations in R are made possible by a group of R packages aimed at [spatial](https://cran.r-project.org/web/views/Spatial.html) and [spatio-temporal](https://cran.r-project.org/web/views/SpatioTemporal.html) data such as `terra`, `sf`, and `stars` [@pebesma2023; @hijmans2024]. -Computations on spatial or spatio-temporal data can often be computationally intensive and slow when the underlying data is large (e.g. high-resolution global rasters). +Computations on spatial or spatio-temporal data can often be computationally intensive and slow when the underlying data is large (e.g. high-resolution global rasters). Depending on the data source and operation, this can range from taking seconds to days or weeks. Managing complex geospatial workflows can be confusing and re-running entire data pipelines is likely to be very time-consuming. The `targets` R package aims to aid with confusing and long-running workflows by automatically detecting dependencies among steps and only re-running steps that need to be re-run [@landau2021]. This seems like a natural fit for complex geospatial workflows in R. From 09b5a2aea249e216fdda5f4133c8835e926ddb11 Mon Sep 17 00:00:00 2001 From: "Eric R. Scott" Date: Thu, 14 Mar 2024 14:24:22 -0700 Subject: [PATCH 07/11] Update proposal/problemdefinition.Qmd Co-authored-by: Nicholas Tierney --- proposal/problemdefinition.Qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposal/problemdefinition.Qmd b/proposal/problemdefinition.Qmd index 813cbae..e2405c5 100644 --- a/proposal/problemdefinition.Qmd +++ b/proposal/problemdefinition.Qmd @@ -24,7 +24,7 @@ The `targets` R package aims to aid with confusing and long-running workflows by This seems like a natural fit for complex geospatial workflows in R. However, geospatial packages like `terra` and `sf` don't work well with `targets` without extensive customization. -One notable difficulty is that `targets`, by default, saves R objects generated by computational steps, but R objects generated by the `terra` package may not actually contain the data itself but rather a pointer to the data. +One notable difficulty is that `targets`, by default, saves R objects generated by computational steps, but R objects generated by the `terra` package may not actually contain the data itself but rather a C++ pointer to the data. 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 complicated code for a custom format. From f2eaef7a3fc538cf93e8afc5baaa2de4e0a64ef8 Mon Sep 17 00:00:00 2001 From: "Eric R. Scott" Date: Thu, 14 Mar 2024 14:24:35 -0700 Subject: [PATCH 08/11] Update proposal/problemdefinition.Qmd Co-authored-by: Nicholas Tierney --- proposal/problemdefinition.Qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposal/problemdefinition.Qmd b/proposal/problemdefinition.Qmd index e2405c5..7f4e4fe 100644 --- a/proposal/problemdefinition.Qmd +++ b/proposal/problemdefinition.Qmd @@ -32,6 +32,6 @@ A second obstacle is that often geospatial data is written in multiple files—f This limits compatibility with `targets` because the intermediate objects stored in a `targets` pipeline are required to be single files with no file extension. Both of these challenges (and others) have been solved in bespoke ways for individual projects, but to date these solutions have not been formalized and distributed as an R package. -Other packages exist as part of a "[targetopia](https://wlandau.github.io/targetopia/)" that extend `targets` to work for specialized needs. +Other packages exist as part of a "[targetopia](https://wlandau.github.io/targetopia/)" that extend `targets` to work for specialized needs. For example [stantargets](https://docs.ropensci.org/stantargets/) for using targets with [stan](https://mc-stan.org/) models. We hope that `geotargets` can join the "targetopia" and simplify geospatial data analysis with `targets`. We believe this will unlock a powerful workflow management tool for a large group of R users that have previously been unable (or unwilling) to use it because of these challenges. From 8d47e7e341037ad3a764d84eea9126dbb6ddf8bc Mon Sep 17 00:00:00 2001 From: "Eric R. Scott" Date: Thu, 14 Mar 2024 14:24:49 -0700 Subject: [PATCH 09/11] Update proposal/proposal.Qmd Co-authored-by: Nicholas Tierney --- proposal/proposal.Qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index 35d4b0f..27ee2cc 100644 --- a/proposal/proposal.Qmd +++ b/proposal/proposal.Qmd @@ -19,7 +19,7 @@ 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 hope to create vignettes demonstrating how to use various geospatial R packages with `targets` and to identify ways we can contribute 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 From f442853e25885b312d3f9f15292ce82908ae77a9 Mon Sep 17 00:00:00 2001 From: "Eric R. Scott" Date: Thu, 14 Mar 2024 14:26:38 -0700 Subject: [PATCH 10/11] Update proposal/proposal.Qmd Co-authored-by: Nicholas Tierney --- proposal/proposal.Qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index 27ee2cc..ac33b49 100644 --- a/proposal/proposal.Qmd +++ b/proposal/proposal.Qmd @@ -43,5 +43,5 @@ This is especially necessary for parallel computing with `targets` since `SpatRa 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), but we plan to 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. +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). From 625a64dc1a2b3ddfe8407b2ba222d45d9392beb8 Mon Sep 17 00:00:00 2001 From: Eric Scott Date: Thu, 14 Mar 2024 14:30:42 -0700 Subject: [PATCH 11/11] clarify what targetopia packages do --- proposal/proposal.Qmd | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposal/proposal.Qmd b/proposal/proposal.Qmd index ac33b49..df4327a 100644 --- a/proposal/proposal.Qmd +++ b/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).