AgriGuide: An Integrated Web Application for Farmers’ Support and Agricultural Marketing Places

1Introduction

1.1Background and context

Agriculture supports food production, rural employment, allied industries and the wider economy. Farmers make decisions throughout the crop cycle: selecting crops, preparing land, choosing seeds and inputs, managing irrigation, monitoring pests and diseases, harvesting, storing and selling produce. Each decision depends on information that may come from agricultural departments, universities, extension workers, local traders, market committees, weather services and other farmers.

Digital technologies can make this information easier to discover. A web application can organise information into searchable sections and make it available through a mobile phone or computer. The usefulness of such a platform depends not only on the amount of information provided, but also on whether it is current, understandable, location-relevant and linked to reliable sources.

AgriGuide is conceived as a single access point for selected farmer-support information and agricultural marketing-place discovery. It focuses on connecting information that is commonly needed before and after harvest. It can help a user learn about a crop and also find places that may support storage, aggregation, sale or transport.

1.2Agriculture information needs

Information needs vary by crop, season, district, water availability, soil, farm size and market conditions. A farmer may need general cultivation guidance at the beginning of a season, weather information during crop growth, and market or storage information close to harvest. A useful digital platform should therefore organise information by topic and location rather than present a large unstructured collection of links.

1.3Problem statement and need

Farmers may have to visit multiple websites, contact different offices or depend on informal communication to locate crop guidance, agricultural services and marketing places. Information may be fragmented, difficult to compare or unavailable in a convenient format. In addition, the location, contact details and operating status of markets and support facilities can change over time.

The project addresses the need for a simple, centralised and searchable web application that organises useful farmer-support information and marketing-place details. The system should clearly show the source and update date of important information. Where live or official data cannot be obtained, the application should label information as static or last updated rather than presenting it as real-time.

1.4Aim of the project

The aim of AgriGuide is to design and develop an integrated web application that improves farmers’ access to agricultural support information and helps them discover relevant agricultural marketing places through a user-friendly digital platform.

1.5Objectives

• Provide a simple registration and login facility for users where personal accounts are required.
• Organise crop information, cultivation guidance and general farming resources by category.
• Provide a directory and search facility for agricultural marketing places and support centres.
• Allow users to search or filter places by location, category and available services.
• Display available contact details, address, map location and source/update information.
• Provide access to market-price information only when a dependable data source is available.
• Enable an administrator to add, update, verify and deactivate records.
• Design a responsive interface suitable for mobile phones and desktop computers.

1.6Scope of the project

The proposed scope includes a farmer-facing web interface, an information-management interface and a database for storing application records. The farmer-facing section will present crop guidance, agricultural resources and a directory of marketing places. The administrator section will support controlled management of content, categories, locations and user feedback.

The marketing-place directory may include regulated agricultural markets, wholesale markets, farmer producer organisation collection points, warehouses, cold-storage facilities, procurement centres and other relevant services. The exact categories will be finalised after reviewing the project region and the availability of verified data. A map view may be provided through a third-party map service, subject to its terms and API availability.

The project is primarily an information and discovery platform. It does not guarantee the quality of produce, purchase prices, buyer availability, transport arrangements or business transactions. It will not provide a formal diagnosis of crop disease or replace expert advice. Any crop-protection or pesticide-related information should be sourced from recognised agricultural authorities and presented with appropriate cautions.

1.7Significance and expected outcomes

AgriGuide is expected to reduce the effort required to find selected agricultural resources, improve awareness of available marketing infrastructure and provide a structured way to maintain local agricultural information. A well-designed directory can help users compare possible destinations before travelling. A source-aware information system can also make it easier for administrators to identify outdated records and correct them.

1.8Intended users

• Farmers seeking crop-related information and nearby marketing or support facilities.
• Farmer groups and producer organisations looking for collection or market information.
• Agricultural students and extension workers using the platform as an information directory.
• Administrators responsible for maintaining and verifying application content.

2Existing system and literature review

2.1Existing approaches

Agricultural information is currently accessed through a combination of official portals, state and central government services, agricultural university resources, market information systems, weather services, local agricultural offices and private platforms. These channels serve different purposes. Some focus on schemes and farmer services, others provide market prices, weather information, crop advisories or directories of infrastructure.

