rgugik Ideas

[x] add sampling factor to pointDTM_get
[ ] create a function that will check if the input polygon lies within the Poland's area (see st_contains, st_coveredby, st_within)
[x] print current iteration
[x] documentation
[x] data license
[x] use seq_len(nrow(nz)) instead of 1:nrow(nz)
[ ] connection retry from another package
[x] translate polish names to english
[x] lintr (codetools included in object_usage_linter), rcmdcheck
[x] flexible area size in pointDTM_get
[x] tests (testthat, tinytest or testit)
[x] make a clear table with Polish and English names of the datasets and corresponding function to use
[x] CI, lintr
[ ] rayshader example: orthophotomap + DTM + 3D buildings (check EAlidaR)
[ ] add check and doc: coordinates must be numeric, not string
[x] add support to custom saving path
[x] links to other functions in docs are not interactive
[ ] write to: "use function pointDTM_get only for small sets, and DEM_request and pointDTM100_download for large"
[x] hexlogo
[ ] OpenGraph image (GitHub, website)
[ ] name README-unnamed-chunk-4-1.png, README-unnamed-chunk-6-1.png in rgugik/man/figures
[ ] rename function to object, see
[ ] write blogpost to Medium, LinkedIn, Jakub website
[ ] change raster package to stars in README

Jul 17 '20 11:07 kadyb

[ ] - parcel_get() - allowing for X and Y to accept both EPSG 2180 and 4326. For example, when X is lower than 180 then the function converts the coordinate from 4326 to 2180
[ ] - parcel_get() - allowing for searching based on spatial objects
[ ] - (suggestion) allow an option to geonames_download() to return an sf object
[ ] - (suggestion) allow an option to pointDTM100_download() to return an sf object

TODO:

[ ] - create a vignette showing application of each of the created function

DONE:

[x] - pointDTM_get() - the example does not work for me Fixed in #10
[x] - examples of how the geodb_download() function's output can be used further I added example with data load and plot. I also added a short description of the database in Polish and English.
[x] - rename the geocode() function - this name is too generic and inconsistent with other functions - there are many packages with this name (e.g. geocodePL_get() I changed geocode() function to geocodePL_get() in 4f5455a
[x] - fill out the Acknowledgment section in README
[x] - some functions download and unzip the files. I think it should be either one or the other
[x] - allow an option to geocodePL_get() to return an sf object

TO DISCUSS/OMIT:

the orto_download() function now expects the output of orto_request(). How about making it more user-friendly? One possibility, for example, would be for orto_download() to accept some spatial object (e.g., polygon, extent, point) and some other arguments (e.g., year, pixel). Then, the orto_request() would be used in the background. (We can keep the old behaviour when the first argument is a data.frame)

Aug 09 '20 12:08 Nowosad

the orto_download() function now expects the output of orto_request(). How about making it more user-friendly? One possibility, for example, would be for orto_download() to accept some spatial object (e.g., polygon, extent, point) and some other arguments (e.g., year, pixel). Then, the orto_request() would be used in the background. (We can keep the old behaviour when the first argument is a data.frame)

I thought about it, and I suppose that oversimplification can cause mistakes and unexpected results. I see two main drawbacks here:

What if the user enters unavailable attribute values (e.g. year = 2015, pixel = 0.05)? A variety of images are stored in the database, so there is a high probability that the user won't find images that meet his expectations in a given area and then will be disappointed that the function does not work. The safe solution is to return the available images, and then filter and download.
What if as a result there are several dozen or several hundred high resolution images to download? I think, the user doesn't want to download all possible images compositions. Moreover, I think the user is interested in the images within one series, so he can merge them into a larger mosaic. In case of all possible image combinations, it will be impossible.

Aug 14 '20 13:08 kadyb

Good points. That's why my thinking was to keep the old behavior when the input data is a data.frame (a result of orto_request()) and only allow for one-step downloading with orto_request() in the background as a second option (for more advanced users). However, this is just an idea - you will make the decision.

Aug 16 '20 16:08 Nowosad