Why teams annotate GIS data in the first place

Three reasons account for most of the work we see.

Building a usable asset inventory from imagery you already own

A state DOT has 30,000 miles of roadway video and dashcam footage. Somewhere in there are every guardrail, sign, traffic signal, drainage culvert, and pavement marking on the network. Manually cataloging them through a windshield survey takes years and goes stale by the time it's done. Annotating the imagery — extracting each asset with its location, class, and condition cue — produces a starting inventory in months. Once the inventory exists, it becomes the basis for maintenance scheduling, safety reviews, and capital planning.

Training data for a geospatial AI model

A mobile-mapping company is building a feature extraction model that runs on customer captures. The model needs labeled examples to learn from: thousands of annotated frames with the features the model should detect, marked correctly. The model is only as good as the training data. Bad annotations don't just degrade accuracy — they create systematic bias the model can't diagnose itself.

Pre-labeling a dataset for downstream review

A utility runs an inspection program where field crews walk a corridor and confirm or reject equipment condition. Walking with no prior data is expensive. Walking with a pre-labeled tablet ("here are the 47 poles in your segment, please confirm condition for each") cuts field time in half. The annotation feeds the inspection workflow, not a model.

How a project actually runs

Every annotation project we run follows the same four stages. The proportions shift by project type but the stages don't.

Stage 1: Schema lock

Before any annotation happens, we lock the schema. This is the most under-invested stage in the industry and the one that determines whether the project is useful or not.

Schema lock means agreeing in writing what every class is, how it's defined, how edge cases are handled, and how the output is structured. For road signs that means: do we follow MUTCD codes (R1-1) or descriptive names (stop sign)? Do we annotate the sign face only, or include the post and mount? What do we do when the sign is occluded by foliage? When it's bent? When there's a temporary overlay? Each of these gets a written rule before annotators see a frame.

A typical schema document for road infrastructure runs 10-20 pages and references MUTCD, AASHTO standards, and the client's existing GIS data dictionary. Boring document. Saves entire projects from being unusable.

Stage 2: Pilot

A small batch — typically 100-500 frames — labeled by 2-3 annotators independently. Output is reviewed against the schema, inter-annotator agreement is measured, edge cases are surfaced. Pilot output is delivered with a report covering: per-class F1 score, kappa scores between annotators, list of edge cases and our interpretation, and recommended schema refinements before production.

This is the moment the project is most likely to fail. Not because the work is bad, but because the schema turned out to encode an ambiguity nobody noticed until annotators started disagreeing. Discovering this on a 500-sample pilot costs days. Discovering it after labeling 100,000 frames costs months.

Stage 3: Production

Once schema and QA standards are calibrated, production runs at scale. Annotators work in CVAT (or whatever platform the project uses), QA passes happen on a sample of every batch, exceptions are routed to a senior reviewer. Production output is delivered on a weekly cadence in the agreed format.

Throughput is usually 200-800 frames per annotator per day, depending on density and complexity of features per frame. A typical project runs 4-12 weeks of production after pilot.

Stage 4: Integration

The final stage that most annotation vendors skip. We hand the output off in the format your downstream system ingests, with a written integration guide. If the system is QGIS or ArcGIS, the output lays down on existing layers without conversion. If it's a model trainer, the format matches what the trainer expects. If integration uncovers issues, we fix them in the original labels and re-deliver.

What teams get wrong on their first project

Three failure modes we see repeatedly.

Skipping schema lock. "Just label all the signs" sounds reasonable. It produces a dataset that's 60% usable. The 40% gap is the cases nobody defined a rule for.

No QA reviewer with domain expertise. A GIS-trained reviewer catches that a labeled "utility pole" is actually a streetlight, that a stop sign falls outside road right-of-way, that the lane line direction labels are inverted on a one-way street. A generic QA reviewer doesn't. The QA pass is where domain expertise compounds, not where it can be skipped to save cost.

Output format chosen at the end. Picking output format after labeling is done means converting labels. Conversions lose information (most commonly: the QA trail and the original confidence score). Pick the format up front so labels are produced in it natively.

How to think about cost

The cost of GIS annotation isn't the labeling — it's the cost of not having usable labeled data when your downstream system needs it. Most projects we run pay back within 3-6 months by replacing a labor-intensive manual process (field inventory, manual map updates, recurrent windshield surveys).

Pilot pricing is fixed and predictable. Production pricing is per-frame or per-feature with volume tiers. We publish ranges before any pilot kicks off so you can decide whether the math works without negotiating.

Need a project scoped? Send a representative sample of your imagery and a paragraph about what you want labeled. We'll come back with a schema draft, pilot scope, and pricing within 48 hours.