There is some interesting work going on currently in relation to risk management in the agriculture space as it relates to 'big data.'
"Agriculture risk management is about having access to ‘big data’ since growth conditions, risk types, climate and insurance terms vary largely in space. Solid crop models are based on large databases including simulated weather patterns with tempo-spatial correlations, crop planting areas, soil types, irrigation application, fertiliser use, crop rotation and planting calendars. … Similarly, livestock data need to include livestock densities which drive diseases, disease spread vectors and government contingency plans to address outbreaks of highly contagious diseases…Ultimately, big data initiatives will support selling agriculture insurance policies via smart phones based on highly sophisticated indices and will make agriculture insurance and risk management rapidly scalable and accessible to a large majority of those mostly affected – the farmers." - from The Actuary, March 2015
Similarly, in another issue of The Actuary there is more discussion related to this:
"In more recent years IBI (Indemnity Based Insurance) has received a renewed interest, largely drivenby advances in infrastructure (i.e., weather stations), technology (i.e., remote sensing
and satellites), as well as computing power, which has enabled the development of new statistical and mathematical models. With an IBI contract, indemnities are paid based on some index level, which is highly correlated to actual losses. Possible indices include rainfall, yields, or vegetation levels measured by satellites. When an index exceeds a certain predetermined threshold, farmers receive a fast, efficient payout, in some cases delivered via mobile phones. "
The article notes several benefits related to IBI products, including decreased moral hazard and adverse selection as well as the ability to transfer risk. However some challenges were noted related to 'basis' risk, where the index used to determine payments may not be directly linked to actual losses. In such cases, a farmer may recieve a payment when no loss is realized, or may actually experience loss but the index values don't trigger a payment. The farmer is left feeling like they have paid for something without benefit in the latter case. The article discusses three types of basis risk; variable, spatial, and temporal. Variable risk occurs when other unmeasured factors impact a peril not captured by the index. Maybe its wind speed during pollination or some undocumented pest damage or something vs measured items like temperature or humidity. An example of spatial risk might be related to cases where index data may be data generated from meteorological stations too far from the field location to accurately trigger payments for perils related to rain or temperature. Temporal risk is really interesting to me in terms of the potential for big data:
"The temporal component of the basis risk is related to the fact that the sensitivity of yield to the insured peril often varies over the crops’ stages of growth. Factors such as changes in planting dates, where planting decisions are made based on the onset of rains, for example, can have a substantial impact on correlation as they can shift critical growth stages, which then do not align with the critical periods of risk assumed when the crop insurance product was designed."
It would seem to me that the kinds of data elements being capture by services offered by companies like Climate Corp, Farmlink, John Deere etc. in combination of other aps (drones/smartphones/other modes of censoring/data collection) might be informative to creating and monitoring the performance of better indexes to help mitigate the basis risk associated with IBI related products.
References:
New frontiers in agricultural insurance . The Actuary. March 2015. DR AUGUSTE BOISSONNADE
http://www.theactuary.com/features/2015/03/new-frontiers-in-agriculture/
AGRICULTURAL INSURANCE— MORE ROOM TO GROW? The Actuary- May 2015.
Lysa Porth and Ken Seng Tan
See also:
Copula Based Agricultural Risk Models
An attempt to make sense of econometrics, biostatistics, machine learning, experimental design, bioinformatics, ....
Wednesday, August 12, 2015
Copula Based Agricultural Risk Models
I have written previously about copulas, with some very elementary examples (see here and here). Below are some papers I have added to my reading list with applications in agricultural risk management. I'll likely followup in the future with some annotation/review.
Zimmer, D. M. (2015), Crop price comovements during extreme market downturns. Australian Journal of Agricultural and Resource Economics. doi: 10.1111/1467-8489.12119
Energy prices and agricultural commodity prices: Testing correlation using copulas method
Krishna H Koirala, Ashok K Mishra, Jeremy M D 'antoni, Joey E Mehlhorn
Energy 01/2015; DOI:10.1016/j.energy.2014.12.055 ·
Xiaoguang Feng, Dermot J. Hayes
Diversifying Systemic Risk in Agriculture: A Copula-based Approach
Mixed-Copula Based Extreme Dependence Analysis: A Case Study of Food and Energy Price Comovements
Feng Qiu and Jieyuan Zhao
Selected Paper prepared for presentation at the Agricultural & Applied Economics Association’s 2014 AAEA Annual Meeting, Minneapolis, MN, July 27-29, 2014.
Price asymmetry between different pork cuts in the USA: a copula approach
Panagiotou and Stavrakoudis Agricultural and Food Economics (2015) 3:6
DOI 10.1186/s40100-015-0029-2
Copula-Based Models of Systemic Risk in U.S. Agriculture: Implications for Crop Insurance and
Reinsurance Contracts Barry K. Goodwin
October 22, 2012
Zimmer, D. M. (2015), Crop price comovements during extreme market downturns. Australian Journal of Agricultural and Resource Economics. doi: 10.1111/1467-8489.12119
Energy prices and agricultural commodity prices: Testing correlation using copulas method
Krishna H Koirala, Ashok K Mishra, Jeremy M D 'antoni, Joey E Mehlhorn
Energy 01/2015; DOI:10.1016/j.energy.2014.12.055 ·
Xiaoguang Feng, Dermot J. Hayes
Diversifying Systemic Risk in Agriculture: A Copula-based Approach
Mixed-Copula Based Extreme Dependence Analysis: A Case Study of Food and Energy Price Comovements
Feng Qiu and Jieyuan Zhao
Selected Paper prepared for presentation at the Agricultural & Applied Economics Association’s 2014 AAEA Annual Meeting, Minneapolis, MN, July 27-29, 2014.
Price asymmetry between different pork cuts in the USA: a copula approach
Panagiotou and Stavrakoudis Agricultural and Food Economics (2015) 3:6
DOI 10.1186/s40100-015-0029-2
Copula-Based Models of Systemic Risk in U.S. Agriculture: Implications for Crop Insurance and
Reinsurance Contracts Barry K. Goodwin
October 22, 2012
Friday, August 7, 2015
Data Cleaning
I previously wrote about the importance of hacking skills for economics researchers and said that it may be one of the most important econometrics lessons you never learned.
In one of his regular 'metrics Monday posts, Marc Bellemare recently wrote about data cleaning. He made a lot of great points and this really stands out to me:
"So what I suggest–and what I try to do myself–is to write a .do file that begins by loading raw data files (i.e., Excel or ASCII files) in memory, merges and appends them with one another, and which documents every data-cleaning decision via embedded comments (in Stata, those comments are lines that begin with an asterisk) so as to allow others to see what assumptions have been made and when. This is like writing a chemistry lab report which another chemist could use to replicate your work.
Lastly, another thing I did when I first cleaned data was to “replicate” my own data cleaning: When I had received all the files for my dissertation data in 2004, the data were spread across a dozen spreadsheets. I first merged and cleaned them and did about a month’s worth of empirical work with the data. I then decided to re-merge and re-clean everything from scratch just to make sure I had done everything right the first time."
The ability to document everything you do with the data, and ensure repeatability and accuracy is priceless! I somehow get the feeling that this is not something that is practiced religiously in a lot of spaces, and makes me cringe every time a hear about results from a ‘study.’ But in the corporate space where I work, this makes collaboration with other groups and teams go a lot smoother if everyone can get back to the same starting point when it comes to processing the data. This is especially helpful when pulling it together from a myriad of servers and non-traditional data sources and formats that characterize today's big data challenges. And in the academic space, just think about the Quarterly Journal of Political Science's requirements related to providing a replication package with article submissions. Sometimes this sort of 'janitor' work can constitute up to 80% of a data scientist's workload, but its well worth the effort if done appropriately. Good documentation throughout the process adds to the workload, but pays dividends.
See also:
In God we trust, all others show me your code.
Data Science, 10% inspiration, 90% perspiration
In one of his regular 'metrics Monday posts, Marc Bellemare recently wrote about data cleaning. He made a lot of great points and this really stands out to me:
"So what I suggest–and what I try to do myself–is to write a .do file that begins by loading raw data files (i.e., Excel or ASCII files) in memory, merges and appends them with one another, and which documents every data-cleaning decision via embedded comments (in Stata, those comments are lines that begin with an asterisk) so as to allow others to see what assumptions have been made and when. This is like writing a chemistry lab report which another chemist could use to replicate your work.
Lastly, another thing I did when I first cleaned data was to “replicate” my own data cleaning: When I had received all the files for my dissertation data in 2004, the data were spread across a dozen spreadsheets. I first merged and cleaned them and did about a month’s worth of empirical work with the data. I then decided to re-merge and re-clean everything from scratch just to make sure I had done everything right the first time."
The ability to document everything you do with the data, and ensure repeatability and accuracy is priceless! I somehow get the feeling that this is not something that is practiced religiously in a lot of spaces, and makes me cringe every time a hear about results from a ‘study.’ But in the corporate space where I work, this makes collaboration with other groups and teams go a lot smoother if everyone can get back to the same starting point when it comes to processing the data. This is especially helpful when pulling it together from a myriad of servers and non-traditional data sources and formats that characterize today's big data challenges. And in the academic space, just think about the Quarterly Journal of Political Science's requirements related to providing a replication package with article submissions. Sometimes this sort of 'janitor' work can constitute up to 80% of a data scientist's workload, but its well worth the effort if done appropriately. Good documentation throughout the process adds to the workload, but pays dividends.
See also:
In God we trust, all others show me your code.
Data Science, 10% inspiration, 90% perspiration
Subscribe to:
Posts (Atom)