Â
- NTES live API (
enquiry.indianrail.gov.in/ntes/SearchTrain?trainNo=) — unofficial but scriptable, gives live train search results (used by DataMeet community).
Out of your 9 requirements, only #1 (timetable) has a genuinely usable public dataset, #2a/#6/#9 have real facts you can ground your work in but no downloadable table, and #2b, #3, #4, #5, #7, #8 are inherently synthetic by design (this is expected and fine — even the PS itself says you'll simulate/mock this).
What you actually need:
- Section-wise train timetable — every train (number, name, category) that passes through a specific block/section, with scheduled arrival/departure times
- Train priority/category classification — so you know which trains can least afford delay (Rajdhani/Shatabdi/Vande Bharat > Mail/Express > Suburban/Passenger > Freight, roughly — though exact precedence rules vary by zone/route)
- Traffic density per section — how many trains (of each type) pass through in a given time window, so you can spot low-traffic windows for maintenance
Â
Train Priority Tiers (for your block-scheduling logic)
Priority | Train Type | Why it matters for blocks |
P1 — Highest | Rajdhani, Shatabdi, Vande Bharat, Duronto | Fully scheduled, high-visibility, heavy punctuality penalties if delayed. Blocks must never intersect these paths. |
P2 | Mail/Express trains (long-distance) | High passenger load, tightly timetabled. Avoid unless no alternative window exists. |
P3 | Suburban/local trains (peak hours) | Extremely high frequency (Mumbai locals run every few minutes in peak hours) — blocking here causes cascading commuter disruption. Peak hours (~7–11 AM, ~5–9 PM) should be treated as near-unblockable. |
P4 | Suburban/local trains (off-peak) | Same trains, but off-peak windows (late morning, early afternoon, late night) are your prime scheduling targets — lower frequency, lower disruption per block. |
P5 | Passenger trains (slow, unreserved) | Lower priority than Mail/Express, but still carries passengers — moderate disruption cost. |
P6 — Lowest (movable) | Goods/freight trains | This is exactly why your PS explicitly calls out "goods train forecast" — freight schedules are more flexible/reschedulable than passenger trains, so they can often be shifted around a block rather than the block being shifted around them. |
How this should actually work in your system
Don't treat this as a fixed static ranking — build it as a disruption-cost weight that feeds your optimization objective function:
disruption_cost(window) = Σ (train_priority_weight × probability_of_delay × passenger_load_factor)
For every train scheduled to pass through that section during that window, you calculate:
Then you sum this up across every single train affected during that window, giving you one total "cost" number for that window.
passenger_load_factor— how many people are on that train at that time (a 6 AM peak local carrying 4,000 people ≠a near-empty 2 PM local)
probability_of_delay— if we block this window, how likely/how badly does this specific train actually get delayed or rerouted? (A train passing right through the middle of the block = 100% affected. A train passing 10 minutes after the block ends = maybe 0%, if there's buffer.)
train_priority_weight— how important is this train (Rajdhani = very high, off-peak local = low, goods = lowest)
- P1/P2 trains: essentially hard constraints — the AI should treat these as blackout windows, not "expensive but allowed."
- P3 (peak suburban): very high soft cost — technically blockable in emergencies, but your optimizer should almost never choose these windows voluntarily.
- P4 (off-peak suburban) + P6 (goods): your scheduler's actual "playground" — most block windows in a working railway are carved out of these.
- Night/pre-dawn windows (roughly 12 AM–5 AM in most sections) — lowest traffic density overall, but even here you'll have a few scheduled mail/goods trains, so it's not zero-conflict, just lower-cost.
One important nuance for Mumbai specifically
Since you're building this for Mumbai CST division, suburban traffic is your dominant constraint — Mumbai locals carry far more daily passengers than Mail/Express trains on the same corridor. So your priority weighting should reflect passenger volume, not just train "class" — a crowded suburban local in peak hours may deserve a higher disruption weight than a lightly-loaded long-distance Mail train passing through at the same time. This is worth mentioning in your pitch as a "we didn't just copy generic train-class hierarchy, we adapted it to Mumbai's actual traffic composition" point — it's a strong differentiator for judges.
2ND PS SELECTION:-Â