Hatfield J.L., Gandini A. (eds.) Nitrogen in the Environment

Подождите немного. Документ загружается.

Developing Software for Livestock Manure and Nutrient Management in USA 527

expectations about incoming data. For example, a program may insist that all P data

be based on the Mehlich III method and in units of part per million. Soil test data

that were derived using a different extraction or in different units must be converted

to the expected standard before they can be imported. Alternatively, universal stand-

ards can be developed where the full range of possible data types are defined. In this

scenario, both data source and receiving program agree to use the predetermined

definitions. The program receiving data can use the standard to identify the type of

data provided and convert the incoming data to its own required format.

The Ag Electronics Association (AEA), a not-for-profit trade association

founded in 1995, has worked ambitiously to create some universal standards. The

AEA has developed two specifications pertinent to soil test data. The first is a data

dictionary for defining soil test data ( AEA, 1997 ). The second is a transfer specifi-

cation for exchanging soil test data ( AEA, 1998 ). These specifications are voluntary

guidelines; no one is required to use them. An informal survey of soil testing labs

conducted by two of this chapter ’ s authors in early 2000 did not find any labs that

were familiar with the AEA ’ s work. However, these specifications go a long way

toward setting an important standard for soil test data identification and exchange.

3.2.3 . Crop identification

In some states, numeric codes have been assigned to crops commonly grown

in those states. These codes are used to specify crops on soil testing laboratory sub-

mission forms and in generating extension fertilizer recommendations. While these

codes make for a state standard of sort, they do not make for a national one since

each state ’ s numbering system is different from the next. Without a universal way

of identifying crops, a different scheme for linking to national crop databases will

have to be worked out for each state.

3.2.4 . Soil identification

NRCS has developed the National Soil Information System (NASIS) as a cen-

tral repository for storing and working with soil survey data. This database sets an

important standard for identifying soils and describing soil attributes, but it does

not solve all problems. In some cases, where a survey area has been remapped or

renumbered, the NASIS database differs greatly from the published soil survey

in use today. Any data references to the published soil identifiers in remapped or

renumbered counties will be incompatible with NASIS.

Closely linked to NASIS is the NRCS Soil Survey Geographic Database

(SSURGO). SSURGO was designed for use by natural resource planners working

with GISs. NASIS has the ability to export a subset of its data as a SSURGO data

set. A SSURGO data set includes digitized versions of the original soil survey maps

and associated soil attribute data. A soil survey area typically consists of a single

county. Once digitized, a county ’ s SSURGO data is submitted to NRCS for certifi-

cation. By December 2000, SSURGO data for about one-third of US counties had

been certified.

CH16-P374347.indd 527CH16-P374347.indd 527 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

528 Nitrogen in the Environment

3.2.5 . Watershed identification

During the 1970s the US Geological Survey (USGS) mapped the US at the

subbasin drainage level, developing an 8-digit hydrologic unit code (HUC) to

identify each subbasin. An 8-digit HUC represents roughly 448,000 acres. In the

late 1970s, recognizing the inadequacy of 8-digit hydrologic units for local water

resource planning, NRCS began mapping subbasins into 11-digit watersheds

(40,000–250,000 acres) and then mapping these watersheds into 14-digit subwa-

tersheds (3,000–40,000 acres). By the early 1990s NRCS had decided to map and

digitize the entire U.S. at the 14-digit subwatershed level. The objective was to

develop a national GIS watershed database that matches USGS topographical maps.

By December 2000, NRCS had certified two states ’ 14-digit maps, with work in

progress in most other states.

3.2.6 . Crop planting and harvest units

In the US, units for seed, planting rates, and harvest yields vary from crop to

crop and even from state to state. For example, depending on the crop, seed can

be priced per pound, bushel, hundredweight, 80,000-seed bag, 100,000-seed bag,

or 50-pound bag. Planting rates are in seeds per acre, pounds per acre, or bushels

per acre, while yields are reported in pounds, bushels, hundredweight, or tons. The

USDA Census of Agriculture uses a standard set of units for crop yields, but in

some cases the census units differ from what producers commonly use.

3.3 . Data Acquisition Challenges

While the public databases mentioned above are indeed public, obtaining them

is not easy. For example, while any SSURGO county data set can be downloaded

from the NRCS SSURGO Web site, obtaining data sets for multiple counties this

way is slow and tedious. Developing software that can be used in more than one

state will require a special arrangement with the responsible agency to facilitate the

acquisition of necessary data. Furthermore, since most of these national databases

are works in progress, with sizeable gaps in the data, the software will also need to

be able to make do when the data for a county or state are not available.

In some cases, vital state-specific data may not be part of a national database.