A farmer may use a government portal to understand a scheme, a market-information portal to check reported prices, a weather service to review forecasts and a map application to locate a facility. These resources can be valuable, but users may need to switch between services and interpret information presented in different formats.

2.2Review of digital agriculture concepts

Digital agriculture includes the use of mobile applications, web portals, geographic information systems, remote sensing, sensors, analytics and online marketplaces. For this project, the most relevant concepts are information integration, location-based search, responsive user experience, structured data management and trusted external references.

A directory-based application is useful when its records are curated and updated. Search and filtering can reduce the time needed to find a relevant facility. Geographic coordinates can support map display and distance-based exploration, although the accuracy of results depends on the quality of the location data.

2.3Limitations of existing fragmented access

• Information may be distributed across multiple portals and organisations.
• Different services may use different layouts, terminology and search methods.
• A user may not know which source is official or most recently updated.
• Local marketing-place details may be difficult to discover in one consolidated directory.
• Some services may require separate accounts, language familiarity or repeated data entry.
• A listed facility may have changed its contact details, operating hours or service availability.

2.4Identified research gap

The project identifies an opportunity for a lightweight integrated interface that combines two related needs: access to selected farming-support information and discovery of agricultural marketing places. The intention is not to duplicate official systems or claim ownership of their data. Instead, AgriGuide can organise links and verified records, provide a consistent search experience and direct users to original sources for authoritative updates.

2.5Proposed contribution

The proposed contribution is a modular application with a farmer-oriented interface, structured marketing-place directory, administrative verification workflow and source/update labels. The project can be adapted to a selected district or region, allowing the development team to focus on reliable local data rather than attempting to cover every agricultural facility in the country at the initial stage.

2.6Summary

The review indicates that digital agriculture resources are useful but serve different purposes. AgriGuide proposes a consolidated discovery layer that improves navigation while retaining links to authoritative services. The quality of the project will depend on data verification, clear limitations and a simple user experience.

2.7Overview of the proposed system

AgriGuide will provide a responsive web application through which a user can browse agricultural resources and search for marketing places. The application will separate presentation, business logic and data storage. This separation makes the system easier to maintain and allows individual modules to be improved without redesigning the entire application.

A typical user flow begins with the home page. The user selects a service such as crop information or marketing-place search. For place discovery, the user can enter a district, taluk, village or place name and select a facility category. The system retrieves matching records and displays relevant details. If map integration is enabled, the user can open the location in a map service for navigation.

2.8Main features

• Home page with clear navigation to major services.
• Crop and farming information organised by categories.
• Searchable marketing-place directory with location filters.
• Place detail page with address, category, contact information and source.
• Optional map view and directions link.
• Information pages containing links to official agricultural resources.
• Administrator dashboard for content and directory management.
• Feedback mechanism for reporting incorrect or outdated information.

2.9Advantages of the proposed system

The integrated interface can reduce repeated searching, make local facilities easier to discover and provide a consistent experience across devices. Central administration can improve the quality of stored records. The use of clear timestamps and source links helps users judge whether information may need confirmation before acting on it.

3Requirements analysis

3.1Functional requirements

Functional requirements describe the services that the application must provide. The following requirements form the proposed baseline and can be refined during implementation.

Table 1 lists the functional requirements.

ID	Requirement	Description
FR-01	User access	Allow visitors to browse public information; provide secure login if account features are enabled.
FR-02	Crop information	Display categorised crop guidance and trusted reference links.
FR-03	Place search	Search marketing places by name, location and category.
FR-04	Place details	Show address, contact details, services and last-updated date where available.
FR-05	Administration	Allow authorised administrators to create, edit, verify and deactivate records.
FR-06	Feedback	Accept reports about missing or incorrect directory information.
FR-07	External links	Direct users to official sources for current advisories, prices or schemes.

3.2User roles

The visitor role can access public information and search the directory. A registered farmer role may save preferences or submit feedback if those features are implemented. The administrator role has permission to manage records and moderate user-submitted changes. Role-based access must prevent ordinary users from modifying verified master records.

3.3Non-functional requirements

Table 2 summarises the non-functional requirements.

