Open kadyb opened 4 years ago
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 2180parcel_get()
- allowing for searching based on spatial objectsgeonames_download()
to return an sf
objectpointDTM100_download()
to return an sf
objectTODO:
DONE:
pointDTM_get()
- the example does not work for me
Fixed in #10geodb_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._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_geocodePL_get()
to return an sf
objectTO DISCUSS/OMIT:
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)
- the
orto_download()
function now expects the output oforto_request()
. How about making it more user-friendly? One possibility, for example, would be fororto_download()
to accept some spatial object (e.g., polygon, extent, point) and some other arguments (e.g.,year
,pixel
). Then, theorto_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:
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.
pointDTM_get
seq_len(nrow(nz))
instead of1:nrow(nz)
object_usage_linter
), rcmdcheckpointDTM_get
pointDTM_get
only for small sets, andDEM_request
andpointDTM100_download
for large"