For example, in Wisconsin, each soil in the state has been assigned a subsoil group

( Kelling et al., 1998 ). This subsoil group is used in generating extension fertilizer

recommendations, but is currently not one of the NASIS soil attributes. Attributes

like this will need to be merged with NASIS data on a state-by-state basis to be

used by planning software.

Acquiring GIS data can be particularly tricky. Not only is there the challenge of

locating and obtaining the right data, but working with and distributing very large

image files can be difficult. In addition, there are often numerous file and data for-

mats to choose from. Finally, in the case of digitized aerial photographs, the age

of the photograph can be important. If the photograph is too old, changes to farm

structures may not be present.

CH16-P374347.indd 528CH16-P374347.indd 528 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

Developing Software for Livestock Manure and Nutrient Management in USA 529

4 . OTHER CHALLENGES

4.1 . Inadequate Research to Support Process-Oriented Models

Process-oriented models must be based on and validated by directly measured

field data. At the present time, there is a lack of data for some of the basic pro-

cesses involving manure applications. For example, while the general concepts of

many nutrient transformations are well understood, actual field verification of nutri-

ent transformations and losses have not been widely measured within the context of

developing or testing transformation models.

4.2 . Limited Funding

In the survey of programs cited earlier, all of the programs appear to have

been developed by non-profit organizations, in most cases land grant universities.

Because programs like these are often closely associated with university research

and government agencies, personnel within those organizations traditionally have

developed the programs. This is not likely to change. The relatively small market

for nutrient planning software means that this kind of software will continue to be

developed by public organizations. As a result, these programs will be constrained

by funding; their existence and longevity will be directly related to success in grant

writing and the length of those grants.

4.3 . Finding Qualified Computer Personnel

In the past, students wrote much of the agricultural software produced by uni-

versities. However, students rarely possess much relevant programming experience

and usually move on after 2 or 3 years. This sometimes makes software develop-

ment success hard to achieve. Today ’ s users expect software that is easy to use, reli-

able and frequently updated. As with a lot of professional activities, the writing of

production code should probably be left to qualified professionals.

Even though today ’ s programming tools and environments are much more

advanced than just a few years ago, learning to use the new tools can be difficult. In

the current job market, finding programmers with the required experience and skills

may not be easy.

4.4 . Satisfying 50 States

Often one of the first questions a software developer is asked upon presenting

a new program to a diverse group is “ How can I use your program for my needs? ”

With agricultural software, if little thought was given to this possibility in the soft-

ware ’ s design, support for additional states or regions will have to be retrofitted to

the program. This can sometimes conflict with the original design or goals of the

program and delay its completion. However, designing a program from the begin-

ning to meet the potential needs of multiple states is challenging. Often each state

likes to think of itself as unique from all others, even though its farmers produce

many of the same crops under generally the same growing conditions as neighboring

states. Overcoming this challenge is less a technical problem than a political one.

CH16-P374347.indd 529CH16-P374347.indd 529 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

530 Nitrogen in the Environment

If planning software must account for state and local regulations, developers

will need links with each regulatory agency to stay apprised of changes in regula-

tory and reporting requirements.

4.5 . Technological Limitations

While most areas of the US can now connect to the Internet at relatively low

cost, much of rural America is limited to slow modem speeds and, barring some

technological breakthrough, will continue to be limited to slow modems for the

foreseeable future. This not only restricts the distribution of software and data via

the Internet, but more importantly limits the possibilities for on-line data entry,

retrieval, and reporting.

5 . WHAT SHOULD THIS NEW SOFTWARE LOOK LIKE?

Software that is national in scope, avoids the limitations of previous programs,

satisfies nutrient management planning ’ s data requirements, and overcomes the hur-

dles described above will not be easy or cheap to develop. What follows is a discus-

sion of the minimum set of features that this software should possess.

5.1 . Deals with Temporal Issues Visually

Manure can be added to storage facilities on a regular basis or only during

certain periods of the year. Manure can also be removed from storage for field

application at potentially any time of the year. A useful way of dealing with these

numerous manure “ transactions ” is a calendar that shows the status of all storage

facilities and fields at monthly intervals. A calendar is also a good way of showing

projected month-to-month fluctuations in manure accumulation.

Closely connected with the use of a calendar to display manure storage and

application status is the concept of “ live ” data handling. With live data handling,

each new or modified transaction forces all “ downstream ” cells of the calendar to

be updated automatically. For example, removing manure from a storage facility

not only reduces the amount of manure displayed for the facility, but also updates

its projected status for the remaining months of the calendar. Applying manure to a

field has a similar effect as well, increasing the number of the field ’ s acres that have