Attribute	Expected requirement
Usability	Simple navigation, readable text, clear labels and minimal steps for common tasks.
Performance	Common searches should return results within an acceptable response time under the expected project load.
Availability	The application should be deployable on a reliable hosting environment with backup procedures.
Security	Use password hashing, access control, input validation and secure transport in deployment.
Compatibility	Support current major browsers and responsive mobile, tablet and desktop layouts.
Maintainability	Use modular code, documented APIs and structured database design.
Data quality	Store source and update dates; provide an administrative verification process.

3.4Hardware requirements

• Development computer: a standard laptop or desktop with a modern dual-core or better processor.
• Memory: 8 GB RAM recommended for comfortable development.
• Storage: sufficient free disk space for source code, database and test data.
• Internet connection for documentation, deployment and any external service integrations.
• Smartphone or tablet for responsive-interface testing.

3.5Software requirements

• Operating system: Windows, Linux or macOS.
• Front end: HTML5, CSS3 and JavaScript.
• Back end: Python with Flask or Django.
• Database: MySQL or PostgreSQL.
• Development tools: Visual Studio Code and Git.
• Testing: browser developer tools and Python testing framework.
• Optional map integration: a map provider selected according to cost, terms and availability.

3.6Feasibility study

3.6.1Technical feasibility

The project is technically feasible using commonly available web-development technologies. HTML, CSS and JavaScript can provide the responsive interface, while Python can implement server-side logic and database operations. A relational database can store users, crop resources, place records, categories and feedback. The project can be developed incrementally, beginning with a local prototype and progressing to deployment.

3.6.2Operational feasibility

The proposed interface is intended for users with different levels of digital familiarity. Simple labels, clear search fields and mobile-friendly pages can support ease of use. User feedback and testing with representative users will be important to identify language, navigation and accessibility issues. If the application is deployed for a real community, a responsible person or organisation must maintain the directory.

3.6.3Economic feasibility

A prototype can be developed with open-source technologies, which helps limit software licensing costs. Potential expenses may include domain registration, hosting, database hosting, map API usage, SMS or email services and data collection. The final cost depends on the scale of deployment and the terms of third-party services. For an academic prototype, free development tools and a limited test dataset may be sufficient.

3.6.4Schedule feasibility

The work can be completed in stages: requirement collection, interface design, database design, core development, integration, testing, documentation and demonstration. A small initial scope helps ensure that the core search and information features are completed before optional integrations are attempted.

3.6.5Feasibility conclusion

The proposed project is feasible as an academic web application, provided that the team defines a manageable geographic scope, uses verified sample data and clearly separates implemented features from future enhancements.

4System design

4.1High-level architecture

The system follows a three-layer architecture. The presentation layer contains the pages and interactive controls used by farmers and administrators. The application layer handles authentication, validation, search, business rules and communication with external services. The data layer stores application records and supports retrieval and updates.

Presentation Layer: Home page, crop information, marketing-place search, place details, user profile and administrator dashboard.

Application Layer: Authentication, role management, crop-resource service, directory search, feedback processing, validation and API integration.

Data Layer: User records, crop categories, crop resources, marketing places, location details, source references and feedback.

4.2External data sources

External information may be obtained from official agricultural departments, agricultural universities, recognised weather providers, official market-information services and verified local institutions. Integration can be implemented through documented APIs, approved data downloads or manually curated records. The project must respect source terms, attribution requirements and data licensing. If an external service is unavailable, the application should show an informative message rather than inventing current data.

4.3Architecture principles

• Separate user-interface code from business logic and database access.
• Use reusable modules and consistent validation rules.
• Apply role-based access to administrative functions.
• Record the origin and last-updated date of important information.
• Design APIs so that future mobile applications can reuse core services.

4.4Major modules

Table 3 lists the major application modules.

Module	Purpose	Key operations
Farmer interface	Provide access to services	Browse, search, view details and submit feedback.
Crop information	Organise farming resources	Browse crop categories, guidance and official references.
Marketing directory	Discover relevant places	Filter by district, taluk, category and name.
Place details	Present facility information	Display address, contact, services and update date.
Administrator	Maintain information quality	Create, edit, verify and deactivate records.
Feedback	Support corrections	Receive reports and track review status.

4.5User interaction flow

