ichsanix/SIG_WEBGIS_Nur_Ichsanul_Alif
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a7cb1f2de07417a3fac9c8a93b859481add87a80
SIG_WEBGIS_Nur_Ichsanul_Alif/docs/SRS.md
T
ichsanix a7cb1f2de0 first commit
2026-06-10 22:46:10 +07:00

14 KiB
Raw Blame History

WebGIS — Software Requirements Specification (SRS)

Spatial Data Management System for Poverty Reduction Support

1. INTRODUCTION

1.1 Purpose

This document defines the functional and non-functional requirements for a WebGIS (Web-based Geographic Information System) application designed to manage spatial data — including point features, road networks, and land parcels — in support of local government decision-making with a focus on poverty reduction programs.

1.2 Scope

The system is named WebGIS-SPD (Spatial Poverty Data). It allows government officers, planners, and community stakeholders to:

  • Register, visualize, update, and delete spatial features (points, lines, polygons)
  • Identify the spatial distribution of poor population areas
  • Overlay infrastructure data (roads, SPBU) with poverty indicators
  • Support location-based decision-making for resource allocation

1.3 Intended Audience

  • Academic reviewers and instructors
  • Local government (dinas/pemda) administrators
  • GIS officers and data entry staff
  • NGO field coordinators

1.4 Definitions

Term Meaning
GIS Geographic Information System
SPBU Stasiun Pengisian Bahan Bakar Umum (Gas Station)
SHM Sertifikat Hak Milik (Freehold Title)
HGB Hak Guna Bangunan (Building Rights)
HGU Hak Guna Usaha (Business Rights)
HP Hak Pakai (Usage Rights)
CRUD Create, Read, Update, Delete
GeoJSON Geographic JSON — standard geospatial format

2. SYSTEM OVERVIEW

WebGIS-SPD is a web application built with:

  • Frontend: HTML5, CSS3, Vanilla JavaScript, Leaflet.js
  • Backend: PHP (procedural, no framework)
  • Database: MySQL 8+
  • Map Tiles: OpenStreetMap (free, community-maintained)
  • Drawing Tools: Leaflet.draw plugin

The system follows a client-server architecture. All spatial data is stored in MySQL as GeoJSON text and served via RESTful PHP endpoints.

3. FUNCTIONAL REQUIREMENTS

FR-01: Point Data Management (SPBU, Mosque, Poor Population)

ID Requirement
FR-01.1 User can add a point by clicking on the map
FR-01.2 Coordinates are captured automatically from click event
FR-01.3 Each point has: name, category, optional subtype
FR-01.4 SPBU points have a subtype: "24 Hours" or "Not 24 Hours"
FR-01.5 User can edit point attributes
FR-01.6 User can delete a point
FR-01.7 Points display custom icons by category
FR-01.8 Clicking a marker shows a popup with attributes and action buttons

FR-02: Road Polyline Management

ID Requirement
FR-02.1 User draws roads using Leaflet.draw polyline tool
FR-02.2 Road length is calculated automatically in meters
FR-02.3 Length is NOT manually editable
FR-02.4 Road types: National (red), Provincial (orange), District (blue)
FR-02.5 Each road stores: name, type, length, GeoJSON geometry
FR-02.6 Roads are styled by type using distinct colors
FR-02.7 User can edit road name/type
FR-02.8 User can delete a road

FR-03: Land Parcel Polygon Management

ID Requirement
FR-03.1 User draws parcels using Leaflet.draw polygon tool
FR-03.2 Parcel area is calculated automatically in m² using geodesic formula
FR-03.3 Area is NOT manually editable
FR-03.4 Ownership types: SHM, HGB, HGU, HP
FR-03.5 Each parcel stores: owner name, ownership type, area, GeoJSON geometry
FR-03.6 Parcels are styled by ownership type
FR-03.7 User can edit parcel attributes
FR-03.8 User can delete a parcel

FR-04: Layer Control

ID Requirement
FR-04.1 Each feature category has an independent toggle checkbox
FR-04.2 SPBU is split into two toggleable sub-layers
FR-04.3 Roads are split by type into three sub-layers
FR-04.4 Parcels are split by ownership into four sub-layers
FR-04.5 Layer counts are displayed next to each toggle