been manured and reducing the field ’ s nutrient requirements and manure applica-

tion priority in subsequent years.

5.2 . Deals with Spatial Issues Visually

Understanding the spatial relationships between a livestock operation ’ s geo-

graphic features is key to accounting for them properly in planning software. An

intuitive way of showing these relationships is to depict them on a multi-layered

map. This is best done with a GIS that allows various spatially referenced data lay-

ers to be overlaid on each other as needed by the user. These layers can consist of

digitized aerial photographs, soil survey, watershed and political boundaries, roads,

CH16-P374347.indd 530CH16-P374347.indd 530 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

Developing Software for Livestock Manure and Nutrient Management in USA 531

water bodies, user-drawn farm and field boundaries, and setbacks and buffers. One

recently developed GIS application, the Spatial Nutrient Management Planner

(SNMP), automatically determines field size, setbacks, spreadable acres, distance

from manure storage, soil type, watershed, and county for each field in an operation

and stores this data in a file for use in other programs ( Lory et al., 2000 ).

5.3 . Resolves Field Identification Problem

Planning software must be able to support more than one system of field iden-

tification. Obviously it has to support the producer ’ s own system of naming fields,

while also supporting a way of identifying portions of a larger field for manage-

ment purposes. One way of handling this is a three-level hierarchy of farm, field,

and subfield ID ’ s. In addition, the software needs to identify FSA farm/tract/field

ID ’ s for government program purposes, although it does not have to use these in its

primary system of field identification. Knowing the field ’ s 14-digit watershed and

the spatial coordinates of its boundaries would also be useful. A GIS can determine

these last two items.

5.4 . Maximizes Use of Publicly Available Databases

NRCS and other federal agencies have put a tremendous amount of work into

constructing a number of national databases. Wherever possible, planning software

should defer to standards set by these agencies rather than trying to develop new

ones. For the most part these databases are more than adequately documented,

although the amount of information present in these databases can be daunting. At

the same time, planning software needs to use local data such as state-specific soil

attributes as well.

5.5 . Generates State-Specific Fertilizer Recommendations for Multiple States

Traditionally, most programs that generate crop fertilizer recommendations

have embedded both the crop-specific logic and the recommendation data in the

program code. Even those programs that stored a portion of the data in an external

file embedded the logic of how to interpret the file ’ s structure and data in the program

code. While this approach may be adequate for individual states, it poses several

problems when trying to support multiple states: (i) changes to recommendations

usually require program changes, (ii) nearly everything about each state ’ s recom-

mendations must be known in advance, and (iii) knowledge of recommendation deci-

sions and changes tends to become lost over time if the program is the only source

for the recommendations.

A more general approach is to move much of the recommendation implementation

out of the program itself and into an external file in the form of expressions that can

be evaluated at runtime ( Hess, 1998 ). The recommendation expressions can be written

in any suitable scripting language and loaded and evaluated as needed during pro-

gram execution. Writing the recommendations as external expressions means that

a great deal of conditional logic can be moved out of the program into an external

CH16-P374347.indd 531CH16-P374347.indd 531 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

532 Nitrogen in the Environment

form that is easier to access, document, modify, and maintain. This approach also

allows outside parties to verify the resulting recommendations. In addition, since

the recommendation expressions can be as general as the scripting language they

are written in, a well-designed implementation will be able to handle a wide range

of future demands.

5.6 . Estimates N Availability Based on N Transformations

Using a single factor for estimating N loss ignores temporal, soil, management,

and climate variables. With only a single factor, manure applied in September will

have the same N loss estimate as manure applied in December. A process-oriented

approach models the N transformations that take place between the time the manure

is applied and the time that the crop needs the manure ’ s N. This is the approach

taken in an N transformation model developed for Ohio, Indiana, and Michigan

( Johnson, 1999 ). Purdue University ’ s Manure Management Planner (MMP) program

implements this model, modifying it to take into account other factors and general-

izing it for use in additional states ( Joern and Hess, 2000 ). The steps in MMP ’ s

algorithm are as follows.

1. Determine manure ’ s ammonium N. (Based on estimated or measured analysis.)

2. Determine manure ’ s organic N. (Based on estimated or measured analysis.

With poultry manure, treat portion of organic N as ammonium N to account

for readily mineralizable uric acid.)

3. Determine amount of organic N that can be mineralized in first year. (Based

on estimates for various manure types.)

4. Determine amount of ammonium N lost due to volatilization during appli-

cation. (Based on temperature at application.)

5. Determine amount of ammonium N lost due to volatilization during first

month following application. (Based on application method, high tempera-

ture following application, application rate, and amount of water in manure.)

