# 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*