# Telecom Desktop Routing Services: What the Desktop Package Contains and What Fielding Must Close

**Title tag:** Telecom Desktop Routing Services Guide 2026
**Meta description:** Telecom desktop routing services: imagery, parcel, ROW and utility layers, preliminary route, planning quantities, accuracy limits, and field-survey handoff.
**Author:** Ashish Kumar Meena
**Published:** September 22, 2026  
**Last updated:** September 22, 2026  
**Category:** GIS/CAD & Mapping
**URL:** https://draftech.com/blog/telecom-desktop-routing-services
**Primary keyword:** telecom desktop routing services
**Word count:** 3153
**Read time:** 13 minutes
![A person at an office desk looks at colored routes on a satellite map on a computer monitor, with a paper map beside them.](../../blog/img_telecom_desktop_routing_services.webp)

---

A project manager can treat a clean GIS line as if a crew already walked it. That is how a preliminary route becomes a construction assumption before anyone measures a pole or a shoulder. The desktop package never claimed that authority. Someone used it as if it had.

This guide is the desktop-phase service. It names what the package contains, the accuracy of each layer, the decisions it cannot close, and the handoff that sends a crew to the remaining questions. Which corridor survives is a different question, and it lives in our [fiber route analysis](/blog/fiber-route-analysis). Scoring miles against cost is covered in the [fiber route optimization techniques for ISP networks](/blog/fiber-route-optimization-techniques-isp-networks). The freeze from need map to buildable corridor is the [broadband route planning](/blog/broadband-route-planning) workflow. This package is the desktop evidence that workflow consumes, not a replacement for it.

## What Telecom Desktop Routing Services Deliver

Telecom desktop routing services assemble a preliminary fiber route from imagery and GIS parcel layers, plus ROW and published utility records, then attach planning quantities that inherit those sources' limits. A defensible package names at least 4 source classes and a confidence class on every accepted line. It is a screening product, not a stakeout.

The buyer is usually trying to fund a field effort or a permit screen, and they want a line they can defend when a reviewer asks which source authorized each segment. Mileage is not the product. The product is a line that can be traced to its sources, with the remaining questions written down instead of absorbed into a confident color. We refuse to issue a desktop route that looks finished when the land-base date is missing.

We keep engineering of that package in-house. Construction, when the owner later includes it, is full turnkey through Draftech-managed subcontract crews. The desktop phase does not authorize either. It only decides where the next dollar of evidence should go.

A confidence class is a plain label on the feature, not a legend decoration. We use four: verified, reported, inferred, unknown. Verified means we have supporting evidence for that feature's intended use. Reported repeats an identified source. Inferred is our analysis. Unknown stays open. Mixing those four into one "good enough" style is how a tax lot becomes a ROW exhibit on a later sheet.

> **Desktop rule:** never style a preliminary route as a construction centerline. Line weight does not upgrade the source.

## What the Desktop Route Package Contains

The package is a register first. Geometry is the index into that register. Every accepted layer carries a publisher and a source date, plus a coordinate reference and the decision that layer is allowed to support. A file named final is not provenance. We hash or otherwise freeze the accepted source set so a replacement download cannot enter unnoticed.

The table maps 6 layers we expect in a desktop route package. Owners may use different labels. The sequence still holds because it separates land-base context from the line we draw and keeps planning quantities from pretending to be a bid form.

| Layer | What it contributes | Planning use | Field trigger |
| --- | --- | --- | --- |
| Current imagery | Visible pavement, structures, canopy, recent land change | Align the line to what is on the photo | Photo date older than last known construction, or the line sits under canopy |
| Parcel GIS | Tax-lot boundaries and mapped owner names | Flag private-frontage risk | Line leaves public road frontage |
| ROW or easement layers | Recorded or inferred occupancy corridors | Screen whether the line stays inside a known occupancy | Gap, overlap, or missing instrument |
| Utility records | Mapped poles, conduit, and other plant as published | Place the line relative to known plant | Missing owner, schematic-only geometry, or a conflict |
| Preliminary route | Connected centerline with segment IDs | Carry the line into design and field packets | Any segment still labeled inferred |
| Planning quantities | Footage, structure counts, and crossing counts from the line | Budget and crew sizing at planning level | A quantity driven by an unresolved trigger |

