How to Outsource GIS Mapping for Telecom Without Losing Control of Your Data

Most telecom GIS outsourcing engagements don't fail because the vendor is incompetent. They fail because nobody defined what "done" meant before the work started. An ISP sends over a shapefile request. The GIS firm delivers something. It comes back wrong — wrong coordinate reference system, missing attribute fields, features that don't align with field-verified pole locations. Then the rework starts, and suddenly a 45-day engagement turns into 187 days of back-and-forth while the network build waits.

I've been on the receiving end of these situations — and I've been the one cleaning them up. This article is about how to structure a telecom GIS outsourcing engagement so you don't end up paying twice for the same data.

Why Telecom GIS Outsourcing Fails — and What the Failure Costs

The failure mode isn't usually technical. It's contractual — or rather, the absence of any contract-level specificity about what the deliverable needs to be. ISPs hand over a vague "GIS mapping" request and get back something they can't use in their network management platform. Features don't align with field conditions. Attributes are incomplete or inconsistently named. The coordinate system doesn't match anything else in the stack.

Here's a specific example. A fiber build in central Ohio — a rural fixed wireless and FTTH expansion across five counties — came to us for remediation after the original GIS engagement produced an unusable dataset. The GIS deliverable came back with all features in a local state plane zone that didn't match the network management platform's expected WGS84 coordinates. Not just slightly off. Off by enough that splice points were appearing in the wrong county on the NMS map. Re-georeferencing 847 pole records and reconciling the attribute schema cost 11 days and $14,300 in re-work charges. That's before you count the schedule impact on construction crews who were waiting on corrected as-built data.

None of that had to happen. The fix was simple — define the output CRS, attribute schema, and format requirements before anyone opens ArcGIS. But that conversation didn't happen until after delivery, which is 187 days too late.

The costs are real and specific. Rework on a GIS dataset doesn't just cost the GIS team's time — it delays permit submissions, holds up BEAD grant closeout documentation, and prevents network operations teams from activating their monitoring systems. Good telecom CAD and GIS work starts with a specification document, not a shapefile request. If your vendor isn't asking for one, write it yourself and hand it to them.

What a Qualified Telecom GIS Firm Actually Delivers

Let me be specific about what a real telecom GIS engagement produces. Not a KMZ alone. Not a PDF with a map on it. Those aren't GIS deliverables — they're display files.

A complete OSP fiber GIS engagement delivers structured feature classes for every network element. Fiber segments carry cable type, fiber count, sheath color, installation date, route segment ID, and attachment type. Splice points include enclosure model, enclosure manufacturer, splice count, splice type, and GPS-verified coordinates accurate to 0.3 meters. Poles — or conduit segments for underground builds — carry owner, class, height, make-ready status, and the utility's own pole identification number matching their GIS export. Equipment locations include asset type, manufacturer, model, and mounting configuration.

Coordinate accuracy matters. Point features — poles, splice points, equipment pads — should be accurate to 0.3 meters or better. Linear features — fiber segments, conduit runs — should be accurate to 0.5 meters. That's not arbitrary. It's what utility GIS systems and BEAD program documentation requirements expect. Coarser than that and you're not meeting the standard for any serious infrastructure grant closeout.

Format requirements: ESRI File Geodatabase as the primary delivery format, with Shapefile and GeoJSON exports as standard secondaries. The EPSG code must be documented — not assumed. And the attribute table must have zero nulls in required fields before delivery. An attribute table with 23% null values in the enclosure model field isn't a deliverable; it's a draft. Check the CAD/GIS documentation standards for OSP fiber networks for the complete attribute requirement breakdown.

One more thing worth stating plainly: the GIS data should integrate directly with your network management platform. That's not a nice-to-have. It's the entire point. If your vendor isn't asking which platform you're using at kickoff, they're not thinking about integration — they're thinking about producing a file and closing the job.

The Coordinate Reference System Problem Nobody Talks About

CRS mismatches are the single biggest cause of GIS deliverable failure in telecom. I say that having reviewed hundreds of outsourced datasets across 22 states.

