← Back to Blog

Why We Built the Bridge Between the OTDR and the GIS

Every fiber engineer has done this drive at least once: OTDR says the break is 6.234 km down the span. You know roughly which road that span runs under. You don't know which yard, which easement, which side of the intersection. So you drive to your best guess, walk the ROW with a shovel and a hunch, and hope.

That gap — between a number an OTDR gives you and a place you can actually point a crew at — is where this company started.

Two tools, never introduced

Here's the part that's strange when you say it out loud: the fiber industry has spent decades building two entirely separate categories of software and hardware, and they've never talked to each other.

OTDR vendors — EXFO, VIAVI, AFL — build test equipment. It's excellent at what it does: send light down a fiber, measure what comes back, tell you a fault is some number of kilometers from the launch point. That's the whole job. The device doesn't know where the fiber physically runs, so it can't know where that number lands on a map.

GIS and OSS platforms — Esri, IQGeo, OSPInsight, VETRO, 3-GIS — solve the other half. They document where your plant is supposed to be: splice cases, vaults, conduit runs, node locations. That's their whole job too. None of them read a raw .sor trace file. None of them are built to take a correction back from a technician standing at a splice case with a GPS reading and a piece of information the system didn't have five minutes ago.

Two well-built, expensive, essential categories of tooling — and a seam between them that nobody ever closed. Not because it's not worth closing. Because it's nobody's core job. It's not an OTDR company's job to know your plant geometry. It's not a GIS company's job to parse test equipment file formats. So it just didn't happen.

What closing it actually looks like

Fiber Damage Locator reads the same .sor file your OTDR already produces. It resolves that distance against whatever plant data you already have — a full GIS export, a spreadsheet, or nothing at all but a hand-drawn route on a satellite map — and hands back a GPS coordinate and a street address. Not "somewhere on this span." An address a dispatcher can hand to a crew.

Then it does the part that made us realize this was a bigger idea than a fault-locator: when a crew builds something in the field — a new splice case, a splitter, a tap — Manual Draw captures it at its real GPS coordinate as they go, with the OTDR trace proving the loss at each point. That record exports as one clean package: CSV, Excel, GeoJSON, a labeled PDF map. Ready to hand back to whoever owns the GIS. The same tool that reads a number off your OTDR also writes clean data back into your system of record. The bridge runs both directions.

Why this has to be an everyday tool, not a drawer tool

We didn't want to build something that only earns its keep on the worst day of the quarter. A tool that only gets opened during a major outage is a tool that gets forgotten, under-trusted, and eventually skipped for "just drive out and look."

So the design goal was: every fault response should run through it, and every splice case a crew builds should get captured through it — not as a special procedure, but as the normal way the job gets done. Every use makes the underlying route data a little more accurate for the next incident. That's the difference between a specialty tool and something that becomes part of how a team actually works.

Where this goes next

We built Fiber Damage Locator because nobody else was going to connect these two worlds — not because either OTDR hardware or GIS platforms did anything wrong. They're both good at their actual jobs. The gap exists because it was always going to take a third party focused on nothing else to close it.

That's also why we're actively looking to partner directly with OTDR hardware manufacturers and GIS/OSS platforms, not just interoperate with their file formats from the outside. The long-term version of this isn't "export from your GIS, upload to us" — it's trace data and as-built corrections flowing between systems with no manual step at all. If you build OTDR hardware or a GIS/OSS platform and this sounds like a conversation worth having, reach out — we'd like to build that future together instead of around each other.

In the meantime, if you're the one standing at the truck deciding which way to drive: see how Fiber Damage Locator works, or open a trace right now in our free OTDR Viewer and see what a .sor file actually has to say.

Related Tools