Mission Report · MapMyIndia [Gtropy]Project case study
IOCL GeoRTD Pipeline
Thirty thousand routes is not a data problem you solve once. It is a pipeline you have to trust every time it runs.
- Status
- Active
- Owned
- Frontend · UI/UX · cross-functional delivery
- Routes injected
- 30,000+
- Stack
- Geospatial data
- Amazon S3
- TypeScript
ResultsMeasured
- 30,000+
- Routes injected · Amazon S3 pipeline
- Route accuracy against ground truth
- Pipeline throughput per run
- 30,000+ routes injected
I decided
- The UI/UX
I built
- The frontend; 30,000+ routes injected into the S3 bucket
With the team
- Cross-functional delivery
Geospatial route data creation for Indian Oil: GeoRTD generation at scale.
Indian Oil moves LPG by road across thousands of routes. Every one of those routes needs geospatial reference data (the GeoRTD) before tracking, geofencing and playback can work against it.
The IOCL operations and telematics teams whose tracking products consume the route data, and the internal team maintaining the pipeline.
Route creation at this volume cannot be a one-off import. Sources change, routes get corrected, and a bad batch has to be findable and reversible. The pipeline had to be designed as something that runs repeatedly, not something that ran once.
Generate route data for 30,000+ routes into a form the platform can consume, at a quality the downstream products can trust, with a process that can be re-run when the inputs change.
If every route carries provenance (what it was generated from, when, by which run), then errors are a data question rather than an archaeology exercise, and the team can trust the pipeline enough to keep running it.
Batch generation into Amazon S3 as the system of record, with validation before injection rather than after. Treat the bucket as the contract between the pipeline and the products that read from it.
Correctness of the route geometry first, then throughput, then the tooling that makes re-runs cheap. A fast pipeline that produces routes nobody trusts is a liability.
The operator-facing surface is a run: what was processed, what was rejected and why, and what changed against the previous run.
Logs and diffs presented as a report, not a console. The question a reviewer asks is 'what is different', and the interface answers that first.
Route data generated and injected into an Amazon S3 bucket: 30,000+ routes.
In progress.
30,000+ routes injected so far; the pipeline is live and still being measured. What gets measured: route accuracy against ground truth, and throughput per run.
Data pipelines are products with a user of one team. They deserve the same discovery (what does the person running this need to know, and when?) as anything customer-facing.