From field data to construction-ready packages. We produce AutoCAD and MicroStation drawings, ArcGIS fiber network maps, splice diagrams, and permit sets — in whatever format your build team can actually use in the field.
Telecom CAD and GIS design services convert field survey data into construction-ready deliverables: AutoCAD plan sheets, splice diagrams, route maps, permit drawing sets, and GIS geodatabases. The output quality depends on field data accuracy at intake and engineering validation before delivery. CAD/GIS production that bypasses either end of that chain generates RFIs and change orders during construction.
Here's the thing about CAD/GIS design in OSP — the output is only as good as what happens at both ends of the workflow. Bad field data in, bad construction drawings out. And drawings that look clean in the office but don't account for field reality are going to generate RFIs the moment a crew actually tries to use them.
We sit in the middle of that process deliberately. Our field survey teams collect the data. Our CAD/GIS designers convert it into construction packages. Our engineers validate the logic — the fiber assignments, the splice schedules, the make-ready designs — before anything goes to the client. That's not a marketing claim about "end-to-end service." It's a practical workflow that eliminates the handoff errors that kill schedule when data moves between subcontractors who don't talk to each other.
For GIS-driven fiber network planning and how it affects project cost, our team also published a detailed breakdown — that's worth reading if you're evaluating whether to invest in a proper GIS-based design workflow versus legacy CAD-only production.
What we don't do: We don't produce drawings in a vacuum. If we're building construction packages from client-supplied field data, we'll flag inconsistencies before design starts — not after. A pole survey where 12% of records are missing attachment heights isn't a design input, it's a re-survey request. We'd rather say that on day one than produce drawings that fail engineering review.
Our CAD/GIS work covers aerial and underground fiber — rural BEAD corridors, suburban FTTH buildouts, downtown conduit systems, and everything in between. We've designed in utility-heavy corridors outside Memphis with 23 active attachments per pole and on open farmland in North Dakota where the design challenge is span length, not congestion. Different problems. Same standard of care.
CAD and GIS software for fiber network design includes AutoCAD and MicroStation for construction document production, ArcGIS and QGIS for spatial network modeling and geodatabase management, and platforms like IQGeo and GE Smallworld for enterprise network inventory. Platform selection depends on pole owner requirements, state DOT standards, and the client's existing network management infrastructure.
We're platform-agnostic by design. Our designers work in your environment, not just ours. These are the platforms we use daily.
Industry-standard for OSP construction packages. We work in AutoCAD for plan sheets, pole attachment details, splice diagrams, bore profiles, and permit sets. Custom block libraries built to your company standards or ours. Civil 3D on projects requiring terrain-referenced profiles.
Our primary platform for fiber network mapping, route analysis, and multi-user GIS database management. We build geodatabases with proper topology rules, domain-coded attributes, and relationship classes — not just shapefiles someone named poorly and called a GIS.
Used where Esri licensing is a constraint or where the client's environment is already QGIS-based. QGIS handles the majority of fiber mapping workflows without issue. We'd recommend ArcGIS for multi-user enterprise environments, but QGIS is fully capable for project-scale work.
Required by some state DOTs and utilities with legacy standards. We've worked in MicroStation on DOT highway crossing permit packages in states that won't accept AutoCAD DGN conversions — you need native MicroStation files, properly structured, and we produce them.
Used by larger ISPs and BEAD subgrantees who need their GIS to function as a live operational database. IQGeo supports fiber planning, work order generation, and field dispatch from a single data model. We design in it for clients who've standardized on the platform.
Primarily used by electric and gas utilities that are entering the fiber space as partners on joint-build projects. Smallworld's data model is deep and idiosyncratic — you need designers who've actually worked in it, not just people who've seen the interface. We have both.
There's no magic in CAD/GIS production. What matters is the sequence of decisions and the quality controls at each step. This is how we run it.
We receive field data — Fulcrum exports, Katapult files, KMZ route traces, or scanned field notes — and run it through a validation checklist before design starts. Missing pole records, GPS outliers more than 15 meters from road centerlines, attachment heights outside expected ranges, and duplicate pole IDs all get flagged and resolved. We don't start drawing on data that hasn't passed intake. That's a rule, not a preference.
We load field data into the GIS environment, apply the project coordinate reference system (NAD83 / State Plane is typical for US utility work), and set up the layer schema. Pole features, route centerlines, underground structures, and service area boundaries all get their own attributed feature classes with the right domain constraints. At the end of this step, we have a working GIS that's ready for route design — not just a points layer on a basemap.
Aerial and underground route finalization in the GIS — connecting pole features with properly attributed span segments, establishing conduit routes with fill calculations, and integrating the FTTH network architecture (fiber distribution hubs, network access points, splitter locations). This step is where the engineering decisions get locked in. We cross-check route decisions against the FTTH design specifications — fiber counts, split ratios, FDH sizing — before moving to CAD production.
Route exports from GIS get brought into AutoCAD or MicroStation for construction package production. Plan sheets at client-specified scale, with pole numbers, cable assignments, hardware callouts, and construction notes. Splice diagrams showing fiber assignments at every splice point. Bill of materials generated from the design attributes — not manually counted, which is where quantity errors creep in. Underground segments get bore profiles on projects where terrain grade affects bore path design.
Every construction package gets a QC pass by a senior designer before delivery. We check: fiber count continuity from segment to segment, splice diagram accuracy against cable assignments, pole number consistency between GIS and CAD, hardware quantity reconciliation against the BOM, and permit drawing completeness. Redlines get tracked in a comment log and resolved before final delivery — not included in the package with a note that says "see redlines."
Final packages delivered in your required format — PDF for permit sets, DWG or DGN for CAD files, FGDB or SHP for GIS data. We stay available for construction RFIs. When a contractor in the field hits something that doesn't match the drawings — and eventually one will — we want to hear about it immediately, not two months later when the as-built documentation is a disaster.
A fiber network CAD construction package includes plan sheets at design scale, splice diagrams with fiber assignments at every splice point, a bill of materials generated from design attributes, permit drawing sets formatted per agency requirements, and cable/conduit schedules. Underground projects add bore profiles. For a complete deliverable breakdown, see our guide on fiber construction package deliverables.
A construction package isn't just a PDF set. It's a complete design handoff — for a full breakdown of fiber construction package deliverables, see our guide. Everything the build crew needs to construct the network without calling the engineer every three hours.
Route plan at 1:200 to 1:500 scale depending on density, showing poles, cable runs, underground segments, and crossing details. Includes title block, revision block, and applicable design standard references.
Per-enclosure fiber assignment diagrams showing tube and fiber numbering, splice loss budgets, slack storage requirements, and spare fiber disposition. Formatted to your network's color-coding convention.
Itemized BOM with part numbers, manufacturer, quantities, and unit — generated directly from design attributes, not manually counted. Includes cable reels, hardware, vaults, conduit, and drop materials.
Specific cable assignment per route segment with reel numbers, footage, and pull direction. Prevents the classic field problem where two crews pull the same cable from opposite ends of a segment.
Authority-specific drawings formatted to DOT, railroad, waterway, or municipal requirements. Includes attachment details, clearance tables, and crossing profiles at the scale and format the authority requires.
Construction notes sheet covering applicable NESC grade requirements, make-ready specifications, splicing standards, conduit fill limits, and any client-specific build standards the contractor must follow.
Complete GIS dataset: pole features, route centerlines, splice enclosure locations, underground structures, and service area boundaries — all attributed and in the project coordinate system. Delivered as FGDB, SHP, or KMZ.
Fill percentage calculations for all conduit segments, demonstrating NESC and client standard compliance. Flags any segments approaching capacity limits that may constrain future additions.
If you're evaluating whether your current construction package format is causing unnecessary RFIs or field confusion, it's worth reading our article on common FTTH HLD design mistakes — several of them trace directly back to how design packages are structured and what information gets left out.
This is the part nobody wants to talk about at the start of a project and everybody regrets ignoring. Your GIS is only useful if the data is clean, structured, and consistent. A network that lives in seventeen different shapefiles with inconsistent attribute names, mixed coordinate systems, and no topology enforcement isn't a GIS asset — it's a liability.
We've inherited some spectacular disasters. A project in the mid-Atlantic region brought us in to assist with a BEAD submittal — and the client's "GIS database" turned out to be 340 separate KMZ files exported from Google Earth, each named by a crew member's initials and a date, with no consistent attribute schema. The coordinate accuracy was fine. Everything else was a problem. We spent six weeks standardizing and importing before the first design drawing could be produced.
If your network history lives in old AutoCAD drawings, paper maps, or a GIS database that was built without a coherent schema, we can migrate it. The process involves building an attribute crosswalk (what "Cbl_Sz" in the old dataset maps to "cable_size_code" in the new schema), defining feature class structures, running automated import with exception reporting, and manually reviewing high-error segments. It's not glamorous work. But a properly migrated dataset saves engineering hours on every subsequent project that touches that network.
Clients increasingly need data in multiple formats simultaneously — an Esri FGDB for their GIS team, AutoCAD DWG for the construction contractor, and a KMZ for the project manager's field app. We build that into the delivery workflow, not as an afterthought. Format conversion done poorly introduces errors — coordinate precision loss, attribute truncation, feature simplification that affects clearance calculations. We test every format conversion against the source dataset before delivery.
On GIS database standards: We default to NAD83 / State Plane (appropriate zone) for US projects unless the client specifies otherwise. All polygon and polyline features have proper closure and vertex counts. Topology rules are defined and validated before delivery. If you've received GIS data from us and something doesn't conform to your internal standard, tell us — we'll correct it, not argue about it.
As ISPs scale, the GIS design database eventually needs to connect to operational systems — work order management, trouble ticketing, capacity planning. We design GIS schemas with that downstream integration in mind. Feature class structures that map cleanly to IQGeo, OSS/BSS platforms, or Esri Utility Network don't happen by accident. They're a design decision that needs to be made at the start of the project, not retrofitted after 200 miles of network data has already been built on an incompatible schema.
For a more detailed look at how GIS investment affects long-term project cost, our article on GIS fiber network planning and cost reduction covers the numbers behind that decision.
Platform selection isn't a preference question — it's driven by project scale, client environment, and downstream data requirements.
| Platform | Best For | Key Limitations |
|---|---|---|
| AutoCAD | Construction packages, permit sets, pole attachment details, DOT crossing drawings | Limited geospatial analysis capability; attribute management outside native CAD requires workarounds |
| ArcGIS (Esri) | Enterprise fiber network databases, multi-user editing, topology analysis, OSS/BSS integration | Licensing cost; steeper learning curve; overkill for small single-project deployments |
| QGIS | Single-user GIS workflows, open-source environments, clients without Esri licenses | Multi-user editing is complex without enterprise setup; fewer native integrations than ArcGIS |
| MicroStation | State DOT permit packages, utility company handoffs with DGN requirements | Limited adoption outside DOT/utility contexts; requires MicroStation-trained designers |
| IQGeo | Tier 2/3 ISPs with operational GIS needs; BEAD subgrantees planning for long-term network management | Significant platform investment; best suited for operators with 10,000+ locations to manage |
| GE Smallworld | Joint builds with electric or gas utilities who have existing Smallworld environments | Proprietary data model; high implementation cost; rarely appropriate outside utility partner projects |
The most common platforms in OSP design are AutoCAD (for general-purpose drafting and construction packages), MicroStation (common on DOT and utility projects with strict CAD standards), and specialized GIS platforms like ArcGIS and QGIS for network mapping and spatial analysis. IQGeo and GE Smallworld are used for integrated network management where the GIS also drives work order systems. Platform choice usually follows the client's existing environment — we work in all of them.
ArcGIS (Esri) is the industry standard for large-scale fiber network mapping — it has better enterprise data management, smoother integration with utility GIS systems, and more mature toolsets for network topology analysis. QGIS is open-source and costs nothing in licensing, which matters on smaller projects or when a client's GIS environment is already QGIS-based. We use both. ArcGIS for projects requiring network topology enforcement and multi-user editing; QGIS for projects where licensing cost is a constraint and the data complexity doesn't require Esri's full stack.
A complete fiber construction package includes: plan-and-profile or plan sheets showing the route at a readable scale (typically 1:200 to 1:500 depending on client standard), splice diagrams with fiber assignments and slack specifications, a bill of materials (BOM) with part numbers and quantities, pole attachment details with heights and hardware specs, cable reel assignments, conduit fill calculations for underground segments, permit drawings formatted to authority requirements, and a general notes sheet with applicable construction standards.
Most clients start by sending us their field data (Fulcrum exports, Katapult files, or scanned field notes) along with a design brief specifying network architecture, splitter ratios, and construction standards. We produce a pilot package — typically a 1–2 mile sample segment — for your team to review against your standards. After approval, we scale to full production. Turnaround on construction packages averages 5–10 business days per route mile depending on complexity.
Yes. Legacy data migration is something we do regularly — converting old AutoCAD drawings into attributed GIS features, importing scanned paper maps into a spatial database, and standardizing attribute schemas across inconsistent datasets. The hardest part is usually the attribute mapping: figuring out what "Cbl_Sz" meant in a 2009 database field and whether it matches what the current schema expects. We build a crosswalk table and document every mapping decision so the migration is auditable.
IQGeo is a network design and management platform used by larger ISPs and utilities who need their GIS to serve as a live operational database — not just a design tool. It supports fiber network planning, work order generation, and field crew dispatch from a single spatial data model. We design in IQGeo for clients who have already standardized on the platform, which is increasingly common among Tier 2 and Tier 3 carriers who received BEAD subgrant awards.
If your current CAD/GIS production is a bottleneck — slow turnaround, inconsistent standards, data that doesn't survive the handoff to construction — we should talk. Send us a sample of what you're working with and we'll tell you honestly whether we can improve it and how. No hard sell. We've handled over 44,000 miles of OSP design and we've seen most of the problem patterns at this point.
Talk to Our CAD/GIS TeamOr email us directly: info@draftech.com | Join our design team