Skip to main content

National Road Network Management Platform

National pavement management platform (internally referred to as PMMS) for road-condition assessment, PCI calculations, GIS-based distress recording, reporting, and infrastructure planning.

Enterprise · 2025 — Present · Backend, Spatial Data & Production Infrastructure Engineer

Technology

  • ASP.NET Core
  • C#
  • .NET 9
  • gRPC
  • SQL Server
  • SQL Server Spatial
  • EF Core
  • GIS
  • OAuth 2.0 / OIDC
  • N-Tier Architecture
  • Identity

Results

  • 12000+ KM Road Network
  • 99.9% Audit Compliance
  • 75% Query Speedup

Overview

National road networks run to thousands of kilometers. This platform is what a government team uses to inspect, catalog, and evaluate pavement distress across all of it — one road segment at a time, fed into a system that actually scales.

The architecture is strict N-Tier for a reason: Core domain models, Infrastructure data access, and WebApp presentation layers stay cleanly separated, so ASTM-based pavement condition calculations and spatial GIS queries don't end up tangled with the high-volume SQL Server workload underneath them.

Field inspectors capture distress data offline-first from the road, syncing once connectivity returns — the API layer has to reconcile out-of-order submissions and duplicate segment reports without corrupting the condition history for a given stretch of road.

gRPC handles the internal service-to-service contracts between the assessment engine and the reporting layer, while public-facing endpoints stream large spatial result sets over server-sent events instead of paginating — a road segment map with thousands of geometry points doesn't fit comfortably into a single REST response.

The challenge

Problem: A coordinate-system bug (UTM Zone 37N to WGS84 reprojection) had been silently corrupting spatial data for an unknown period — pavement condition markers were rendering in the wrong location on the map, and nobody could say how long it had been happening or how many records were affected.

Approach: Wrote a reprojection audit script that re-derived the correct WGS84 coordinates from the original raw survey data (rather than trusting the already-corrupted stored values), then ran it as a one-time backfill migration inside a transaction so a failure partway through wouldn't leave the dataset in a half-corrected state.

Result: Restored accurate coordinates across 27,000+ geometry records, fixing map rendering and spatial proximity queries network-wide — and added a coordinate-range validation check at the ingestion layer so a reprojection bug like it can't silently pass through again.

Key features

  • Domain-driven pavement condition workflows
  • ASTM-based PCI calculation workflows
  • GIS/spatial data integration for geo-referenced distress logging and road segment breakdown
  • REST and gRPC APIs streaming large spatial result sets over server-sent events
  • High-volume SQL Server spatial workloads and reporting pipelines
  • Single sign-on via OpenID Connect and OAuth 2.0
  • Production deployment ownership with a self-authored 26-case production-readiness standard
  • Role-based access control with ASP.NET Core Identity for field inspectors and administrators
  • Offline-first field data capture with conflict-resolving sync on reconnect
  • Coordinate-range validation at the ingestion layer to catch reprojection errors before they reach the database

← All projects