Soil-Test-Based Crop Advisory System for Small Farmers (Python, scikit-learn, MySQL)

Soil-Test-Based Crop Advisory System is an individual BCA project that converts the numbers on a farmer's Soil Health Card into a specific, explained crop recommendation for the farmer's own district.

Under the Soil Health Card scheme (launched February 2015), every farm holding in India is tested for twelve parameters — available nitrogen, phosphorus and potassium, sulphur, five micronutrients, plus pH, electrical conductivity and organic carbon. The card tells a farmer the status of the soil, but turning that status into "what should I sow this kharif?" still depends on a rushed conversation at the extension centre. This system closes that loop: an extension officer enters the card's readings along with the farmer's village, land size and preferred season, and a decision-tree classifier trained on published crop-suitability ranges (as followed by ICAR's Krishi Vigyan Kendra network) recommends crops for the district — in this build, Tumakuru, Karnataka — ranked with a confidence score.

The differentiator is explainability. The system does not stop at "groundnut, 87%"; it shows the matched conditions — "pH 6.4, medium phosphorus, 640 mm normal rainfall" — as plain IF-THEN rules extracted from the trained tree, so the officer can read the reasoning aloud and a farmer can accept or reject it.

The application is built with Python, Flask and MySQL — all within the IGNOU BCA (revised) permitted stack — with scikit-learn for the model. It deliberately stays at beginner scope: one district, one classifier, one clean web workflow, but every part is complete and defensible.

A farmer's Soil Health Card reports twelve soil parameters, but crop choice is still decided by habit, neighbours or fertiliser-shop salesmen. KVK extension officers can give scientifically grounded crop advice, but they are few, the reasoning is unrecorded, and the same question must be answered one farmer at a time. Generic crop-advisory apps apply national-scale rules that ignore district soil and rainfall reality and give no reason for their suggestions, so farmers rightly distrust them.

What is needed is a small, auditable system for a single extension centre that (a) records the card's readings and the farmer's context, (b) recommends crops consistent with the district's published suitability ranges, (c) shows why each crop was suggested in IF-THEN language the officer can verify, and (d) keeps a history so follow-up is possible. The design must not collect government ID numbers — farmers are referenced by registration number only.

Abstract

This project designs and implements a crop-advisory web application that maps Soil Health Card readings to district-specific crop recommendations with human-readable justification. A decision-tree classifier is trained on a suitability dataset constructed from published ICAR/KVK crop-suitability ranges for Tumakuru district (ragi, groundnut, pigeonpea, maize, sunflower and allied crops), using soil pH, organic carbon, N-P-K ratings, normal rainfall and season as inputs. The trained tree is exported as IF-THEN rules that the advisory screen displays next to every recommendation, and the system records each advisory for follow-up by the extension centre. The stack is Python, Flask, MySQL and scikit-learn.

Introduction

A small farmer holding one to two hectares makes a sowing decision every season with little information. The Soil Health Card scheme has tested most holdings in the country and returns a card of twelve soil parameters with fertiliser dosages — but the card does not answer the question the farmer actually asks: "given my soil, what crop should I grow this season?" Krishi Vigyan Kendras, ICAR's district-level farm science centres, answer it with field experience and published suitability tables. This project digitises that reasoning so a single extension officer can serve more farmers in less time, without inventing advice.

Existing System

• The official Soil Health Card portal delivers test results and fertiliser recommendations, not crop choice.
• KVK officers give crop advisories verbally or on notice boards; the reasoning lives in experienced heads and printed tables.
• Generic mobile apps recommend crops nationally, often ignoring district reality — a crop unsuitable for 600 mm red-soil Tumakuru can appear next to a canal-irrigated suggestion with no explanation.
• Limitations: advice is unrecorded, non-reproducible, cannot be audited, and is unavailable when the officer is not present.

Proposed System

• Structured entry of Soil Health Card values (N, P, K, pH, organic carbon), village, holding size and season, with range validation at the form level.
• A decision-tree advisory model trained on the district suitability dataset, compared against k-NN and naive Bayes baselines with k-fold cross-validation.
• Rule extraction — the chosen tree is exported as IF-THEN conditions shown beside every recommendation, keeping the officer in charge of the decision.
• A district crop knowledge base in MySQL holding each crop's suitable pH band, nutrient class, rainfall band and sowing window, editable by the admin as new varieties are released.
• Advisory history per farmer with a follow-up flag, so the centre can call back and record what was actually sown.

Feasibility Study

• Technical: every component is free and documented — Flask, MySQL and scikit-learn; the model is a decision tree, trainable on a laptop in seconds; the app works on a low-end phone browser.
• Economic: zero licence cost; hosting on a ₹200/month VPS or entirely offline within the centre's LAN.
• Operational: the workflow mirrors what officers already do (read card → check tables → advise), so training takes minutes; explanations in local-language-ready text build the trust that a black-box score never would.

In scope

• One extension centre, one district (Tumakuru as the bundled example), one admin/officer role pair.
• Entry of the Soil Health Card's farmer-relevant parameters: N, P, K, pH, organic carbon; plus village, holding size and season.
• Decision-tree crop recommendation with k-NN and naive Bayes baselines, cross-validated.
• Rule display, printable advisory card, farmer-wise advisory history and follow-up flags.
• Admin screens to edit the crop knowledge base and manage officer accounts.

Out of scope (v1)

• Fertiliser dosage calculation (the SHC portal already provides it) and pesticide advisories.
• Weather-based dynamic advisories, market-price integration and yield prediction.
• Multi-district or multi-language deployment (the text layer is kept translation-ready, but only English ships).
• Mobile apps, SMS gateways and offline-first sync.
• Any collection of Aadhaar or other government ID numbers — by design, never stored.

The project follows the Incremental SDLC model over twelve weeks, chosen so that a working vertical slice (enter soil test → see an advisory) exists from week 4 and every later increment only deepens it. Each increment closes with a tested, demonstrable build, which matches how a single student can keep the project always presentable.

The application is a classic three-tier web architecture, deliberately conventional so every layer can be explained in the viva:

1. Presentation tier — server-rendered Jinja templates with a thin JavaScript layer for form validation; pages are mobile-friendly because officers work from phones.
2. Application tier — Flask blueprints (farmers, soil tests, advisory, admin); the advisory engine calls the persisted scikit-learn model, then maps the prediction to the knowledge base and extracts matching rules.
3. Data tier — MySQL holds users, farmers, soil tests, crops, advisories and the audit log; all model input is validated before it touches SQL, and every query uses parameterised statements.

flowchart TD
  O(["Extension officer"]) -->|"HTTPS login"| A["Flask app"]
  A --> F["Farmer & soil-test forms"]
  F -->|"validated values"| E["Advisory engine"]
  E -->|"feature vector"| M["scikit-learn decision tree"]
  M -->|"crop + confidence"| R["Rule extractor"]
  E --> KB[("MySQL: crops knowledge base")]
  R --> OUT["Advisory card with IF-THEN reasons"]
  F --> DB[("MySQL: farmers, tests, advisories")]
  A --> L["Audit log"]
  OUT --> O

ER diagram

erDiagram
  USER ||--o{ ADVISORY : issues
  FARMER ||--o{ SOIL_TEST : "provides samples for"
  SOIL_TEST ||--o{ ADVISORY : "generates"
  CROP ||--o{ ADVISORY : "is recommended in"
  USER ||--o{ AUDIT_LOG : "is recorded in"

  USER {
    int user_id PK
    string username UK
    string password_hash
    string role
  }
  FARMER {
    int farmer_id PK
    string reg_no UK
    string name
    string village
    decimal holding_ha
    string phone
  }
  SOIL_TEST {
    int test_id PK
    int farmer_id FK
    date card_date
    decimal n_kg_ha
    decimal p_kg_ha
    decimal k_kg_ha
    decimal ph
    decimal oc_percent
    string season
  }
  CROP {
    int crop_id PK
    string crop_name
    decimal ph_min
    decimal ph_max
    string rainfall_band
    string sowing_window
  }
  ADVISORY {
    int advisory_id PK
    int test_id FK
    int crop_id FK
    int user_id FK
    decimal confidence
    string rules_shown
    boolean follow_up_needed
    datetime issued_at
  }
  AUDIT_LOG {
    int log_id PK
    int user_id FK
    string action
    datetime at_time
  }

DFD to level 2 (as required in the BCSP-064 synopsis)

flowchart TB
  O(["Extension officer"]) --> P1["1.0 Manage farmer records"]
  P1 <--> D1[("D1 Farmers")]
  O --> P2["2.0 Record soil test"]
  P2 <--> D1
  P2 <--> D2[("D2 Soil tests")]
  P2 --> P3["3.0 Generate advisory"]
  P3 --> P31["3.1 Rate nutrients & pH"]
  P31 --> P32["3.2 Match crops from knowledge base"]
  P32 <--> D3[("D3 Crops")]
  P32 --> P33["3.3 Rank, extract rules, format"]
  P33 <--> D4[("D4 Advisories")]
  P33 -->|"card + reasons"| O

Key design decisions: the advisory is stored with the exact rule text shown to the officer, so any past advice can be replayed and audited; nutrient rating (low/medium/high) is computed once and stored to keep the model input and the human explanation consistent; and the crops table, not the model, is the source of agronomic truth — the model only ranks candidates the knowledge base already considers possible.

• Multi-district and multi-language deployment with translated advisory text and per-district knowledge bases.
• Yield and fertiliser additions — extend the knowledge base from crop choice to expected yield bands and SHC-linked fertiliser verification.
• SMS/IVR advisory so farmers without smartphones receive the recommendation and can query it by voice in their language.
• Seasonal learning loop — record actual sowing and harvest outcomes to retrain the tree on real field results instead of published ranges alone.
• Price-aware ranking — blend suitability with Minimum Support Price and local mandi trends so the top recommendation is also economically sensible.