What is a prescription file, and how does a rate controller read it?

A prescription file is just a map with a rate attached to it. Strip away the GIS talk and that's the whole idea: polygons drawn over a field, each one carrying a number that tells the controller what rate to run while the machine is inside that boundary.

Where it gets confusing is the file format, because there are two that show up constantly in a retailer's workflow, and they don't behave the same way once they hit the cab.

Shapefile prescriptions, the simple version

A shapefile prescription is a set of files, usually a .shp, .shx, and .dbf bundled together, where the .dbf holds an attribute table. One column in that table is the rate: seeds per acre, gallons per acre, pounds of product, whatever the applicator is running. Each polygon in the shapefile ties back to one row in that table.

Most sprayer and spreader controllers read this format natively. Ag Leader InCommand, Raven Viper, older Deere GreenStar displays, all of them can pull in a zone shapefile as long as the rate column is named something the display expects, or you map it manually on import. The catch is that "zone shapefile" isn't one standard. Some software wants the column labeled Rate, some wants TargetRate, and a mismatch there is the single most common reason a grower calls back saying the controller "didn't do anything" on pass one.

ISOXML, the format everyone's moving toward

ISOXML (built on the ISO 11783 standard, which is why guys just call it ISO-XML or "the ISO file") is a different animal. Instead of one flat shapefile, it's a folder, typically TASKDATA, containing a TASKDATA.XML file plus grid files that hold the rate data cell by cell. That XML also carries client, farm, and field metadata, product definitions, and in planters, separate rate maps for hybrid or population splits running side by side.

Case IH AFS, New Holland IntelliView, and current-generation Deere Operations Center workflows all lean on ISOXML now, mainly because it can carry more than one product's worth of instructions in a single export. A split-rate seed and starter fertilizer script is a lot cleaner as one ISOXML task than as two shapefiles the operator has to load separately.

How the controller turns a zone into a rate change

Once the file's loaded, the controller is just matching GPS position against the zone boundary. Cross a line, switch to the rate tied to that polygon. The part that actually trips people up is lag: the controller has to account for the distance between the GPS antenna and where product leaves the machine, so there's a look-ahead setting (sometimes called application delay or implement offset) that fires the rate change a little early. Set that wrong and the zone boundary on the as-applied map shows up staggered several feet from where it should be, every time.

Projection matters too. If the prescription was built in one coordinate system and the display's running another, zones can shift just enough to clip the wrong strip, especially on long narrow fields where a few feet of drift crosses a boundary.

Where the as-applied map comes back in

After the pass, the controller logs the rate it ran, second by second, GPS-stamped. That log becomes the as-applied map, and it's the thing you check against the original prescription to confirm the equipment did what the file told it to do. Any gap between prescribed and as-applied, whether it's lag, an operator override, or a bad rate column, shows up there first.

That whole loop, from imagery to a usable zone file to the controller honoring it, is the part we built Field Variability around: a per-zone script generated from the season's biomass and vigor passes, exported in the format your display already reads.

If you're scripting rates off last year's soil grid and nothing newer, it might be worth seeing what a current-season zone layer looks like first.