1. 1. The user opens the AgriGuide home page.
2. 2. The user chooses crop information or marketing-place discovery.
3. 3. For place discovery, the user enters a location or selects filters.
4. 4. The application validates the search and queries the database.
5. 5. Matching records are displayed with available details and update information.
6. 6. The user opens a place record or follows an official external link.
7. 7. If an error is found, the user can submit feedback for administrator review.

4.6Context-level data flow

At the context level, the AgriGuide application interacts with three main external entities: the farmer or visitor, the administrator and approved external information providers. Farmers send search requests and feedback and receive information pages and directory results. Administrators submit verified content changes and receive management reports. External providers supply data or reference links according to their interfaces and terms.

4.7Level-1 data flow

• Process 1 – User Access: validates login details and assigns the appropriate role.
• Process 2 – Information Retrieval: retrieves crop resources and reference links.
• Process 3 – Place Search: applies location and category filters to directory records.
• Process 4 – Feedback Handling: stores reports for administrative review.
• Process 5 – Content Administration: validates and updates approved records.

4.8Database design

A relational database is suitable because the application contains structured entities with clear relationships. A marketing place belongs to a category and is associated with a geographic area. A crop resource may be associated with one or more crop categories. Feedback can refer to a place or information record and may be assigned a review status.

4.9Proposed database entities

Table 4 lists the main database entities.

Entity	Important fields	Purpose
User	user_id, name, email, password_hash, role	Account and role information
Crop	crop_id, crop_name, category, season	Crop classification
Resource	resource_id, title, description, source_url, updated_at	Crop guidance and reference material
Place	place_id, name, category_id, address, district, taluk, latitude, longitude	Marketing and support locations
Category	category_id, category_name	Place or resource categories
Feedback	feedback_id, user_id, place_id, message, status, created_at	User-submitted correction reports

4.10Relationships and data integrity

Each user may submit multiple feedback records. A category may be associated with many marketing places. A crop may have multiple information resources. A feedback record may refer to a place record, a resource record or a general issue. Foreign-key constraints should be used where appropriate to prevent orphaned records. Required fields, valid formats and duplicate checks should be applied during data entry.

4.11Search and filtering design

The directory search should support partial name matching and filters for district, taluk, village or facility category. Search results should be paginated when the dataset becomes large. The application should display a useful empty-state message when no records match. If distance sorting is implemented, the system must have reliable coordinates and should explain that straight-line distance may differ from actual road distance.

4.12Data quality and verification

Marketing-place records should be verified before being marked as approved. The system can maintain a status such as Draft, Pending Verification, Verified or Inactive. Administrators should record the source and date of verification. User-submitted corrections should not directly overwrite approved records; they should enter a review queue. This approach reduces the risk of publishing inaccurate contact or location information.

4.13Backup and recovery

The database should be backed up periodically according to the deployment environment. Backup files should be access-controlled and stored separately from the live database. Recovery should be tested to ensure that data can be restored. The final deployment plan should define backup frequency, retention period and responsibility for recovery.

5Technology and implementation plan

5.1Proposed technology stack

Table 5 lists the proposed software and tools.

Layer	Proposed technology	Reason for selection
Front end	HTML5, CSS3, JavaScript	Widely supported technologies for responsive interfaces.
Back end	Python with Flask or Django	Supports modular server-side development and database integration.
Database	MySQL or PostgreSQL	Relational storage, queries and data integrity.
Editor	Visual Studio Code	Source editing and extension support.
Version control	Git	Tracks code changes and supports collaboration.
Deployment	Suitable cloud or institutional server	Makes the application accessible for demonstration or use.

5.2Front-end development

The front end will be designed with clear navigation, consistent typography, readable forms and responsive layouts. The home page will introduce the application and provide direct links to major services. Search pages will keep filters visible and show results in cards or tables. Place detail pages will clearly distinguish verified information from unavailable or unverified fields.

5.3Back-end development

The Python application will expose routes or API endpoints for user access, crop resources, place search, place details, feedback and administration. Server-side validation is required even when browser-side validation is also used. Database queries should use parameterised operations or a trusted ORM to reduce injection risks.

5.4Database implementation

The database schema will be created from the entity model. Tables will use primary keys and suitable foreign keys. Indexes can be added to commonly searched fields such as place name, district and category. The implementation should avoid storing unnecessary personal information. Passwords must never be stored in plain text.

