ISOXML vs shapefile: which format does your rate controller want?

If you've ever built a zone map in the office and then watched a rate controller choke on it in the cab, you already know the format matters as much as the zones themselves. Two formats show up in almost every variable-rate workflow: the shapefile and ISOXML. They're not interchangeable, and picking wrong costs you a trip back to the shop with a laptop.

What each format carries

A shapefile is a bundle of files, usually four: .shp for the geometry, .dbf for the attribute table (your rate values), .shx for the index, and .prj for the coordinate system. Most rate controllers only need the .shp and .dbf to read a zone map, but drop the .prj and you risk the whole prescription loading offset from the field boundary by a few rows, or worse, on the wrong field entirely if two clients' farms sit close together.

ISOXML is a different animal. It's the ISO 11783 task-file standard, built around a TASKDATA.XML file plus supporting shape data, and it was designed for machines, not GIS software. It can carry more than one product rate in a single task (seed and starter fertilizer together, for instance), it logs what the controller actually applied versus what the prescription said, and it handles multi-section control and boom width data that a plain shapefile has no field for.

A shapefile is a map. ISOXML is a task, with the application log built in.

Which controllers want which

Older single-product rate controllers, and a fair number of yield monitors doing on-the-go population control, still read shapefiles fine. If your customer's planter display only wants one rate column and you're not tracking as-applied data back out of the cab, a clean shapefile with the right projection and a correctly named rate column does the job.

ISOBUS-compliant terminals, and most precision ag displays built in the last several years, expect ISOXML, especially if you're loading the job through a cloud platform like Operations Center rather than a thumb drive. Upload a shapefile to a system expecting a TASKDATA structure and it either rejects the file outright or converts it on the fly, which is where a lot of attribute-naming problems sneak in. If the controller reads "Rate" but your table says "TargetRate" or "Seed_Rate," the import can silently default to a flat rate instead of throwing an error you'd notice.

The failure mode that burns the most hours is the file that loads without complaint and plants flat anyway, because the column name didn't match what the controller template expected.

A few things worth checking before you export

Match the projection to what the display expects, not just what your GIS software defaults to. Most zone work in the Midwest and Plains ends up in a state plane or UTM zone, but older monitors can still want geographic coordinates. Check the manual, not the assumption.

Keep rate column names boring and consistent across every file you hand a grower. If your shop standard is "RxRate," use it every time, for every crop, every controller, every year. The controller doesn't care what's semantically correct. It cares what string it's told to look for.

If you're exporting multi-product scripts (seed plus a starter, or seed plus a fungicide pass later), check whether the target controller supports multi-product ISOXML tasks before you build the file that way. Some older ISOBUS implementations claim compliance but only read the first product in the task and ignore the rest.

Test the file on a desktop viewer that reads both formats before it goes to the cab. Catching a dropped .prj or a mismatched column name at your desk costs five minutes. Catching it at the field edge costs the morning.

Field Variability builds the per-zone rate file from the season's biomass and vigor passes so the script is ready for the controller format your grower's already running: see how the prescription export works.