How precise is the network map? It depends on which GPS made it

The manhole the design places at that point — does the crew find it there, or eight metres further on, under the asphalt resurfaced last year? Who took that coordinate, with which device, with what declared error that day? Most networks have no written answer, because the position of a network element is not a single fact: it is the sum of who surveyed it, with which technique, and how long ago.

The Recommendation, with the right number

ITU-T Recommendation L.94 (01/2015), Use of global navigation satellite systems to create a referenced network map, approved on 13 January 2015 by Study Group 15, sets out guidelines for creating, operating and maintaining a telecommunication network map using satellite positioning. The Scope, verbatim: “The purpose of this Recommendation is to provide general implementation guidelines regarding the creation, operation, and maintenance of the telecommunication network map by using global navigation satellite system (GNSS) and geo-referenced systems.” Since 15 February 2016 the number has changed: the record states that “Former ITU-T L.94 renumbered as ITU-T L.262 on 2016-02-15 without further modification and without being republished” — same text, new number, never republished under it. The PDF downloaded today still carries, in its watermark, the L.94 header.

What has to appear on the map

Clause 6.1 lists, as typical information content, a set of items; among them, verbatim: “the cable routing and the type of infrastructure”, “the length of each section”, “the owner of each section”, “the status of infrastructure use, for example empty or occupied duct”, “the dimensions of the duct, cable, optical closure and optical cabinet”. Clause 6.2 sets the minimum elements to be shown: “central offices, poles, manholes, optical closures, optical cabinets, ducts and tunnels” — the same assets covered in inspecting underground chambers. Taken one at a time they look obvious. Taken together, they are a list of what rarely lives in one place: ownership of a shared section is usually a contractual fact, not a technical one, and sits in a different archive from the one holding the manhole’s elevation, the as-built.

GNSS or differential: the difference is measured in metres

The weak point of any referenced map is the most used and least defined word: GPS. The Recommendation draws a distinction. Plain GNSS, clause 9: “a GNSS has a positioning accuracy of 5 to 10 metres, because there must be a relative line of sight between the GNSS antenna and at least four satellites” — and in urban areas, between buildings and overpasses, the margin gets worse still. DGNSS, defined in clause 3.2.1, corrects the position against a known reference station: a technology that delivers better accuracy than plain GNSS, “from 5-10 metres down to a few metres […] to about 10 cm in case of the best implementations.” Clause 9 puts it as an explicit recommendation: “In order to have reliable positioning both in urban and in non-urban areas, with an error from 1 to 10 cm, it is recommended to use differential GNSS.” Between plain GNSS and DGNSS there can be eight metres of difference — the distance between finding the manhole and digging where it is not. Which of the two was used for a given coordinate is almost never stated on the map itself.

Two views, one dataset

Clause 7 requires two representations of the same network, not one: “Network maps should be visualized both in geographical information system (GIS) format for geographical view, and in a computer aided design (CAD) system, for schematic view.” The geographic view says where; the schematic view says how it connects. Networks with only one — usually the CAD, because that is the design’s — arrive on site without the map they need.

Who brings the data in from the field, and how

The survey device, clause 8, is not just any phone: “should be a mobile handheld device, compliant with [ITU-T L.69]”, a separate Recommendation on field handheld requirements. Clause 11 sets out the procedure when the map does not yet exist: first “The survey process”, where data gathered on site “are recorded in field and loaded in real time to the database”; then “The back office process”, where an operator “should access the district database, validate collecting data and transfer data on the final project”. Underground assets need a third step: “georadar with GNSS (or differential global navigation satellite system (DGNSS)) should be used” — the same gap left by ducts never surveyed after installation. All three streams must converge on the same coordinate system, “such as the international standard world geodetic system – 1984 (WGS-84)” — otherwise the georadar survey and the technician’s handheld survey tell two slightly different maps.

The tag, the database, and the status that changes

Clause 12 closes the loop between the physical object and the digital record: in the local database “it should be possible to associate in-field information directly to the network element, recorded with an ID tag applied to it, as described in [ITU-T L.64]” — the physical tag linking the manhole to its row in the database, the same principle behind identifying a cable by vibration. In the remote database you select the area and filter by layer: “you could see only the telecommunication copper network or only empty ducts.” But position is not enough: clause 10 requires the map to also show the element’s status, “such as new, old or to be changed”, and that “The status of the network elements should be upgraded when finishing a construction or repairing work”. The update time, the Recommendation adds, “should depend on the network element type” — without setting one. It is the easiest line to promise in a tender and the hardest to check at acceptance: a map updated in March, after work carried out in June, is not wrong on paper. It is simply out of date.

See the service · Talk to an engineer

The Italian appendix

An appendix, headed “Italian experience regarding geo-referencing system”, describes a platform with GNSS survey from a mobile terminal: “Using the GNSS-enabled mobile terminal, it is possible to collect data of an asset and capture its GNSS position. Once the operation is completed, the device automatically sends the data to the cloud.”

What we do not know

Compliance with ITU-T Recommendations is voluntary: “Compliance with this Recommendation is voluntary.” The appendix on the Italian experience says so at the outset: “This appendix does not form an integral part of this Recommendation”; illustrative material from a platform not named in the public text, not a requirement. We do not know whether that platform is still on the market ten years on, nor whether it describes a practice now widespread among Italian operators: we cite it as a historical precedent, not a current prescription. And we have not found — we neither state nor rule it out, not having checked an Italian primary source — an Italian obligation requiring DGNSS for this survey: anyone who wants it written down has to put it in the specification themselves, perhaps tying it to the layers already provided for by the SINFI register.

Two threads, applied

First thread: the survey method — GNSS or differential, with what declared margin —, the coordinate system, the minimum elements to be shown and the maximum time to update status after work all become lines in the specification, not a generic GPS survey entry. At acceptance, the check is that declared accuracy is the one required, not the factory default of whichever receiver was used that day.

Second thread: the GNSS survey, the georadar report, the CAD design, the GIS register and the physical tag on the asset stop being five separate archives and become, with CSIDIA, the group’s other company, a single map of the network on which an AI runs the diagnosis and the crew closes the fault: because the diagnosis that matters — a manhole that has moved, a buried route that differs from the design, a stretch never surveyed — comes from comparing successive measurements tied to the same identifier, what clause 12 calls the ID tag. Within the client’s perimeter: on-premise, on standalone machines with no deep integration, or a dedicated cloud with a data centre in Italy, always with shared management.

From the site visit, at no cost, comes the list of your network’s GNSS-surveyed points — manholes, covers, closures, cabinets — and for each one: which technique was used, when, and with what declared accuracy. Including the coordinates that, once checked, simply are not there. The point on the map the crew will follow tomorrow morning: who measured it, and with what margin of error?