National Weather Big Data Analytics Platform
Ministry of Earth Sciences (MoES) · Disaster Management · Software
The verification idea is genuinely good and cross-checking citizen claims against real meteorological data is the differentiator — but sort out where your reports will actually come from before you write any code, because the statement assumes access that no longer exists.
What it actually is
During a flood or a heatwave, people post photographs and reports online long before official observations confirm anything, but that information is scattered and much of it is wrong or recycled from an older event. The ask is a platform that collects those public weather reports automatically, works out which are genuine, sorts them by event type and location, and puts them on a dashboard.
What to build
An ingestion and verification pipeline collecting weather-tagged public posts and citizen reports with the metadata the statement lists — timestamp, city, state, coordinates, imagery and event category — into a central store, then a verification layer that is the actual substance of the project: near-duplicate detection catching the same photograph recirculated across accounts and across past events, a classifier assigning each report to the event categories named including rainfall, thunderstorm, flooding, heatwave, fog, dust storm and strong wind, and a plausibility check cross-referencing each claim against independent meteorological evidence for that place and time so a claimed cloudburst in a district with no rainfall signal is flagged rather than mapped — surfaced through a dashboard filtered by date, event, location and verification status.
Smallest thing that wins the room
Feed in a batch containing a genuine flood report, the same photograph recycled from a flood three years ago, and a fabricated claim, and show the pipeline mapping the first, flagging the second as a duplicate and rejecting the third because the rainfall record for that district contradicts it.
How crowded this one gets
A guess, projected from the 2025 statements — the last year where both the submission counts and the winners were published.
Quieter than 45% of the 226 · #125 of 226 by expected field
A normal-sized field. Your idea has to be good, not miraculous.
Why: central ministry statements sat below the average.
This is a guess, not a fact
Nobody has published 2026’s numbers yet. This is an analysed estimate from last year’s pattern, so please do not take it as the truth — check the live counter on the SIH portal before you decide anything. The range covers the middle half of likely outcomes, so one statement in two lands outside it. Entry closes at 500 ideas per statement, so no range goes past that — a statement that reaches the cap fills and shuts rather than drawing an unlimited crowd. The model reads only three things a team can see before choosing — software or hardware, the theme, and what kind of body posted it — and those explain about a quarter of the variation in last year’s field sizes (R² 0.25 on held-out statements). Trust the band more than the number, and the ordering more than either. It cannot see how good your idea is, which is the part that actually decides it.
The scores
The number is the shorthand. The line under it is the reason.
Acceptance potential
3/5Crowdsourced disaster reporting is a familiar shape, but the verification angle rescues it — cross-checking a citizen claim against the actual meteorological record for that place and time is a genuinely clever and demonstrable idea that most teams building this will skip in favour of a nicer map.
Feasibility
3/5The processing side is straightforward and meteorological data for cross-checking claims is genuinely public, but the collection side is the problem — bulk programmatic access to the major social platforms is now either expensive or restricted and scraping them breaches their terms, so the primary source the statement is built around is not freely available.
Innovation scope
3/5The pipeline, the metadata, the machine learning tasks and the dashboard filters are all named, but how you actually verify a report — which is the hard part and the point of the system — is left completely open.
Clarity
3/5The ingestion, the event categories and the dashboard features are described clearly, but the verification requirement sits in a single line despite being far harder than everything else combined, and no accuracy target or definition of a verified report is given anywhere.
Effort
HeavyMulti-source ingestion, media and text deduplication, event classification, cross-referenced plausibility checking and a filtered analytics dashboard is five components, with the verification layer alone being a substantial piece of work.
Demo-ability
MediumA map filling with citizen reports is engaging and the moment a recycled photograph gets caught is genuinely satisfying, but the demo depends entirely on you having curated a batch that contains the failure cases worth catching.
In its favour
- Green flag: Cross-referencing a citizen claim against the independent meteorological record for that location and time is the strongest verification signal available and it is entirely buildable from public rainfall and satellite data — this is the idea that makes the project worth doing
- Green flag: Perceptual hashing catches recycled disaster photographs reliably and cheaply, and recirculated imagery from past events is genuinely the dominant form of weather misinformation
- Green flag: The event categories are enumerated in the statement, so your classification taxonomy is fixed by the sponsor rather than chosen
- Green flag: A verified-versus-unverified map is a concrete, legible output that a disaster manager can immediately see the use of
Against it
- Red flag: Bulk access to the major social platforms is now paid or restricted and scraping breaches their terms, so the primary data source is the weakest part of the plan — line up an alternative such as public citizen-report feeds or an open platform before you commit
- Red flag: Fake report detection is stated in one line and is by far the hardest requirement here; a team that builds ingestion and a dashboard has skipped the only part of this statement that is not commodity engineering
- Red flag: Absence of a rainfall signal is not proof a report is false — highly localised events genuinely do fall between gauge and grid resolution, so your system should downgrade confidence rather than declare a report fake
- Red flag: Geotagged metadata is frequently stripped or falsified on social platforms, so location often has to be inferred from text and imagery, which is a separate and error-prone problem the statement does not acknowledge
What you will be writing
- perceptual image hashing for recycled-photo detection
- multilingual text classification into event categories
- cross-reference against gridded rainfall and satellite records
- Kafka or Redis streams ingestion pipeline
- PostGIS spatial clustering of reports
- React dashboard with multi-axis filtering
- Crowdsourced disaster intelligence
- Misinformation detection
- Real-time data pipelines
Prior art to read before you start
citizen weather report collection and verification · duplicate and misleading content detection · event categorisation and geospatial dashboarding
Analysed by Claude Opus. Every score above is a judgment call with its reasoning attached — kindly cross-check this against the official statement on the SIH portal before your team commits to it.