September 30, 2026
Getting Field Boundaries and Prescription Files to a Drone Operator
The file handoff is where a variable-rate job most often stalls, and almost never because the map was wrong. It is a missing projection file, a boundary drawn around the wrong quarter, or rate units nobody agreed on. Here is what to send, in what format, and how to check it before the aircraft is booked.
What It Is
Before a drone can fly a variable-rate granular pass on your field, two pieces of data have to move from wherever they live now onto the aircraft: the field boundary, which says where the work happens, and the prescription, which says how much product goes where inside it.
That transfer sounds like a formality. In practice it is the step that most often delays a booked job, and the reason is rarely that the agronomy was wrong. It is that a shapefile arrived without the piece that declares its coordinate system, or the boundary came from a land title rather than from the farmed edge, or the rates were in pounds per acre and the file was read as kilograms per hectare.
None of those are hard problems. All of them are much cheaper to catch the week before than on the morning the truck is loaded. This is the list of what to send and how to check it.
If you are still deciding whether a variable-rate pass is the right call at all, the variable-rate granular guide covers that question. This one assumes the decision is made and the files need to move.
Who It's For
Anyone hiring a drone pass that follows a map rather than a flat rate.
That covers growers whose agronomist already builds prescriptions in an agronomy platform, farms with boundaries sitting in a farm management program or a yield monitor, and operations where a retail agronomy service holds the zone data. It also covers the case where nobody has a usable boundary yet, which is more common than it sounds and is fixable.
If your field is genuinely uniform and the pass is one rate across the whole thing, you do not need a prescription at all. A flat rate is the correct answer on even ground, and a clean boundary is the only file that matters. Skip to the boundary section.
It is worth reading from the other side too. If you are the agronomist or retail agrologist exporting the file, the checks below are the ones that determine whether your prescription is flown as you intended or bounced back for a rebuild.
How It Works
Start with the boundary, because everything else is measured against it. The boundary is a closed polygon around the ground to be treated. Every acre count, every zone area, and every coverage record downstream inherits whatever the boundary says, so an error here propagates through the entire job including the invoice.
A boundary that works is one that matches the farmed edge rather than the legal edge. Those are different lines. A quarter section title includes the road allowance, the yard site, the bush along the creek, and the slough that has been wet for four years. A drone flying the title boundary treats all of it, which wastes product on ground that grows nothing and inflates the acres you are billed for. The quote article covers how boundary acres and treated acres diverge; this is where that gap is created.
Where a usable boundary usually already exists:
- The yield monitor or guidance display. Fields recorded over past seasons are already drawn to the farmed edge, because that is where the machine went.
- A farm management or agronomy platform. Most export field boundaries directly, often as shapefile or GeoJSON.
- A previous soil sampling or mapping job. If someone has zone-sampled the field, a boundary exists.
- Nothing yet. Then a boundary gets drawn, either from imagery or from a mapping flight. That is a small job, not a blocker, and it only has to happen once per field.
Then the prescription, which is a boundary with instructions. A prescription map is the field divided into zones, each zone carrying a target rate. The file itself is usually polygons with a rate attribute, or a grid of cells with a rate per cell. Either works. What matters is that the rate is in a named column with a unit everyone agrees on.
The two questions that decide whether a prescription file flies:
- Which attribute column holds the rate? A file with columns named Rate, Rate_lb, TgtRate, and Zone is unhelpful if nobody says which one the aircraft should read. Name it in the email.
- What unit is the rate in? Pounds per acre and kilograms per hectare are both normal and the numbers differ by roughly a factor of nine. A prescription read in the wrong unit does not fail loudly. It applies a wrong rate perfectly evenly.
Formats, and what each one is good for. There is no single universal file, so the practical rule is to ask what the operator's aircraft and software accept before exporting, then send that. In broad terms:
| Format | What it is | Watch for |
|---|---|---|
| Shapefile (.shp) | The long-standing GIS standard, still the most widely accepted | It is a file set, not one file — send all parts, zipped |
| GeoJSON (.geojson) | A single text file, easy to inspect and email | Always in longitude/latitude, so no projection ambiguity |
| KML / KMZ | Google Earth format, excellent for looking at | Thin on attributes — fine for boundaries, weak for rates |
| ISOXML task data | The ISO 11783 standard machinery exchange format | Comes out of ag software as a folder structure; keep it intact |
The shapefile trap, because it catches everyone once. A shapefile is not a file. It is a set of files that share a name and must travel together:
- .shp — the geometry itself
- .shx — the index that makes the geometry readable
- .dbf — the attribute table, which is where your rates live
- .prj — the declaration of which coordinate system the coordinates are in
Send only the .shp and it is unreadable. Send everything except the .prj and it is readable but floating, because nothing in the file says whether those numbers are degrees of latitude, metres in a UTM zone, or metres in a provincial projection. Software then guesses, and a wrong guess puts your field in the wrong place or scales its area incorrectly.
The fix is one line long: zip the whole folder and send the zip. That is the single highest-value habit in this entire article.
Coordinate systems, briefly, in Alberta terms. A coordinate system is the frame the numbers are measured in, and a file that does not declare its own is the most common reason a boundary lands in the wrong township or reports the wrong area. The ones you will meet here:
- Geographic longitude and latitude on the NAD83 or WGS84 datum. Coordinates look like -112.8 and 53.0. This is what GeoJSON and KML always use.
- UTM, which is metres on a zone-by-zone grid. Alberta straddles two zones: most of the central and eastern farming area falls in zone 12, while the far west and the Calgary area sit in zone 11. A file projected in the wrong zone is visibly displaced.
- Alberta 3TM and 10TM, the provincial projections you will see coming out of government and survey data.
You do not need to understand the mathematics. You need the .prj to exist, or the export dialogue to have had a coordinate system selected rather than left at a default. If a boundary ever plots in the ocean off Africa, that is the missing-projection signature, and it means the file was read as degrees when it held metres.
Geometry problems that stop a file. A prescription is instructions for a machine, and machines are unforgiving about geometry that a human eye would forgive:
- Gaps between zones. Ground in no zone has no rate, so nothing gets applied there.
- Overlapping zones. Ground in two zones has two conflicting rates, and which one wins is not something you want decided by chance.
- Unclosed or self-intersecting polygons. A boundary that crosses itself has no unambiguous inside.
- Slivers and stray fragments. A one-metre-wide zone is smaller than any effective swath a spreader can fly, so it cannot be honoured no matter how good the equipment is.
- Zones finer than the machine. A prescription drawn at a resolution the aircraft cannot resolve is a prescription that will be approximated. Better to know that at the design stage.
Most agronomy software cleans this up on export. Not all of it does, and a prescription hand-drawn over an image usually needs a look.
Attribute naming has a real limit. Shapefile attribute names are capped at ten characters, which is why columns arrive looking like TGT_RATE_L or ZONE_RATE1. That is a format constraint, not a mistake. It becomes a mistake when the name is so truncated that its meaning is lost, or when the export silently renames a column and the receiving end reads a different one. Say in the email which column is the rate and what unit it is in, and the truncation stops mattering.
What comes back, and what that file is. After the pass you should receive an as-applied map: a georeferenced record of where product actually landed, at what rate, on what date. That is not the same object as the prescription. The prescription is the plan and the as-applied record is the outcome, and comparing the two is how you find out whether the plan was achievable — where the aircraft could not honour a zone because it was too narrow, and where coverage overlapped.
Keep both. Next year's prescription is better for having last year's as-applied record beside it, and a program or funding claim generally wants the as-applied file rather than the plan.
Who owns the data. This is worth settling in writing before you send anything, because it is easy to settle in advance and awkward to settle afterward. The questions that matter:
- Who owns the boundaries and prescriptions you supply, which should be you.
- Who owns the coverage and as-applied records the aircraft generates, and whether you get them in an open format rather than trapped in a portal.
- Whether your field data can be aggregated, shared with a third party, or used in anything beyond doing your job.
- What happens to your files when the working relationship ends.
None of that is answered by the file format. It is answered by the agreement, and a straightforward operator will put it in plain language without being pushed. If nobody will tell you what happens to your field data, that is information too.
A last practical note on timing. File problems are discovered when someone opens the file, and if that happens the morning of the job the window is already closing. Send the files when the job is booked, not when the truck is loaded. An operator who opens them a week out has time to come back with one question instead of a cancelled day, and the field preparation guide covers the ground-side half of the same principle.
Key Dates
- Send files:When the job is booked, not the morning of
- Shapefile:Zip the whole folder — .shp, .shx, .dbf, and .prj together
- Coordinate system:Declared in the file, not assumed
- Rate column:Named in the email, with its unit stated
- Boundary:The farmed edge, not the title edge
- Returned file:Georeferenced as-applied record
How UAV AG Can Help
How UAV AG handles the file side of a variable-rate job:
- →We tell you which formats our aircraft and software read before you export, so nothing gets built twice.
- →Files get opened and checked when the job is booked, not on the morning of the pass.
- →We confirm the rate column and its unit back to you in writing before anything is flown.
- →Geometry gets reviewed for gaps, overlaps, and zones narrower than the effective swath we can actually fly.
- →If a field has no usable boundary yet, we draw one from imagery or a mapping flight — once, and you keep it.
- →A georeferenced as-applied record comes back to you in an open format after the pass, for your own files and for program documentation.
- →Your boundaries and prescriptions remain yours. We do not aggregate or pass on your field data.
A Note From Us
The reason this article exists is that the file handoff is invisible until it fails, and then it fails on the worst possible day.
Nobody thinks about a .prj file. It is four letters of a filename inside a folder that somebody zipped, or did not. But a boundary without one can put your quarter section in the wrong place entirely, and a rate column read in the wrong unit applies the wrong amount of product flawlessly evenly across the whole field, which is worse than applying it unevenly because it looks fine.
The whole problem is solved by two habits. Zip the folder rather than picking files out of it, and say in the email which column holds the rate and what unit it is in. That is it. Everything else in the list above is a check somebody should run once, a week before the aircraft is needed, when a question still costs a phone call instead of a window.
If your prescriptions come out of an agronomy platform and you are not sure what it exports, send us one field and we will tell you. It takes a few minutes and it means the real job is never the first time we see your data.
Frequently asked questions
What file format should I send field boundaries in?
Whatever the operator can actually read, which is worth asking before you export. Shapefile is still the most widely accepted and GeoJSON is the easiest to inspect and email because it is a single text file. KML and KMZ are fine for a boundary but thin on attributes, so they are a poor carrier for rates. ISOXML task data works where both ends handle it, provided the folder structure stays intact.
Why does my shapefile not open properly?
Almost always because part of the set is missing. A shapefile is several files sharing a name: .shp holds the geometry, .shx indexes it, .dbf holds the attribute table with your rates, and .prj declares the coordinate system. Sending only the .shp leaves it unreadable, and sending everything but the .prj leaves it readable with no declared location. Zipping the whole folder and sending the zip solves it permanently.
What is a .prj file and why does it matter?
It is the small text file inside a shapefile set that states which coordinate system the coordinates are in. Without it nothing tells the software whether those numbers are degrees of longitude and latitude, metres in a UTM zone, or metres in an Alberta provincial projection, so it has to guess. A wrong guess puts the field in the wrong place or reports its area incorrectly, and the classic symptom is a boundary plotting far out at sea.
Should the boundary follow the legal quarter section or the farmed area?
The farmed area. A title boundary includes the road allowance, the yard site, bush along a creek, and any long-term wet holes, none of which grow a crop. Flying that outline puts product on unproductive ground and inflates the acres on your invoice, because acre counts downstream inherit whatever the boundary says.
What units should a variable-rate prescription use?
Either pounds per acre or kilograms per hectare is normal, but the file has to say which and so should your email. The two differ by roughly a factor of nine, and a prescription read in the wrong unit does not throw an error — it applies a wrong rate evenly across the entire field, which is harder to spot afterward than an uneven pass would be.
What if I have no field boundary at all?
It is a small job rather than a blocker, and it only has to be done once per field. A boundary can be drawn from recent imagery or captured directly on a mapping flight, and after that it is reusable for every future pass, soil sampling plan, and prescription. Many farms also discover they already have one sitting in a yield monitor, a guidance display, or a previous soil sampling project.
Can zones in a prescription be too small to fly?
Yes. A spreader honours a prescription at the resolution of its effective swath, so a zone narrower than that swath cannot be applied as drawn no matter how precisely it was mapped. Very fine zones, slivers, and stray fragments get approximated in practice, which is why it is better to know the achievable resolution while the prescription is being designed than to discover it in the as-applied record.
Who owns the field data after a drone job?
That is set by your agreement with the operator, not by the file format, so it belongs in writing before you send anything. Reasonable terms are that the boundaries and prescriptions you supply stay yours, that the coverage and as-applied records come back to you in an open format rather than living only in someone else’s portal, that your data is not aggregated or shared with a third party, and that you know what happens to your files if the relationship ends.
Is the as-applied file the same as my prescription?
No, and the difference is the useful part. The prescription is the plan and the as-applied record is what actually happened: where product landed, at what rate, on what date. Comparing them shows where a zone could not be honoured because it was narrower than the swath and where coverage overlapped, which is exactly the information that makes next year’s prescription better.