NAD83 versus WGS84 sounds minor. It's not. Depending on your region, NAD83 (EPSG:4269) and WGS84 (EPSG:4326) differ by 1–2 meters. Over 37 miles of fiber route, that 1–2 meter offset causes every feature to visually misalign with your existing network data, your aerial imagery basemap, and your utility's pole database. Network management platforms that auto-snap features to existing layers will snap them to the wrong poles. That's not a GIS problem anymore — it's a field verification problem, and it's expensive.

The UTM zones add another layer of complexity. NAD83/UTM zones vary by region — central Texas uses EPSG:32614, central Ohio uses EPSG:32617, and the Pacific Northwest might be on EPSG:32610. A firm that defaults to a single UTM zone without checking your project location is setting you up for a re-projection problem. For projects that cross UTM zone boundaries — not uncommon on long-haul fiber routes — the CRS strategy needs to be explicitly agreed upon before digitizing begins.

The fix is simple. Ask every GIS firm this question in your first conversation: What datum and coordinate system do you default to, and can you match our existing platform's CRS? If they can't answer without hesitation — if they have to go ask someone or "check their template" — that's your answer. Walk away. A firm that does this work regularly knows their default CRS the way a drafter knows their line weights.

Specify the EPSG code in writing at project kickoff, in the scope document, in the deliverable specification, and in the QA checklist. Don't assume it's understood. Good as-built GIS documentation standards require the EPSG code to be documented in every deliverable package — treat that same requirement as a non-negotiable for outsourced mapping engagements too.

Data Governance: Staying in Control When You're Not Doing the Work

The governance question is where most ISPs get into trouble. They outsource the GIS work, the vendor manages the data in their own systems, and 18 months later the ISP needs to change vendors — or the vendor closes — and suddenly they don't have a clean, current copy of their own network data.

That's not a hypothetical. It happens.

Staying in control of your GIS data when you're outsourcing the production comes down to four things. First: version control. Every deliverable should have a version number and a delivery date in the filename and in the metadata. You need to know which version of the dataset is authoritative at any point in time. "final_v3_revised_updated_FINAL2" is not version control. "FiberRoute_OH_Licking_v3.1_20260505.gdb" is.

Second: data schema agreement upfront. Define every feature class, every attribute field name, every field type, and every allowed value before work starts. This is a table you build together at kickoff — not something the vendor fills in after the fact. If you don't own the schema definition, you're dependent on the vendor to interpret their own data forever. That's lock-in.

Third: formal QA/QC protocol. The vendor should run their own QA against the agreed schema before delivery. Not a visual check — an attribute completeness check, a topology check (no gaps, no overlaps, no dangling segments in the fiber route feature class), and a coordinate accuracy verification against field GPS points. Ask to see their QA checklist before you engage. A vendor that can't produce one doesn't have a QA process — and you'll be running their QA for them at your own cost, after delivery, on your schedule.

Fourth: data sovereignty. Your GIS data lives in your systems. Period. Never accept an arrangement where the vendor manages the authoritative dataset in their system and gives you exports on request. That's vendor lock-in with a GIS label on it. The CAD/GIS documentation standards for OSP fiber networks are clear on this — the owner of the infrastructure owns the authoritative data record. Any outsourcing arrangement that puts the vendor in control of the master dataset is structurally wrong, regardless of how reliable that vendor has been so far.

Questions That Sort GIS Firms in the First 20 Minutes

Portfolios don't filter GIS firms. Pretty maps tell you nothing about data quality, schema consistency, or whether the firm can match your platform's CRS requirement. Questions do.

What GIS software do you use natively? The answer should be ArcGIS Pro, QGIS, or both — and they should be able to explain why. A firm that says "we use Google Earth" for production-grade telecom GIS work isn't a production-grade GIS firm. A firm that uses QGIS exclusively is fine for many workflows but may have limitations if your NMS is tightly integrated with the Esri ecosystem. Know what you need and verify the match.

What coordinate systems do you deliver in by default, and can you match a client-specified CRS? We covered this. If they hesitate, that's the answer.

