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 adding new index raster in MODIStsp #163

Closed
maximomenezes opened this issue Feb 5, 2019 · 30 comments
Closed

error adding new index raster in MODIStsp #163

maximomenezes opened this issue Feb 5, 2019 · 30 comments
Assignees
Labels
bug Issues due to a code bug enhancement {MODIStsp} enhancements proposals

Comments

@maximomenezes
Copy link

Hello.

My name is Máximo Menezes. I am a user of the MODIStsp script and am having trouble adding new indexes.

For example, I intend to perform simple subtraction of band 2 (NIR) with band 1 (Red). This operation fails even though I try different ways of writing the formula.

I tried without relatives: b2_NIR-b1_Red, with parentheses (b2_NIR-b1_Red), with space and unrelated b2_NIR - b1_Red and with parentheses and space (b2_NIR - b1_Red).

None of these mathematical operations accuse error (Set New Index), however, none of them generate a visible image. The file is generated, however, in white.

Could you help me understand what would be wrong?

Thanks and I await the response.

Best regards

Máximo Menezes Costa

@lbusett
Copy link
Contributor

lbusett commented Feb 8, 2019

Thanks for reporting. Will have a look ASAP.

In the meantime, could you please tell me which version of MODIStsp you are using , and share your sessioninfo() ?

Lorenzo

@maximomenezes
Copy link
Author

Hello Lorenzo.

Thanks for answering.

Below is the summary of the processing.


