Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when using spatial_file_path #75

Closed
dk-forestry opened this issue Jun 5, 2017 · 7 comments
Closed

Error when using spatial_file_path #75

dk-forestry opened this issue Jun 5, 2017 · 7 comments

Comments

@dk-forestry
Copy link

I'm trying to download MODIS data using the spatial_file_path-option. When using the shapefile manually in the GUI to "Load extent from a spatial file", everything works as expected. However, when I provide it as an argument like this

MODIStsp(gui = FALSE, options_file = "options.json", spatial_file_path = "shapefile.shp")

I get the following error:

Error in as.vector(x) : no method for coercing this S4 class to a vector

Would you have any ideas what might be the problem here?

ranghetti added a commit that referenced this issue Jun 5, 2017
to allow reading spatial_file_path files
@ranghetti
Copy link
Contributor

Dear @dk-forestry,
thank you for signaling it; i made a change in the code which should have solved the problem. Please try to update your MODIStsp installation from GitHub (devtools::install_github("lbusett/MODIStsp")).

@dk-forestry
Copy link
Author

Thank you, it now works with the updated version. :)

By the way, I noticed two things related to this:

  1. In the example for Non-Interactive Execution and scheduled processing the following code is used:

# Create a character array containing a list of shapefiles (or other spatial files)
extent_list = list.files("X:/path/containing/some/shapefiles/", "\\.shp$")

Shouldn't list.files include the argument full.names = TRUE?

  1. If the argument for spatial_file_path points to a non-existing file, the user receives the following error:

Error in MODIStsp(gui = FALSE, options_file = option_file, spatial_file_path = single_shape) :
Error in bbox_from_file(file_path = spatial_file_path, out_crs = general_opts$user_proj4) :
File format not recognized by GDAL or OGR.
Details: Error in CRS(gsub("'", "", cmd_output)) :
PROJ4 argument-value pairs must begin with +: ERROR 1: ERROR - failed to load SRS definition from NA

Maybe it would make sense to check somewhere if the shapefile exists and give a clear error if not?

@lbusett
Copy link
Contributor

lbusett commented Jun 6, 2017

Both good points ! Thanks for the suggestions !
We'll implement them in the next release.

Lorenzo

@lbusett lbusett closed this as completed Jun 6, 2017
@dk-forestry
Copy link
Author

dk-forestry commented Jun 6, 2017

I was working and downloading some data with the new version from above and noticed something else related to the spatial_file_path.

Assuming I have a shapefile called studyarea.shp, then a folder called studyarea is created in the Main output folder. So far, so good. However, if MODIStsp is run again (with exactly the same option file and shapefile), a new folder called studyarea_1 is created, and all data is reprocessed (even though the ReProcess Existing Data was set to No. If the command is run again, studyarea_2 is created, then studyarea_3, and so on.

I imagine that this behavior is unexpected, because during scheduled data downloads or this workaround the same data would be created over and over (until the HDD is at its limits ;) ). Is there maybe a fix or workaround?

@lbusett
Copy link
Contributor

lbusett commented Jun 6, 2017

Definitely a bug in the spatial_file_path option. We'll investigate it ASAP.

@lbusett lbusett reopened this Jun 7, 2017
ranghetti added a commit that referenced this issue Jun 7, 2017
Now output directory mantains the name of spatial_file_path even if this already exists
@ranghetti
Copy link
Contributor

ranghetti commented Jun 7, 2017

This was an expected behaviour: the intention was to create separate folders in case this function was run in a cycle, in which spatial files had the same basename (being placed in different folders).
Actually this is an uncommon situation, while scheduled download appears to be a more common one. So this functionality was remove: now (with commit 099b432) the original folder name is maintained.

@dk-forestry
Copy link
Author

Thanks for the explanation and the changes to the code! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants