Soil file output error about translator-dssat HOT 5 CLOSED

The reason for this issue is that when resolve the issue of overwriting file, I add append function for soil and weather file, but forget to change to use soil_id as the key of soil files in the map, while originally I use file name as the key. As a result, for soil file, it becomes to allow to write site info only once. It cause the following data lost.
In addition, I also check the weather side and find another issue that, if multiple experiment use same weather station's data but the duration are discontinuous, like one use UFGA8401, and another use UFGA8601, I will put them together in one weather site data. Will API be able to divide them and send them in separated site record?

from translator-dssat.

Yes, the API is designed to handle this.

On Tuesday, November 6, 2012 at 3:02 PM, MengZhang wrote:

The reason for this issue is that when resolve the issue of overwriting file, I add append function for soil and weather file, but forget to change to use soil_id as the key of soil files in the map, while originally I use file name as the key. As a result, for soil file, it becomes to allow to write site info only once. It cause the following data lost.
In addition, I also check the weather side and find another issue that, if multiple experiment use same weather station's data but the duration are discontinuous, like one use UFGA8401, and another use UFGA8601, I will put them together in one weather site data. Will API be able to divide them and send them in separated site record?

—
Reply to this email directly or view it on GitHub (#27 (comment)).

from translator-dssat.

In addition, if the weather daily data between years is not always in ascending order, will it become an issue for API?
Like 19850101 ... 19851231, 19840101 ... 19841231, 19860101 ... 19861231

from translator-dssat.

I'll test to make sure, but I believe I search by year anyways.

On Tuesday, November 6, 2012 at 3:31 PM, MengZhang wrote:

In addition, if the weather daily data between years is not always in ascending order, will it become an issue for API?
Like 19850101 ... 19851231, 19840101 ... 19841231, 19860101 ... 19861231

—
Reply to this email directly or view it on GitHub (#27 (comment)).

from translator-dssat.

OK. If it becomes an issue, I can add a sort handling for daily array.

from translator-dssat.