library(MODIStsp)
Warning message:
package ‘MODIStsp’ was built under R version 3.5.2
MODIStsp()
Loading required package: gWidgetsRGtk2
Loading required package: RGtk2
Loading required package: gWidgets
Loading required package: cairoDevice
[Mon Feb 11 18:08:33 2019] Welcome to MODIStsp!We will now search for a valid GDAL installation - pleasewait! (this will happen only once)
GDAL version in use: 2.2.3
[Mon Feb 11 18:13:41 2019] MODIStsp --> Starting processing
[Mon Feb 11 18:13:41 2019] Accessing http server at: http://e4ftl01.cr.usgs.gov/MOLT/MOD09GQ.006/
[Mon Feb 11 18:13:42 2019] Retrieving list of available Terra Files for Year 2012
[Mon Feb 11 18:13:42 2019] [Mon Feb 11 18:13:42 2019] All Required output files for date 2012_09_15 are already existing - Doing Nothing!
Set Reprocess to "Yes" to reprocess existing data!
[Mon Feb 11 18:13:42 2019] HDF File: MOD09GQ.A2012260.h13v10.006.2015249075703.hdf already exists on your system. Skipping download!
[Mon Feb 11 18:13:42 2019] [Mon Feb 11 18:13:42 2019] 1 files for date: 2012.09.16 were successfully downloaded!
[Mon Feb 11 18:13:42 2019] Computing Terra b2_NIR - b1_Red for date: 2012_09_16
[Mon Feb 11 18:14:15 2019] HDF File: MOD09GQ.A2012261.h13v10.006.2015249103704.hdf already exists on your system. Skipping download!
[Mon Feb 11 18:14:15 2019] [Mon Feb 11 18:14:15 2019] 1 files for date: 2012.09.17 were successfully downloaded!
[Mon Feb 11 18:14:19 2019] Processing Terra b1_Red files for date: 2012_09_17
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c3b936e4d.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b1_Red/MOD09GQ_b1_Red_2012_261.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:14:31 2019] Processing Terra b2_NIR files for date: 2012_09_17
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO
1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c6bb8338b.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b2_NIR/MOD09GQ_b2_NIR_2012_261.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:14:40 2019] Computing Terra b2_NIR - b1_Red for date: 2012_09_17
[Mon Feb 11 18:15:10 2019] Accessing http server at: http://e4ftl01.cr.usgs.gov/MOLA/MYD09GQ.006/
[Mon Feb 11 18:15:10 2019] Retrieving list of available Aqua Files for Year 2012
[Mon Feb 11 18:15:10 2019] HDF File: MYD09GQ.A2012259.h13v10.006.2015249054205.hdf already exists on your system. Skipping download!
[Mon Feb 11 18:15:10 2019] [Mon Feb 11 18:15:10 2019] 1 files for date: 2012.09.15 were successfully downloaded!
[Mon Feb 11 18:15:14 2019] Processing Aqua b1_Red files for date: 2012_09_15
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c507f64a2.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b1_Red/MYD09GQ_b1_Red_2012_259.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:15:25 2019] Processing Aqua b2_NIR files for date: 2012_09_15
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO
1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c312f184b.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b2_NIR/MYD09GQ_b2_NIR_2012_259.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:15:32 2019] Computing Aqua b2_NIR - b1_Red for date: 2012_09_15
[Mon Feb 11 18:16:00 2019] HDF File: MYD09GQ.A2012260.h13v10.006.2015249081152.hdf already exists on your system. Skipping download!
[Mon Feb 11 18:16:00 2019] [Mon Feb 11 18:16:00 2019] 1 files for date: 2012.09.16 were successfully downloaded!
[Mon Feb 11 18:16:04 2019] Processing Aqua b1_Red files for date: 2012_09_16
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c55631e54.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b1_Red/MYD09GQ_b1_Red_2012_260.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:16:16 2019] Processing Aqua b2_NIR files for date: 2012_09_16
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO
1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c579a2ee.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b2_NIR/MYD09GQ_b2_NIR_2012_260.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:16:24 2019] Computing Aqua b2_NIR - b1_Red for date: 2012_09_16
[Mon Feb 11 18:16:54 2019] HDF File: MYD09GQ.A2012261.h13v10.006.2015249083622.hdf already exists on your system. Skipping download!
[Mon Feb 11 18:16:54 2019] [Mon Feb 11 18:16:54 2019] 1 files for date: 2012.09.17 were successfully downloaded!
[Mon Feb 11 18:16:58 2019] Processing Aqua b1_Red files for date: 2012_09_17
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8cd99161.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b1_Red/MYD09GQ_b1_Red_2012_261.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:17:10 2019] Processing Aqua b2_NIR files for date: 2012_09_17
Checking gdal_installation...
Scanning for GDAL installations...
Checking the gdalUtils_gdalPath option...
GDAL version 2.4.0
GDAL command being used: "C:\OSGeo4W64\bin\gdal_translate.exe" -a_nodata "-28672" -ot "Int16" -of "GTiff" -a_srs "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs" -co "COMPRESS=None" "C:\Users\MAXIMO
1\AppData\Local\Temp\RtmpiGnWrc/mstp_temp\file1e8c3cb7977.vrt" "D:\Imagens\MODIS\MODIStsp/Surf_Ref_Daily_250m_v6/b2_NIR/MYD09GQ_b2_NIR_2012_261.tif"
Input file size is 4800, 48000...10...20...30...40...50...60...70...80...90...100 - done.
[Mon Feb 11 18:17:17 2019] Computing Aqua b2_NIR - b1_Red for date: 2012_09_17
[Mon Feb 11 18:17:45 2019] Creating Virtual Files and R time series for layer b2_NIR - b1_Red
[Mon Feb 11 18:17:45 2019] Creating Virtual Files and R time series for layer b2_NIR - b1_Red
[Mon Feb 11 18:17:45 2019] Creating Virtual Files and R time series for layer b2_NIR - b1_Red
[Mon Feb 11 18:17:45 2019] Total Processing Time: 4.06219533284505
[Mon Feb 11 18:17:45 2019] MODIStsp processed files are in: D:\Imagens\MODIS\MODIStsp
[Mon Feb 11 18:17:45 2019] Original downloaded MODIS HDF files are in: D:\Imagens\MODIS\MODIStsp
Warning messages:
1: package ‘gWidgetsRGtk2’ was built under R version 3.5.2
2: package ‘RGtk2’ was built under R version 3.5.2
3: package ‘gWidgets’ was built under R version 3.5.2
4: package ‘cairoDevice’ was built under R version 3.5.2

image

@maximomenezes
Copy link
Author

Hello Lorenzo.

The images are generated, however, mostly blank, as shown below.

Strangely, all images appear with maximum and minimum values equal: 30000 and - 30000.

image

@lbusett
Copy link
Contributor

lbusett commented Feb 12, 2019

Hi @maximomenezes ,