5.5Map and location integration

A map service may be used to show a verified location and provide an external directions link. The project should select a provider after reviewing API limits, attribution rules, privacy requirements and cost. If map integration is not available, the application can still provide a formatted address and a user-initiated external map link. Coordinates must be checked before publication.

5.6Market information integration

Market-price information is time-sensitive and can vary by commodity, grade, market and date. If a suitable official source or documented API is available, AgriGuide may display the reported value with its market name, commodity, unit, date and source. If such integration is not available, the system should provide a link to the official source instead of displaying invented or stale prices as current.

5.7Development phases

1. 1. Requirement collection and definition of target region and user roles.
2. 2. Wireframe design and review of the user navigation flow.
3. 3. Database schema creation and sample-data preparation.
4. 4. Implementation of core front-end pages and server routes.
5. 5. Development of place search, filters and detail pages.
6. 6. Development of administration and feedback workflows.
7. 7. Integration of approved external links or APIs.
8. 8. Testing, correction, documentation and final demonstration.

5.8Security considerations

• Store passwords using a recognised salted password-hashing method.
• Enforce role-based permissions for administrator functions.
• Validate and sanitise all user inputs on the server.
• Use parameterised database queries or a trusted ORM.
• Apply HTTPS in production deployment.
• Protect administrative sessions and provide logout functionality.
• Limit access to personal data and avoid collecting unnecessary details.
• Keep dependencies updated and remove unused test accounts.

5.9Privacy considerations

The application should explain why any personal information is collected and how it is used. Public browsing should remain possible where practical without requiring an account. Contact details submitted for feedback should be visible only to authorised personnel. The project should define a retention approach for user data and provide a way to correct inaccurate account information.

5.10Accessibility and language

The interface should use readable font sizes, sufficient contrast, meaningful labels and keyboard-accessible controls. Buttons and form fields should have clear names. Since farmers may prefer local languages, the architecture should allow content labels and help text to be localised. Kannada can be considered for the initial regional version, with English retained where useful for technical or official terms.

5.11Responsible information presentation

Crop guidance and agricultural recommendations can affect livelihoods. The application should identify the source, publication or update date and intended region where available. It should avoid presenting general information as a guaranteed result. For pest, disease, chemical-use or financial decisions, users should be directed to qualified local experts and official guidance.

6Testing, results and evaluation plan

6.1Testing strategy

Testing will be carried out throughout development. Unit testing will check individual functions such as input validation and search filters. Integration testing will verify communication between the interface, server and database. System testing will examine complete user journeys. Usability testing will gather feedback on navigation, readability and ease of finding information.

6.2Proposed test scenarios

Table 6 lists the proposed test scenarios.

Test ID	Scenario	Expected result
TC-01	Open home page on desktop and mobile	Layout displays without overlap and navigation works.
TC-02	Search a known marketing place	Matching record is displayed with correct details.
TC-03	Apply district and category filters	Only records matching the selected filters appear.
TC-04	Search for a non-existing place	A clear no-results message is displayed.
TC-05	Submit incomplete feedback form	Validation identifies required missing fields.
TC-06	Attempt administrator page as normal user	Access is denied or redirected appropriately.
TC-07	Update a place record as administrator	The authorised update is saved and audit details are retained where implemented.
TC-08	Open external source link	Correct source opens; unavailable links are handled clearly.

6.3Performance evaluation

The application will be tested with a representative sample dataset. Search response time, page loading behaviour and database query performance will be observed. If the dataset grows, pagination and indexes can be introduced. Performance results should be measured in the actual test environment and recorded in the final report rather than estimated in advance.

6.4Usability evaluation

Representative users can be asked to complete tasks such as locating a market in a selected taluk, finding a crop resource and reporting an incorrect directory entry. Feedback can be collected on task completion, clarity of labels, number of steps and perceived ease of use. Any testing involving real participants should follow institutional guidance and avoid collecting unnecessary personal information.

6.5Data accuracy evaluation

A sample of directory records should be checked against the original source or direct confirmation from the responsible facility. The evaluation can measure the proportion of records with complete addresses, valid contact details, coordinates and update dates. Missing or uncertain fields should be marked clearly rather than filled with assumptions.