FR-05: Data Listing and Navigation

ID Requirement
FR-05.1 Sidebar shows a scrollable list of all features per type
FR-05.2 Clicking a list item zooms the map to that feature
FR-05.3 List items have inline Edit and Delete actions

4. NON-FUNCTIONAL REQUIREMENTS

ID Category Requirement
NFR-01 Performance Map renders within 2 seconds on standard broadband
NFR-02 Usability All map interactions require no more than 3 clicks
NFR-03 Reliability API returns structured JSON for all success/error states
NFR-04 Security All inputs are sanitized via PDO prepared statements
NFR-05 Scalability Database schema supports >10,000 features per table
NFR-06 Compatibility Works in modern browsers (Chrome, Firefox, Edge)
NFR-07 Maintainability Code is modular, commented, and follows single responsibility
NFR-08 Openness Uses open-source libraries (Leaflet, OSM) — no licensing cost

5. USER ROLES

Role Permissions
GIS Admin Full CRUD on all layers; manage system configuration
Data Entry Officer Add and edit features; cannot delete
Viewer Read-only; can pan/zoom map and view popups
Community Supervisor Add poor population points; view mosques and infrastructure

6. USE CASE DESCRIPTIONS

UC-01: Add Gas Station (SPBU)

  • Actor: GIS Admin / Data Entry Officer
  • Precondition: User is on the Points tab
  • Flow:
    1. User clicks "Add Point on Map"
    2. User clicks a location on the map
    3. Modal opens with coordinates pre-filled
    4. User selects category = SPBU, subtype = 24 Hours / Not 24 Hours
    5. User enters name and optionally description
    6. User clicks "Add Point"
    7. Marker appears on map; entry added to list
  • Postcondition: Point stored in database; shown on correct sub-layer

UC-02: Draw and Save a Road

  • Actor: GIS Admin
  • Precondition: User is on the Roads tab
  • Flow:
    1. User clicks "Draw Road on Map"
    2. User draws polyline by clicking multiple points; double-clicks to finish
    3. Modal opens with length auto-filled (read-only)
    4. User enters road name and type
    5. User saves; road appears on map with correct color
  • Postcondition: Road stored with GeoJSON + calculated length

UC-03: Draw and Save a Land Parcel

  • Actor: GIS Admin
  • Flow: Similar to UC-02 but with polygon; area auto-calculated

UC-04: Toggle Layer Visibility

  • Actor: Any user
  • Flow: User clicks checkbox next to a layer name; features appear/disappear

UC-05: Edit a Feature

  • Actor: GIS Admin / Data Entry
  • Flow: User clicks "✏️" on a list item or in popup → modal opens pre-filled → saves updated data

UC-06: Delete a Feature

  • Actor: GIS Admin
  • Flow: User clicks "🗑️" → confirmation dialog → feature removed from map and database

7. BUSINESS PROCESS ANALYSIS

Current Process (Without System)

  1. Field officers collect data on paper forms
  2. Data is manually entered into Excel spreadsheets
  3. Reports are produced monthly; no spatial context
  4. Decision-makers have no map-based view of poverty distribution
  5. Infrastructure gaps (missing roads, no SPBU access) are not correlated with poverty

Improved Process (With WebGIS-SPD)

  1. Field officers directly enter poor population locations on the web map
  2. Data is instantly visible to supervisors and planners
  3. GIS admin overlays road network + poverty zones to identify accessibility gaps
  4. Land parcel ownership data helps identify available land for social housing
  5. Mosque locations help identify community focal points for program delivery

8. POVERTY REDUCTION SYSTEM DESIGN

8.1 Actors Involved

Actor Role Data They Contribute
Local Government (Dinas Sosial) Decision makers, program funders Program areas, budget allocation zones
GIS Officers (BPS/Bappeda) Data managers, analysts Road networks, land parcels, administrative boundaries
Community (RW/RT Leaders) Ground truth validators Poor household locations, family counts
Mosques / Religious Institutions Community focal points Zakat distribution data, beneficiary lists
NGOs / Social Organizations Program implementors Intervention areas, beneficiary tracking
Health Centers (Puskesmas) Health services data Malnourishment points, access to healthcare