What feature classes do you produce for a standard OSP fiber build? They should list fiber segments, splice points, poles or conduit, and equipment locations without prompting. If they say "it depends on what the client asks for" without also volunteering a standard schema, they don't have one. Every project starts from scratch. That means inconsistent data across your network over time.

How do you handle topology errors — gaps, overlaps, dangling segments? The answer should describe a specific topology rule set they run before delivery: no gaps greater than 0.01 meters in the fiber route network, no overlapping segments, no dangling endpoints except at terminal equipment. If they say "we check it visually," that's not a topology QA process. Visual checks miss sub-meter gaps that still break network tracing in your NMS.

What's your attribute schema for a fiber segment feature class? This is the filter question. A qualified firm recites it: cable type, fiber count, sheath color, installation date, segment ID, length, attachment type, project ID. An unqualified firm says "we include whatever the client needs." That sounds flexible. It's actually a red flag — it means there's no standard and every deliverable will be different. Your GIS fiber network planning needs consistent data across all builds, not a patchwork of vendor-specific schemas.

One more: Can you describe your delivery QA protocol before a package goes to the client? Ask for specifics. Attribute completeness check — how? Topology validation — which rules? CRS verification — how is it confirmed? A firm with a real QA process knows the answer immediately. A firm without one will describe a general review process that amounts to "someone looks it over."

These questions take 20 minutes. They'll tell you more about a GIS firm's actual capability than reviewing 30 portfolio samples. Use them. Your field survey data accuracy — already hard to get right — deserves a GIS firm that can handle it correctly on delivery, not one that requires three revision cycles to get the attribute schema right.

How Draftech's GIS Team Integrates With Your Existing Systems

Our CAD/GIS services team works natively in ArcGIS Pro. That's not a marketing claim — it's the production environment for every OSP fiber GIS engagement we run. Feature classes are built in ArcGIS Pro geodatabases from the start, not converted from another format at the end.

Standard delivery format is ESRI File Geodatabase (.gdb), with Shapefile (.shp) and GeoJSON exports included in every package. No add-on, no additional fee. The coordinate reference system is NAD83 (EPSG:4269) or WGS84 (EPSG:4326) per client specification — confirmed in writing at project kickoff. If your platform uses a state plane or UTM CRS, we match it. We've worked in UTM zones from EPSG:32610 through EPSG:32619 across active projects. The EPSG code is documented in the delivery metadata and in the project record.

Every engagement starts with a kickoff schema document — a table defining every feature class, field name, field type, field length, and allowed values for the project. That document is reviewed and approved by the client before digitizing begins. It's the quality baseline we QA against before delivery. Our QA protocol includes an attribute completeness check against the schema (zero nulls allowed in required fields), an ArcGIS topology validation run (no gaps, no overlaps, no dangling endpoints in fiber route feature classes), and a spot-check of coordinate accuracy against field GPS points using a sample of at least 37 point features per delivery.

Deliverables are versioned. Every package includes a version number, delivery date, and a QA sign-off sheet documenting what was checked and by whom. That documentation travels with the data — it doesn't live in our project management system where you can't access it.

We're currently active in 22 states and deployable across all 50 U.S. states. Project scale ranges from 8-mile rural aerial builds to 140-mile regional backbone routes. Our GIS deliverables integrate directly with common network management platforms. If you're running a BEAD-funded build, our GIS data meets the documentation requirements for grant closeout — including the formatted feature class exports and metadata standards that NTIA-funded programs expect. The BEAD grant closeout documentation requirements are specific, and a GIS dataset that doesn't meet them creates real compliance risk at closeout.

We also work alongside OSP engineering teams — either your internal team or ours — so the GIS data stays synchronized with the engineering record throughout the build, not just at closeout. That integration eliminates the data drift between design intent and as-built reality that's the single most common source of GIS inaccuracy in telecom networks.

Want to know if your current GIS vendor is set up to deliver what you actually need? Send us a sample dataset at info@draftech.com and we'll tell you exactly what's missing, what doesn't meet standard, and what a corrected deliverable should include.