getPackage() function not compatible with stackByTable()

[danielshulee]

The zip files downloaded from getPackage() are not compatible with stackByTable(). It seems very odd to me that these two functions cannot be used in sync with each other, while zipsByProduct() and stackByTable() can be used together. For example, I used getPackage() to get 2D wind speed and direction (dpID = DP1.00001.001) in ABBY during the month '2018-01'. I then went on the NEON data browser and downloaded the exact same dataset manually, specifying ABBY between January 2018 to January 2018, and then dragging the downloads to my desktop. When I manually open both zip files, I can see that the folders they create have the exact same datasets. However, on the original zip files, I can only use stackByTable() on the one manually downloaded, while stackByTable on the one downloaded by getPackage() returns Error in stackDataFiles(savepath): No data files are present in specified file path. I'm not sure whether this is an actual issue or something being worked on right now, but I think it would be very important for the two to be compatible since the whole goal of this package is to make it easier for users to pull NEON data in a form that is understandable.

Specifically in my case, I am making an R Shiny app that allows users to easily pull NEON data in app without having to manually download on the NEON website. A first step allows the user to get data either through getPackage() or zipsByProduct(), and then a second step would allow the user to "Unzip/Join Downloads", using stackByTable under the hood. However, at the moment stackByTable() doesn't work on files obtained by getPackage(), so I will have to recommend the user to manually download instead. Hopefully, in the future, these functionalities will be linked :). Thanks!

[cklunch]

@Danielslee51 We'll look into this, thanks for the heads up! zipsByProduct() and getPackage() were designed with different uses in mind - since getPackage() only downloads a single month for a single location at a time, we weren't necessarily thinking people would pass along data from it to stackByTable(). But you're right that for the sensor data, people may want to use stackByTable() to stack the tower level files within a single month.

You're also correct that it should be working regardless, and I'm not sure why it isn't. We'll get back to you!

[cklunch]

OK, we've determined that this is happening because of the way the folder structure is handled. Downloading a single zip file, as in getPackage(), results in a slightly different folder structure than downloading from the Portal or from zipsByProduct().

I'll keep this on our list of package improvements, but since getPackage() wasn't intended for file-stacking purposes, it's not a high priority for us. In the meantime, I would recommend sticking with zipsByProduct() for your app. Thanks!

[danielshulee]

Thank you for the response. I figured how to get around this. While stackByTable(zipfile) didn't work, if I simply place that zip file inside of a folder I can use stackByTable(directorywithzip, folder = TRUE), it returns a stackedFiles folder inside with everything unzipped, making it kinda of like how the zipByProduct() function works except you have to put it inside the folder yourself. Since this isn't high priority anyways, I'm guessing this is enough a solution, so hopefully it can be shared with other people so that noone else has troubles.