Ideas

[kadyb]

• 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)
• print current iteration
• documentation
• data license
• use seq_len(nrow(nz)) instead of 1:nrow(nz)
• connection retry from another package
• translate polish names to english
• lintr (codetools included in object_usage_linter), rcmdcheck
• flexible area size in pointDTM_get
• tests (testthat, tinytest or testit)
• make a clear table with Polish and English names of the datasets and corresponding function to use
• CI, lintr
• rayshader example: orthophotomap + DTM + 3D buildings (check EAlidaR)
• add check and doc: coordinates must be numeric, not string
• add support to custom saving path
• 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"
• 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

[Nowosad]

• - 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:

• - pointDTM_get() - the example does not work for me
  Fixed in Error in pointDTM_get() #10
• - 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.
• - 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
• - fill out the Acknowledgment section in README
• - some functions download and unzip the files. I think it should be either one or the other
• - allow an option to geocodePL_get() to return an sf object

TO DISCUSS/OMIT:

1. 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)

[kadyb]

1. 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:

1. 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.
2. 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.

[Nowosad]

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.