6. Calculate amount of ammonium N remaining at end of application month.

(Subtract total volatilized N (steps 4 and 5) from step 1 ’ s total ammonium N.)

7. Determine amount of organic N converted to ammonium N during appli-

cation month. (Based on month ’ s temperature. Reduce organic N by this

amount and increase ammonium N by this amount.)

8. Determine amount of ammonium N converted to nitrate N (nitrification)

during application month. (Based on month ’ s temperature. Reduce ammo-

nium N by this amount and increase nitrate N by this amount.)

9. Determine amount of nitrate N lost due to denitrification during application

month. (Based on month ’ s temperature, soil type, and number of days soil

is continuously saturated with water. Reduce nitrate N by this amount.)

10. Determine amount of nitrate N lost due to leaching during application

month. (Based on month ’ s temperature and time since application. Reduce

nitrate N by this amount.)

CH16-P374347.indd 532CH16-P374347.indd 532 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

Developing Software for Livestock Manure and Nutrient Management in USA 533

11. Repeat steps 7–10 for each month until N is needed by crop.

12. Sum the remaining ammonium N and nitrate N. This is the N available to crop.

For strategic planning, estimated manure analyses and long-term temperature

and rainfall data must be used since actual data will not yet be known. For tacti-

cal planning, actual manure analyses and weather data can be used. The transfor-

mation factors used in each step of the algorithm can be adjusted for each state as

necessary.

Figure 1 shows the results of running MMP ’ s N transformation model with var-

ious hypothetical manure applications. Note the importance of application timing to

total N loss.

5.7 . Open Architecture

The term “ open ” can have several meanings when applied to computer soft-

ware, but in the context of agricultural software it usually means the ability to

import and export data in popular file formats. This definition needs to be expanded

Figure 1 . Percent N remaining after applying 6,000 gallons/acre liquid pig manure

(15,000 gallons/acre lagoon effluent for irrigation) at various months of application

in northern Indiana using MMP ’ s N transformation model ( Bailey and Joern, 2000 ).

100

Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun

Month of application

Percent available N remaining

(on June 30)

Injected

Broadcast, incorporated

Irrigated

Broadcast, surface

CH16-P374347.indd 533CH16-P374347.indd 533 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

534 Nitrogen in the Environment

to include other types of access, including program-to-program links and facilities

for enhancing and customizing the software by users.

5.7.1 . Imports and exports data in multiple formats

Traditionally, programs have linked to each other by importing and export-

ing data via external files. By supporting various standard file formats, data can be

extracted from one program ’ s usually proprietary format and used in another pro-

gram. By working through a neutral format, neither program needs to know very

much about the other program. Unfortunately, importing and exporting is not the

same as merging data or exchanging data dynamically. Neither do these capabili-

ties address the problem of data identification, only the physical exchange of data.

Efforts like those of the AEA can help by establishing a standard way of identifying

and exchanging soil test data via a Transfer Support Layer (TSL) file created for

each data source. However, creating a TSL is not a trivial task and will probably

require software developers to work closely with soil testing laboratories to create

each TSL. A similar effort to establish standard ways of identifying crops would be

helpful. For example, a four-level hierarchy for identifying crops by genus, species,

use, and cultivar could be one approach.

5.7.2 . Supports modern computer technologies

A smoother way of linking programs is to utilize newer software technologies.

One of these is Microsoft ’ s Component Object Model (COM), which is built into

all of its Windows operating systems beginning with Windows 95. COM supports

a mechanism called Automation, which permits one program to operate another

program remotely without user activity. The program being manipulated is the

Automation “ server ” and the program doing the manipulation is the Automation

“ client. ” Programs can be both a client and a server. Automation offers a number of

advantages over previous technologies such as Dynamic Link Libraries (DLL). To

start, the language used to develop an Automation client or server is not relevant,

as the COM specification is language independent. This permits developers greater

latitude in their choice of development tool. In addition, an Automation server can

be largely self-documenting.

Automation also permits more than just data interchange. Any capability of a

program can be made available to other programs. This allows complex systems to

be built in a modular fashion and allows programs to take advantage of the unique

computational abilities of other programs. For example, the previously cited GIS

application, SNMP, can utilize Automation to exchange non-spatial data and ferti-

lizer recommendations with Purdue ’ s MMP software ( Joern et al., 2000 ). Publicly

funded agricultural software should support Automation both as client and server to

make its data and algorithms as widely available as possible.

5.7.3 . Add-in facility

For planning software to be widely adopted, it needs a way to be customized

and enhanced by third parties. One way of doing this is to provide a facility for