6.6Expected results

The expected result is a working prototype that allows users to browse agricultural resources and search a curated directory of marketing places. The prototype should demonstrate a clear user journey, reliable retrieval from the database, administrator content management and responsive page layouts. Actual results, screenshots and measured test outcomes will be documented after implementation.

6.7Limitations

The accuracy and coverage of the directory depend on available verified data. Real-time prices, weather or facility availability require external data sources and may not be available in every region. Internet access is required for online use and map services. The platform cannot guarantee a transaction or substitute for official advice.

7Project planning and conclusion

7.1Work breakdown

Table 7 sets out the project phases, activities and deliverables.

Phase	Activities	Deliverable
1. Analysis	Identify users, requirements and regional scope	Requirement specification
2. Design	Prepare wireframes, architecture and database model	Design documents
3. Development	Build interface, server logic and database	Core application prototype
4. Integration	Connect modules and approved external sources	Integrated application
5. Testing	Perform functional, security and usability checks	Test report and fixes
6. Documentation	Prepare user guide and final report	Final project documentation
7. Demonstration	Deploy or run prototype and present features	Project demonstration

7.2Proposed timeline

A tentative 12-week schedule is suggested below. The actual duration should be adjusted to the academic calendar and project-review dates.

Table 8 gives the tentative timeline.

Task	Weeks
Requirement analysis	1–2
System and database design	3–4
Front-end and back-end development	5–8
Integration and data verification	9
Testing and improvements	10–11
Documentation and demonstration	12

7.3Expected deliverables

• Requirement specification and system-design diagrams.
• Responsive AgriGuide web application prototype.
• Database containing sample or verified regional directory records.
• Farmer-facing crop-resource and marketing-place search modules.
• Administrator interface for maintaining records.
• Testing documentation, screenshots and user guidance.

7.4Future enhancements

• Kannada and additional regional-language support.
• Progressive Web App features for improved mobile access.
• Verified weather and market-price integrations from official sources.
• Distance-based place discovery and route planning.
• Notifications for selected updates, where user consent is provided.
• Farmer group and producer-organisation service listings.
• Accessibility improvements and voice-assisted navigation.
• Analytics for administrators to identify missing or outdated records.

7.5Conclusion

AgriGuide proposes an integrated web application to make selected farming-support information and agricultural marketing-place details easier to access. By combining crop resources, location-based directory search, structured records and administrative verification, the platform aims to provide a convenient information-discovery experience for farmers. The system is designed as a practical academic project that can begin with a limited regional dataset and grow through carefully selected integrations.

The success of the application will depend on usability, data quality, transparent sourcing and responsible presentation of information. AgriGuide is intended to complement existing agricultural services and official information systems, not replace them. With these principles, the project can demonstrate how web technologies can support better access to agricultural information and marketing infrastructure.

References

1. [1]Ministry of Agriculture and Farmers Welfare, Government of India. Official agriculture programmes and farmer information [Internet]. https://agriwelfare.gov.in/
2. [2]Directorate of Marketing and Inspection, Government of India. Agricultural marketing and market-related information [Internet]. https://dmi.gov.in/
3. [3]AGMARKNET. Agricultural marketing information portal [Internet]. https://agmarknet.gov.in/
4. [4]e-NAM. National Agriculture Market [Internet]. https://enam.gov.in/
5. [5]India Meteorological Department. Weather services and forecasts [Internet]. https://mausam.imd.gov.in/
6. [6]Indian Council of Agricultural Research. Agricultural research and extension resources [Internet]. https://icar.org.in/
7. [7]Karnataka Department of Agriculture. State agricultural information and services [Internet]. https://raitamitra.karnataka.gov.in/
8. [8]Python Software Foundation. Python documentation [Internet]. https://docs.python.org/3/
9. [9]Flask Documentation [Internet]. https://flask.palletsprojects.com/
10. [10]Django Documentation [Internet]. https://docs.djangoproject.com/
11. [11]MySQL Documentation [Internet]. https://dev.mysql.com/doc/
12. [12]PostgreSQL Documentation [Internet]. https://www.postgresql.org/docs/
13. [13]MDN Web Docs. HTML, CSS and JavaScript [Internet]. https://developer.mozilla.org/