What we mean by "geodata annotation"
Most of the labeling industry treats imagery as a pixel grid. You draw a box around a cat, you save a JSON file with corner coordinates in pixel space, you move on. That works fine when the only question is "is there a cat in this picture."
Geodata annotation is the same job done on imagery where the answer needs to land on a map. A bounding box around a stop sign is not useful to a transportation department unless the box is tied to a coordinate (lat/lon, optionally elevation), a projection (which datum, what zone), a class that fits an established schema (MUTCD R1-1 for a US stop sign, not just "stop sign"), and a QA trail that survives a regulatory audit two years from now.
We call this geodata annotation to distinguish it from the more common "image annotation" or "data labeling" services. The visible work — drawing the box — looks similar. The deliverable is structured differently because the consumer is different.
Where the difference actually shows up
Three places it shows up in production.
The output isn't a folder of labels
When we ship an annotation deliverable, you don't get a zip of label files keyed to image filenames. You get GeoJSON, COCO, KITTI, or Mapillary output where every feature carries its geometry in a real coordinate system, its class id, a confidence score, the QA reviewer who approved it, and timestamps for capture and review. Load it into QGIS or ArcGIS, it lays down on a basemap correctly. Feed it into a training pipeline, the features still know where they are.
Class definitions are schema, not labels
A generic labeling team will accept "stop sign" as a class. We push back. There are 70+ types of US regulatory signs in MUTCD, and a stop sign is R1-1 specifically. There are also R1-2 yield signs, R1-5 stop-here-on-red signs, and R1-1A all-way supplements. If your downstream consumer is a state DOT asset inventory, "stop sign" loses 90% of its value the moment it's stored. We push the schema conversation up front so the labels you get are the labels your system can actually use.
QA is spatial, not just visual
Generic QA is visual: the reviewer looks at the image, decides if the box is right. Spatial QA also checks the geographic facts. If a label is supposed to be a road sign, it should fall within road right-of-way (we cross-reference public ROW polygons). If a label is supposed to be a utility pole, its location should approximate a utility company's pole inventory (we cross-reference the authoritative GIS layer where one exists). When a label disagrees with the spatial ground truth, the reviewer is notified, not the model.
Why this difference matters to your team
Two reasons we hear most often.
First, the data you get from geodata annotation is usable as-is by your map team. They don't need to reverse-engineer the coordinate system from filename conventions, or write a script to validate that every label has a real-world position. The cost of integrating annotation output into a production map system is dramatically lower when the annotation team built it for that purpose.
Second, when the work needs to defend itself — a regulatory submission, an asset inventory audit, an expert challenge in litigation — the metadata is already there. We don't have to retroactively reconstruct chain of custody. Each feature carries its capture timestamp, its review timestamp, its reviewer ID, and a link back to the source frame. If the work is challenged, we have answers.
When generic image labeling is fine
If your downstream consumer is a model that only cares about pixels (a perception model with no map output, an object detection benchmark, a research dataset), generic image labeling is fine. You're paying for visual accuracy and that's what you'll get.
If your downstream consumer is anything that touches a map — asset inventory, infrastructure monitoring, autonomous vehicle ground truth, regulatory work — the small extra cost of geodata-native annotation pays back the first time someone asks "where is this thing?" and you have a defensible answer.
How we got here
We've been doing GIS work since 2018. Annotation became a service line because clients were sending us cleaned-up label outputs from other vendors and asking us to spatial-validate them. We were doing 30-40% of the labeling work over again to make it usable. Eventually we built the front of the pipeline too.
The shift from generic labeling to geodata-native labeling isn't a technique change. It's a discipline change. The schema discussion happens before annotators touch a frame. The QA pass uses authoritative spatial layers, not just visual review. The output format is decided up front, in the format your consumer ingests. Everything else is the same boring craft of drawing boxes accurately and consistently.
Want to see what this looks like in practice? Run a 500-sample pilot in 2-4 business days. You send representative imagery and a target schema; we return labeled output in your pipeline's format with QA scores and an edge-case log. Fixed pilot fee, no commitment to scale.