### Imagery and the Land Base

Imagery is the picture the line has to survive. The USDA Farm Production and Conservation Business Center, Geospatial Enterprise Operations, administers the National Agriculture Imagery Program. Recent NAIP specification is 60-centimeter ground sample distance, with 2025 collections delivered at 60 cm or 30 cm depending on the state, and a USDA specification that well-defined points tested shall fall within 4 meters of true ground at a 95 percent confidence level (CE95). That pixel can show a driveway. It cannot locate a pole face to construction tolerance.

We record the acquisition year on the layer, not only the download date. Leaf-on canopy hides shoulders. A tile with cloud cover, which NAIP allows up to 10 percent per quarter-quad, is not a clearance photo. If the last known road reconstruction is newer than the image, the photo is a history layer. It stays in the package. It does not control the line.

### Parcel, ROW, and Utility Records

Parcel GIS is a tax-map representation. It can tell us where the line may leave public road frontage and where a private easement question exists. County cadastral disclaimers say the same thing in plainer language: the polygon is not a survey. We treat it as 1 screening layer with a named source date, and we refuse to let that polygon stand in for a recorded occupancy when the instrument is missing. Access stays unresolved until the controlling record confirms it.

ROW and easement layers are only as good as the instrument behind them. A county "ROW" polygon is often a cartographic offset from centerline, not a recorded occupancy. We keep that distinction on the feature. Utility records help us place the preliminary line relative to mapped plant, and they fail in a different way: many electric and telecom GIS files are schematic. A pole that snaps to the parcel line in the county viewer may sit inside the lot in the field. That offset is a field trigger, not a snap tolerance we "fix" at the desk.

### Preliminary Route and Planning Quantities

The preliminary route is a connected centerline with stable segment IDs. Those IDs are the only thing that should survive into the field packet and the later design file. We do not dissolve them to make the map prettier, because those IDs are the only join key the field packet and the later design file can share without losing lineage. Each segment carries installation assumption (aerial or buried) as a planning label, not as a construction method. Method is confirmed after the physical questions close.

Planning quantities are derived from that centerline. Route footage and structure counts come off the same geometry. Crossing counts are listed separately so a bridge or railroad is not buried inside a mileage total. They are budget tools. They are not a unit-price schedule. If a quantity is driven by an unresolved trigger, we flag the quantity rather than round it into a confident total. For clients who want that layer register and preliminary route handled as an engineering product, that is what our [GIS mapping services](/services/gis-mapping-services/) cover.

## Accuracy Limits of Imagery, Parcel, ROW, and Utility Layers

Accuracy follows the weakest accepted layer, not the map's zoom. A desktop route that looks sharp on a 4K monitor can still sit 4 meters off true ground, which is the USDA NAIP CE95 specification. We write the limit on the line. We do not let display scale become a measurement claim.

The American Society for Photogrammetry and Remote Sensing Positional Accuracy Standards for Digital Geospatial Data, Edition 2, Version 2 (2024), reports product accuracy in RMSE in ground units. Edition 2 eliminated references to the 95 percent confidence level as an accuracy measure and raised the minimum checkpoint count for a product accuracy assessment to 30. That standard governs imagery and elevation products we consume. It does not convert a desktop route into an ASPRS-class survey. We cite it so a reviewer knows which language the source imagery was built under, and so nobody treats a 60-centimeter pixel as a stake.

The FGDC Content Standard for Digital Geospatial Metadata, FGDC-STD-001-1998, is how we expect identification, data quality, spatial reference, and distribution to be organized when a source actually carries metadata. Many county parcels do not. Missing metadata is a limitation, not a license to assign a likely CRS because the overlay "looks close." We quarantine unknown coordinates until evidence supports a definition.