8.2 Required Data Attributes Per Actor

Poor Population Points (contributed by Community + Dinas Sosial):

  • Head of household name
  • Number of family members
  • Monthly income (IDR)
  • Access to clean water: yes/no
  • Distance to nearest road (m) — calculated from road layer
  • Distance to nearest SPBU — calculated from point layer
  • Receiving social assistance: yes/no
  • Assistance program type (PKH, BPNT, etc.)

Road Network (contributed by GIS Officers):

  • Road name, type, surface condition
  • Last maintained date
  • Accessibility rating (1–5)

Land Parcels (contributed by BPN / GIS Officers):

  • Ownership type (SHM/HGB/HGU/HP)
  • Current usage (residential, agricultural, vacant)
  • Available for social housing: yes/no

Mosque Data (contributed by Religious Affairs):

  • Name, capacity
  • Zakat collection amount (IDR/year)
  • Zakat distribution radius (m)

8.3 Example Use Case: Targeting Poverty Aid

Scenario: Government wants to identify poor households with the worst infrastructure access.

System Query:

  1. Display all "Poor Population" points
  2. Toggle on "District Roads" layer
  3. Visually identify poor zones more than 500m from any road
  4. Overlay land parcel layer → identify HGU/HP parcels near these zones
  5. Overlay mosque layer → find nearest mosque to use as aid distribution point

Result: Decision maker can now select 50 priority households based on spatial proximity to infrastructure gaps, identify community delivery channels (mosques), and plan land use for social housing — all from a single map interface.

8.4 How the System Contributes to Poverty Reduction

Contribution Mechanism
Targeted Aid Delivery Spatial query identifies worst-off zones first
Infrastructure Planning Road gaps near poor zones inform public works budgets
Land Use Planning Vacant HP/HGU parcels near poor zones identified for social housing
Community Empowerment Mosques mapped as distribution hubs for zakat + government aid
Evidence-Based Policy Spatial statistics replace anecdotal reports
Monitoring Change detection over time shows if interventions are working
Transparency Web-based, shareable map increases government accountability

9. SYSTEM ARCHITECTURE DIAGRAM

┌──────────────────────────────────────────────────────────────┐
│                        CLIENT (Browser)                       │
│   ┌────────────┐  ┌─────────────┐  ┌────────────────────┐   │
│   │ Leaflet.js │  │  Leaflet    │  │  Vanilla JS App    │   │
│   │  Base Map  │  │  Draw Tools │  │  (app.js)          │   │
│   └─────┬──────┘  └──────┬──────┘  └────────┬───────────┘   │
│         └────────────────┴──────────────────┘                │
│                           │ fetch() HTTP                      │
└───────────────────────────┼──────────────────────────────────┘
                            │
┌───────────────────────────┼──────────────────────────────────┐
│                    SERVER (PHP)           │                   │
│   ┌──────────────────────────────────┐   │                   │
│   │  api/points.php                  │   │                   │
│   │  api/roads.php                   │◄──┘                   │
│   │  api/parcels.php                 │                       │
│   └───────────────┬──────────────────┘                       │
│                   │ PDO                                       │
│   ┌───────────────▼──────────────────┐                       │
│   │         MySQL Database            │                       │
│   │   tables: points, roads, parcels  │                       │
│   └──────────────────────────────────┘                       │
└──────────────────────────────────────────────────────────────┘

10. DATABASE ENTITY RELATIONSHIP

POINTS
├── id (PK)
├── name
├── category [spbu|mosque|poor]
├── subtype [24hours|not24hours|null]
├── latitude, longitude
├── description
└── timestamps

ROADS
├── id (PK)
├── name
├── road_type [national|provincial|district]
├── length_m (auto-calculated)
├── geojson (LineString)
├── description
└── timestamps

PARCELS
├── id (PK)
├── owner_name
├── ownership_type [SHM|HGB|HGU|HP]
├── area_m2 (auto-calculated)
├── geojson (Polygon)
├── description
└── timestamps

Document Version: 1.0 | Prepared for Academic Submission | WebGIS-SPD

Reference in New Issue View Git Blame Copy Permalink