would you be able to save your processing options to json (using "save options" from the gui, and send me the file? (You can just save it, open it in a text editor and cut and paste the text here)

Lorenzo

@maximomenezes
Copy link
Author

Hello Lorenzo.

I'll check it again, but it looks like I've found a solution using the scale factor (* 0.0001).

I put the formula as follows (b2_NIR *0.0001)-(b1_Red *0.0001).

I tried the following and it did not work either:
(b2_NIR)-(b1_Red).

Once again thank you for the help and if you find a direct solution, be sure to let me know.

graciously

@maximomenezes
Copy link
Author

Hello Lorenzo.

Appearing the "Apply Scale / Offset" option also generates visible images using the following formula:

(b2_NIR) - (b1_Red)

However, the maximum and minimum values seem confusing, in addition to doubling the image size (90mb).

It seems the values are being nullified during the calculation and the use of these factors seems to avoid this.

If I find any other information, I will share it.

graciously

image

@maximomenezes
Copy link
Author

Hello Lorenzo.

See how the maximum and minimum values were.

If I find any other information, I will share it.

graciously

image

@lbusett
Copy link
Contributor

lbusett commented Feb 12, 2019

That's weird, but I may have a hunch.

two things:

  1. Can you please make two "new" runs, changing each time the "main MODIStsp output folder", and using first apply scale/offset to "No" and then to "Yes"? Then check the Red and NIR tiff files and look what values you get.

  2. Could you open a terminal (press the windows key, then write "cmd" and press enter) and run:

"C:\OSGeo4W64\bin\gdal_translate.exe" --version

and post the results?

PS: Regarding file size, you can limit it using the "compression" option

@maximomenezes
Copy link
Author

Hello Lorenzo.

The pixel values are not the same. See the figure below.

Thank you and I await information.

graciously

image

@lbusett
Copy link
Contributor

lbusett commented Feb 12, 2019

Are those result computed with "apply scale offset" to "yes" or to "no" ?

@lbusett
Copy link
Contributor

lbusett commented Feb 12, 2019

this is what I currently get on my machine:

image

with apply scale and offset on No and on Yes, respectively, so it appears to be identcal to arcgis (thankfully...). I suspect that this could be a GDAL version issue: are you able to run the

"C:\OSGeo4W64\bin\gdal_translate.exe" --version

command ? (you can also use the terminal from within RStudio, if you are using it)

image

@maximomenezes
Copy link
Author

Hello Lorenzo.

Going back on what I said in the last comment:

  • Although the maximum and minimum values are not the same. The pixels that I checked had the same value (image below), however, this was done by comparing the MODIStsp image that was multiplied by the scale factor (* 0.0001) with the ArcGIS image that was not multiplied by the scale factor.

I did not inspect all the pixels, but in theory, some of them should have different values (depending on the maximum and minimum values).

graciously

image

image

@lbusett
Copy link
Contributor

lbusett commented Feb 12, 2019

Concerning the min/max: I suspect those are not coming from the "full" image. In QGIS, if I do not modify it manually, they are computed from a subset to save time.

again in a terminal, can you try:

"C:\OSGeo4W64\bin\gdalinfo" "D:/Temp/t2/Surf_Ref_Daily_250m_v6/myind/MOD09GQ_myind_2017_122.tif"

(after changing the path in the second part to that where you saved the MODIStsp results)

and check the last lines? You should get something like:

  Metadata:
    STATISTICS_MAXIMUM=0.72719997167587
    STATISTICS_MEAN=0.1582325395491
    STATISTICS_MINIMUM=-0.10459999740124
    STATISTICS_STDDEV=0.082667738021847

(or the same, multiplied by 10000)

Could you do the same check on MODIStsp outputs created with the "normal" formula (b1_Red-b2_NIR), and with Apply scale offest on "No" and then on "Yes"? (Please make sure that you use new output folders each time, otherwise, if you do not set "Reprocess existing data" to "Yes", the ouputs will not be recomputed.

@maximomenezes
Copy link
Author

Hello Lorenzo.

The questions and answers were a little overlapping. While I was doing some tests you answered and asked a few more things. When I went to answer there were other questions.

Anyway, I did as you asked:

  • I have changed the output folders in each processing;
  • I performed the processing by ticking "no" and "yes" in the "ApplyScale / Offset" option.

Note that by checking "yes" the image is generated normally, however, the maximum and minimum values are the same as the image generated in ArcGis without having multiplied by the scale factor.

image

@lbusett
Copy link
Contributor

lbusett commented Feb 13, 2019

Hi Maximo. Yes, we were working concurrently so there was a bit of a mess. Sorry for that I think may have pinpointed the problem. It woul be however useful if you may be able to run the gdalinfo command u shared in my last on the file resulting from using apply scale offset = no.

@maximomenezes
Copy link
Author

Lorenzo ...

The gdal version is in the figure below.
image

The question of maximum and minimum values seems to me to be solved, according to the figure of my last answer (They are the same, however, one would be multiplied by 0.0001 and another not, so they should not have the same value).

Lorenzo ... these values suggest that in the internal script that performs the calculation (algebra) of the bands the scale factor seems to be being divided and not multiplied. When we mark "yes" in the "AppyScale / Offset" option it generates an image with the same values as an image generated by a simple subtraction in the ArcGis raster calculator.

When I perform the following calculation in arcgis:

image

it gives me an image similar to that generated in MODIStsp with the option "no" for "AppyScale / Offset". That is, most of the values are null and void and generate an image at zero and 1. It seems to me that the script is applying a division by the value 10000 unduly.

@maximomenezes
Copy link
Author

It seems to me that the script is applying a division for the value 10000 even though we did not select any option. When we mark "yes" in the scale factor, division and multiplication are canceled by generating a file with the value of simple subtraction.

@lbusett
Copy link
Contributor

lbusett commented Feb 13, 2019

Hi. I agree. And i think that is related to a breaking change in latest gdal versions, since on tests on my machine yesterday all seemed to be ok. I will be able to check maybe tomorrow. My interest in the min/max values for the no scale offset is in understanding which value you get in the image, besides the Minmax values (according to your last, you get 0 and 1, whch makes sense because in that case we save as integers).

Thanks for all your input! I'll keep you posted

@maximomenezes
Copy link
Author

Hello Lorenzo.

A partial solution is to check "yes" in the "AppyScale / Offset" option. This circumvents the script by nullifying the undue division.

And next to that, use the formula with the correction factor when adding the new index ((b2_NIR) - (b1_Red)) * 0.0001. With this I got the same values as the ArcGis Raster Calculator (see figure).

image

@lbusett
Copy link
Contributor

lbusett commented Feb 13, 2019

Thanks for the workaround. However, this is not expected bahaviour, so it will be fixed ASAP (I am updating my gdal now to 2.4, to see if i can replicate the problem).

@lbusett
Copy link
Contributor

lbusett commented Feb 13, 2019

Ok. I confirmed this is a GDAL version issue.

For future reference, this was most probably due to this change:

https://trac.osgeo.org/gdal/ticket/3221#comment:5

Working on a fix.

@lbusett lbusett self-assigned this Feb 13, 2019
@lbusett lbusett added bug Issues due to a code bug enhancement {MODIStsp} enhancements proposals labels Feb 13, 2019
@maximomenezes
Copy link
Author

Hello Lorenzo.

I am more of a user than a programmer. I do not know if I understood correctly, but the script or the gdal would be applying scale factor with wrong values or changed in the MODIS product bands.

Sorry if I'm being superficial, but internalizing a table (like this one below) would not prevent the program from making the wrong choice?
image
image

image

For example, when we choose an option in the "Category" menu it directs and limits the "product" option to the one we chose in the previous option. Can not do something similar with different scale factor? When choosing an option the script would already filter and direct to the respective scale factor.

Sorry if I misunderstood. My English is still basic.

Origin of information: http://modis-sr.ltdri.org/guide/MOD09_UserGuide_v1_3.pdf

@lbusett
Copy link
Contributor

lbusett commented Feb 14, 2019

@maximomenezes

This is what MODIStsp already does, and on systems with GDAL < 2.3.x it works well.

However, due to a recent change in the gdal_buildvrt function (which is used in MODIStsp), the scale factor is "caught" from HDF metadata and applied automatically, even when apply scale/offset is set to "No". To make things worse the scale factor in the metedata of reflectances in MODIS HDF files is reported a "10000" instead of 0.0001, leading to a disaster ( I know this is quite technical.....).

However, I now have a tentative fix for this. Could you please:

  1. Remove MODIStsp using remove.packages("MODIStsp")

  2. Reinstall from github using:

require(remotes)  
remotes::install_github("ropensci/MODIStsp", ref = "feature/fix_gdalvrtbug")

Let me know if it works.

@maximomenezes
Copy link
Author

Hello Lorenzo.

Failed to install one of the packages / dependencies, but it appears that the installation has completed.

I tested simple subtraction and generated a normal image!

Thank you so much for the help!

graciously

Máximo

@lbusett
Copy link
Contributor

lbusett commented Feb 15, 2019

Thanks to you for reporting! I will push the update also to CRAN as soon as possible.

@lbusett lbusett closed this as completed Feb 15, 2019
@maximomenezes
Copy link
Author

maximomenezes commented Feb 15, 2019 via email

@osamasajid123
Copy link

Hi Lorenzo,

I was having similar issue with the scaling as described by Máximo. I am following your comment in which you asked to remove modistsp and reinstall :

require(remotes)
remotes::install_github("ropensci/MODIStsp", ref = "feature/fix_gdalvrtbug")

After running the lines above, the R window gives the following options. Which one do I need to choose?

"
These packages have more recent versions available.
Which would you like to update?

1: R.utils (2.7.0 -> 2.8.0 ) [CRAN] 2: R6 (2.3.0 -> 2.4.0 ) [CRAN] 3: raster (2.6-7 -> 2.8-19) [CRAN]
4: rgdal (1.3-4 -> 1.3-6 ) [CRAN] 5: rgeos (0.3-28 -> 0.4-2 ) [CRAN] 6: stringi (1.1.7 -> 1.3.1 ) [CRAN]
7: stringr (1.3.1 -> 1.4.0 ) [CRAN] 8: zoo (1.8-3 -> 1.8-4 ) [CRAN] 9: CRAN packages only
10: All 11: None
Enter one or more numbers separated by spaces, or an empty line to cancel
1:

"

Thanks,
Osama

@lbusett
Copy link
Contributor

lbusett commented Feb 15, 2019

Hi @osamasajid123 ,

Unless you need to keep some older versions of a package, I'd suggest to select "All" (10). That way, you'll bring all packages up to current versions.

Lorenzo

@osamasajid123
Copy link

Hi Lorenzo,

I did what you said. Now when I try to open the interface by running MODIStsp(), I get the following error. Can you understand what is going wrong?

Warning in read.dcf(file.path(p, "DESCRIPTION"), c("Package", "Version")) :
cannot open compressed file 'C:/Users/osama/Documents/R/win-library/3.5/MODIStsp/DESCRIPTION', probable reason 'No such file or directory'
MODIStsp would like to save a "MODIStsp_Previous.json" file
containing information about its last successfull run in the folder
.../your-r-library/MODIStsp/ExtData/.

Do you authorize this?

1: Yes - "MODIStsp_Previous.json" will be saved permanently and updated after
after each successfull run of the tool. You will not see this message anymore.

2: No - Previous options will be written to tempdir and will be lost when you
exit R. You will see this message at each MODIStsp execution.

Choice (1/2): 1
GDAL version in use: 2.2.3
Warning in read.dcf(file.path(p, "DESCRIPTION"), c("Package", "Version")) :
cannot open compressed file 'C:/Users/osama/Documents/R/win-library/3.5/MODIStsp/DESCRIPTION', probable reason 'No such file or directory'
Warning in read.dcf(file.path(p, "DESCRIPTION"), c("Package", "Version")) :
cannot open compressed file 'C:/Users/osama/Documents/R/win-library/3.5/MODIStsp/DESCRIPTION', probable reason 'No such file or directory'
Warning in read.dcf(file.path(p, "DESCRIPTION"), c("Package", "Version")) :
cannot open compressed file 'C:/Users/osama/Documents/R/win-library/3.5/MODIStsp/DESCRIPTION', probable reason 'No such file or directory'
Reading the MODIS products' characteristics from XML. Please wait!
Error: '' does not exist in current working directory ('C:/OSU AEDE/MODIS/Surf_Ref_8Days_500m_v6/NDVI').

@lbusett
Copy link
Contributor

lbusett commented Feb 16, 2019

Strange. I'd try restarting r and trying install again on a fresh session.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues due to a code bug enhancement {MODIStsp} enhancements proposals
Projects
None yet
Development

No branches or pull requests

3 participants