Horizontal error stacks. A 4-meter NAIP CE95 can sit beside a cadastral line compiled at 1:2,400. The United States National Map Accuracy Standards, issued by the U.S. Bureau of the Budget on June 17, 1947, set 1/30 inch at publication scale for maps larger than 1:20,000, which is about 6.7 feet on the ground at 1:2,400. A schematic utility offset is a third location. Those sources can point the same preliminary line at different physical places. The package has to show that stack. Hiding it in a single "accurate to the basemap" note is the failure. When two sources disagree, we do not average them. We keep both records and label the conflict, then write the field trigger that will settle it once a person can see which source is wrong.

One thing I still push back on in our own GIS work: a desktop line with no confidence class. Visual polish is not a survey. A package can look complete at the desk and still place the pole line on the other side of the pavement once someone stands there. The geometry is not "wrong" as GIS. It was asked to decide something it could not see.

## What Telecom Desktop Routing Services Cannot Decide

Desktop work cannot confirm pole class. It cannot read attachment height. It cannot measure buried utility depth. It cannot prove usable shoulder width from a 60-centimeter pixel when grass and parked cars occupy the same cells. Those 4 physical items require a person at the structure or a locate.

Legal access is the other closed door. Parcel GIS flags the question. It does not answer it. A recorded easement or a highway occupancy permit can answer it. An owner letter can too. A colored polygon cannot. We leave access in unknown or reported until that record arrives, even when the line "fits" the tax lot.

A GIS utility layer is not a substitute for a one-call ticket. State damage-prevention statutes still require notice to 811 before excavation. We will plot published plant so the preliminary line can avoid an obvious conflict. We will not certify clearance. Subsurface investigation, when the owner later funds it, follows its own method. Desktop routing does not start that method by snapping to a county water main.

Make-ready conclusions are out. So are pole-loading results, splice-closure locations that depend on measured slack, and restoration limits that depend on pavement type the photo cannot classify. The package can name those as later engineering stages. Naming them is not completing them.

> **Self-critical note:** our own maps get dangerous when uncertain layers accumulate into a polished trace. We counter that by showing source dates and confidence classes at the feature, then sending field effort at the assumption that can move the line. Detail never upgrades the record.

## Hand the Desktop Package to Field Survey

Hand off when the preliminary route is continuous and the source register is complete. Remaining decisions are named as field triggers. We do not send a crew to walk the whole county. We send them to the 1 or 2 locations that can move the line.

The field packet is a subset of the desktop package, not a new drawing. It has to answer a question the desk already wrote. The field survey assignment carries those questions. Results return to the same segment IDs so the desktop line can be confirmed or shifted. Rejected work keeps the ID so lineage is not lost.

- **Segment ID:** the stable key from the preliminary route, copied into the collector form before the crew leaves.
- **Question to close:** one decision the visit must answer, written as a measured value or a yes/no, not "check the area."
- **Source excerpt:** the imagery chip or parcel flag that created the question, so the crew is not guessing why they are there.
- **Return format:** a geotagged photo and a measured offset, or a blocked-access note, attached to the same ID.

A visit that comes back as "looks fine" is a wasted day. We would rather have a blocked-access exception with a next action than a verbal clearance that never hits GIS. The desktop package is not finished when the crew is scheduled. It is finished when each trigger has a returned disposition and the quantities that depended on those triggers are recalculated.

What comes back does not automatically freeze the corridor. Freeze is a later planning decision. The desktop-to-field loop only upgrades confidence on the segments that were tested. Untested inferred segments stay inferred. That is the honest state to hand the planning workflow.

Returned dispositions are few on purpose. Confirm leaves the desk geometry in place. A shift moves the centerline and recalculates the quantities that depended on it. Reject withdraws the segment and pulls the alternate from the planning record rather than inventing one on the tablet. Blocked access is not a confirm. It is a next-action note with a named owner.

## Buy the Desktop Package by the Decision It Can Support

**Rural cooperative or single-state ISP under 5,000 passings:** buy a bounded desktop package on the serving area you actually intend to field this season. Require the 6-layer register and a field-trigger list before anyone walks a mile. Do not fund a county-wide "route study" that is only a pretty line. Keep the alternate off this sheet; this product is the evidence pack for the line you already need to test.