CH16-P374347.indd 534CH16-P374347.indd 534 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

Developing Software for Livestock Manure and Nutrient Management in USA 535

adding components developed by others. Most modern software has this capability.

For example, word processors support document templates, browsers support helper

applications for viewing foreign file formats, and so on. With planning software,

specialized reports are necessary. Typically, these reports use the program ’ s data

but are developed with commercial database and reporting software. If the planning

software has a way of adding in these reports, they will appear to the user as an

integrated part of the program.

5.7.4 . Permits state-specific customization

In addition to specialized reports, planning software will need to be custom-

ized for use in other states with minimal program changes and without forking into

multiple versions of the program. One way to help with this problem is to place all

program data that could vary from state to state into external files. This not only

provides a common way of customizing the program, allowing state-specific files to

“ drive ” the program, but also places data where others can view and verify the values.

5.7.5 . Technical documentation

To realize the goals outlined above, planning software will need documentation

not only for the user (a given), but also for other developers. To make it as publicly

available as possible, this technical documentation should be posted on a Web site

and updated regularly as the program progresses.

6 . FUTURE DIRECTIONS

Developing software that models natural processes is an ever-changing land-

scape. Assumptions made today about hardware, software, methodology, data, or

users may not be true tomorrow or may become irrelevant in light of technological

developments. However, it is clear that software will continue to be asked to do

more and more. Software will need to be more open, more flexible and custom-

izable, and easier to use. Several areas where these needs could be addressed are

described below.

6.1 . Linking Private and Public Software

Privately developed software is available for practically every commercial

aspect of agriculture, including software that manages and analyzes site-specific

data and documents farm activities such as pesticide applications, equipment depre-

ciation, tax form filing, and bookkeeping. In addition, a great deal of publicly

developed software that incorporates research done by universities and government

agencies is also available, including software that estimates soil loss, schedules irri-

gation, creates conservation plans, and helps agency personnel keep track of farmer

clients. Much of the information entered about an operation or activity in one of

these programs could potentially be used in other programs. As more and more

aspects of agriculture become measurable, the amount of data generated by each

CH16-P374347.indd 535CH16-P374347.indd 535 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM

536 Nitrogen in the Environment

operation will increase. Exchanging data between various programs needs to be

dynamic and simple to do, if not completely transparent to the user. Furthermore,

to avoid duplication of programming effort, programs need to be able to utilize each

other ’ s computational abilities.

6.2 . Utilizing the Internet to Distribute Software and Data

A great deal of software and data are already distributed via the Internet, either

by manual downloads or, in some cases, automatic updates. More and more soft-

ware will undoubtedly gain the ability to update itself automatically. How much

software will eventually be run over the Internet as Java™ or other programs

remains to be seen. Faced with the age-old problems of software compatibility and

distribution, many developers embraced the Internet as a way of avoiding these

problems, only to discover that Web-based software presented its own set of new

problems involving bandwidth, security, privacy, and data ownership.

Another area where new possibilities exist is for software to assist the user

in locating the increasing amounts of publicly available on-line data. Rather than

requiring that each user hunt for necessary data more or less manually, software that

knows where to look for the data could simplify the search process.

6.3 . Emergence of GIS as a True End-User Management Tool

Until recently, GIS was limited by its considerable hardware and data require-

ments. Many of these limitations have eased or will disappear as the digitizing and

mapping efforts now underway are completed and the resulting data are made avail-

able in more compact and selective forms. The world of commercial GIS software is

also changing, with more modern and standard programming tools becoming avail-

able. These changes will allow GIS to become a ubiquitous tool for visually manag-

ing many types of agricultural data and supplant the traditional row-by-column way

of presenting agricultural data to the user.

The marriage of GIS and the Internet appears to be a natural match. Few users

require more than a tiny fraction of publicly available GIS data. Yet packaging data

to be used by a large group requires that most of this GIS data be included. Why

not provide GIS data on an as-needed basis via the Internet? For example, a farmer

or consultant could locate a farm on a Web-based map server. The server then pack-

ages all relevant data for downloading. To keep the amount of download data to a

minimum, bulky layers such as digitized aerial photographs can be clipped to the

farm boundaries.

Another approach would be a Web-based GIS that supports many of the nutrient

management tasks performed by today ’ s standalone software. With this approach,

all GIS data would remain on the server.

6.4 . Modeling of Nutrient Loss Potential on a Site-Specific Basis

As the impacts of land use on nutrient and sediment loss potential become more

quantifiable, new software that can estimate the effects of management on these

CH16-P374347.indd 536CH16-P374347.indd 536 5/31/2008 6:21:26 PM5/31/2008 6:21:26 PM