FTTH Network Intelligence.
NORTHBRIDGE / SPATIAL NETWORK OPERATIONS
Spatial infrastructure intelligence for fibre connectivity, serviceability, capacity and network quality.
Professional context
The project draws on my experience with FTTH network data, spatial databases, GIS workflows and backend systems at ipNX Nigeria Limited as GIS Analyst (Senior Officer) & Backend Developer.
The displayed network uses independently prepared demonstration data. No production customer records, infrastructure coordinates or internal systems are included.
Connectivity is an operational question
A nearby terminal does not guarantee a working connection. The equipment hierarchy, physical fibre route, deployment state and available capacity must agree. Northbridge brings those checks into one map, with an inspector that explains each result.
One network, several operational views
The workspace opens over Lagos, Nigeria, with a real OpenStreetMap basemap. Network, serviceability, capacity and QA modes share the same records. Use Focus network for an infrastructure view or Reset extent for geographic context.
Spatial data model
Connected infrastructure, explicitly modelled
The PostgreSQL/PostGIS schema separates service areas, deployment projects, equipment, fibre segments, premises, service connections and QA results. Devices carry the upstream parent relationship; fibre segments hold physical routes between endpoints. A premise’s terminal assignment and an active service connection are distinct relationships.
Foreign keys protect canonical relationships. State and commissioning checks, non-negative capacity, unique endpoint pairs and valid non-empty geometry constrain accepted records. GiST indexes support spatial queries; parent and terminal indexes support traversal and service lookup.
Follow the path to the core
Select a premise, then choose Trace network. The map highlights its upstream route and the inspector lists the access terminal, splitter, cabinet, ODF, OLT and central office. Each physical segment has a length and cumulative total.
Co-located equipment transitions add no cable length. Separated equipment requires one valid deployed route. Missing or ambiguous links, cycles, invalid parent types and endpoint mismatches return an incomplete path rather than a plausible-looking answer. The verified reference path measures 820 metres. The dashed premise-to-terminal line indicates proximity, not an installed drop cable.
Passed is different from serviceable
84 of 99 premises are passed; 68 are serviceable under the current rules. Passed requires a deployed service area, a deployed assigned terminal within 160 metres, zone membership and a valid upstream path.
A new connection also needs a spare terminal port. An existing active connection remains serviceable at exact full capacity; an overloaded terminal constrains every attached premise. Planned infrastructure, absent paths, excessive distance and capacity constraints have separate statuses.
Capacity with network context
Capacity mode distinguishes available, moderate, high-utilisation and full assets. Selecting equipment exposes total capacity, occupied connections, available capacity, utilisation, active premises and assigned premises.
The network contains 41 active service connections and 20 usable spare terminal ports. Terminal occupancy counts active service connections. Cabinet and splitter capacity counts direct child equipment; downstream active premises are reported separately. Usable spare ports require a valid, commissioned and deployed upstream path.
Network integrity at a glance
35 open exceptions cover topology, geometry, capacity, attributes and connectivity. Filter by severity and rule category, select an issue, and inspect the affected asset on the map.
Checks detect duplicate identifiers, missing geometry, invalid endpoints, absent commissioning, impossible capacities, broken parents and disconnected premises. The inspector explains the failed rule, shows network context and offers a trace where a path can be evaluated. Rejected records remain available for investigation without weakening canonical database constraints.
Application architecture
Shared rules, distinct delivery paths
Python/Shapely resolves spatial relationships and bounded graph traversal. A visited set prevents cycles from hanging a request. FastAPI exposes filtered asset and premise lists, traces, downstream equipment, cabinet capacity, QA results and summary metrics, with bounded pagination and explicit error responses.
The hosted map reads a versioned network export. The source package includes the local read-only API and the PostGIS schema, loader and analytical queries as a separate database path.
Engineering outcomes
One set of rules supports connectivity, serviceability, capacity and quality views. Automated checks cover valid and incomplete traces, physical lengths, exact-full versus overloaded capacity, API filtering, pagination and errors. Presentation coordinates are separate from the metre-based geometry used for analysis.
Native selectors and text detail panels supplement the map. Distinct equipment symbols, contextual legends and visible focus states support navigation; on mobile, compact metrics and a collapsible asset sheet preserve space for the network.
Scope and next steps
The implementation focuses on spatial modelling and operational workflows. It does not model fibre-core allocation, optical budgets, resilience, access control or organisation-specific business rules. Geographic placement provides Lagos context; route measures use the authored local metre plan and do not represent surveyed street alignments.
Next: validate the PostGIS path in a running database, connect the API to explicit staging and canonical views, and extend the model with fibre-core allocation and outage impact analysis.