**Overbuilder on a 2026 BEAD schedule:** freeze the desktop package as a named revision before field crews are let. Grant closeout will ask what geometry was assumed. A line that moved in GIS while the crew was out, with no revision ID, is a records failure. Segment-based release lets one serving area field while another is still in desktop review. Do not let planning quantities become the bid form until the triggers that drive them are closed.

**Engineering firm delivering to an owner GIS:** use the owner's schema and receiving test as the acceptance basis. Preserve source dates and confidence classes even when they do not fit a required domain. The owner can reject an inferred line. They cannot reconstruct a source you flattened. Draftech keeps this engineering in-house so that interpretation stays with the people who will also write the field packet.

The useful outcome is not a longer GIS line. It is a package a reviewer can audit, because the reviewer can trace sources and limits, then the preliminary route with its planning quantities, then every question still open. A PM who was not in the GIS session should be able to see why a crew is being sent to one crossing and not the whole spine.

That is the problem this service removes. A polished centerline with no source date is the first failure. A tax lot used as ROW is next, and it is the same failure that sends a crew to the wrong side of the road. We also see schematic utility snaps treated as locates, plus quantities that hide unresolved triggers. Draftech keeps the desktop route in-house so those four failures stay on the register, where they can still be fixed before anyone rolls a truck.

Active in 24 states. Available across [all 50 U.S. states](/states/). If a live serving area needs the desktop package before field is funded, reach out at [info@draftech.com](mailto:info@draftech.com).

An owner that wants the desktop assumptions tested on a qualifying route can start with one bounded segment. Draftech will [engineer the first 20,000 linear feet at no cost](/free-design), from feasibility and field survey through permit approval. Our owner reviews each request before we commit the package.

> **Talk to our GIS routing team about your desktop package.** [Request a review of the layer register and field-trigger list](/#dt-contact) before the crew is scheduled.

## Frequently Asked Questions

### What is included in a telecom desktop routing package?

A desktop route package contains at least 4 source classes: current imagery, parcel GIS, ROW or easement layers, and available utility records. Those layers support a preliminary route and planning quantities, each tagged with a source date and a confidence class. The package also carries a field-trigger list. It is not a staked construction set.

### How accurate is a desktop fiber route?

Accuracy follows the weakest accepted layer, not the map's zoom. USDA NAIP orthoimagery is specified at 60-centimeter ground sample distance, with well-defined points required to fall within 4 meters of true ground at a 95 percent confidence level (CE95). Parcel GIS is often compiled at map scale. We write that limit on the line rather than implying survey grade. A sharp screen image does not change that number.

### Can parcel GIS prove right of way?

No. A cadastral parcel polygon is a tax-map representation. It can flag where a route may leave public road frontage. It cannot prove legal occupancy. We treat parcel GIS as 1 screening layer with a named source date. Access stays unresolved until the controlling record confirms it. A tax lot is not a ROW exhibit.

### What can a desktop package not decide without fielding?

Desktop work cannot confirm pole class, attachment height, buried utility depth, or usable shoulder width. It also cannot close a legal access question. Those 4 physical items plus access require field or owner evidence. We list each as a field trigger instead of filling the gap with a confident line. Hiding those gaps on a polished map is the failure.

### When should the desktop package hand off to field survey?

Hand off when the preliminary route is continuous and the source register is complete. Remaining decisions are named as field triggers. We send the crew to the 1 or 2 locations that can move the line, not the whole county. The field packet carries segment IDs and the question each visit must answer. Results return to those same IDs.

### Does Draftech engineer the desktop route in-house?

Yes. Desktop routing is in-house Draftech engineering. We assemble the layers and write the field-trigger list under our own QA. When construction is in scope, Draftech-managed subcontract crews deliver full turnkey. We do not claim a self-perform crew today. Active in 24 states. Available across all 50 U.S. states. Email the layer register to info@draftech.com before the crew is scheduled.