WebGIS feature development

SPEC

Technical spec

Frontend: Vue 3
TypeScript
Map: OpenLayers
Backend: Spring Boot

FIT

A good fit when

A map screen has to be added to a system that is already in production
Work handled in lists and tables now needs the location checked often
Screens must be added while the existing authentication and permission model stays as it is

PREBUILT

Example components

These components illustrate the proposed structure. Template features and scope will be confirmed after implementation and verification.

Working map screen: A base map, layer list, zoom controls, and attribute lookup on feature click already run.
Layer and selection state: Layer visibility and the map-to-list selection link are already wired through a store.
WMS/WFS integration spec: Request and response formats with the map server, and the error handling rules, are settled.
Hook for existing auth: The API call layer isolates one connection point, so existing tokens or sessions pass straight through.

The layout and design are adapted to each project.

SCREENS

Example screens

Example screens to explore layouts and flows. The final template design and style have not been decided yet.

A map-based entry screen with a combined search box and the work menus. — Map entry screen · Search and the work menus are connected on a single screen.

A screen where the selected list item is highlighted on the map with a detail panel open on the right; work data is masked. — List, map, and detail linked · Selecting a row highlights the feature on the map and opens the detail panel.

SCOPE

In scope

Deliverables

The agreed map-based screens and features
Integration APIs or an integration specification
Test results and deployment instructions

In scope

Requirement capture and screen definition
Implementation of map screens and connected features
Connection to the existing authentication and permission model
Verification against the acceptance criteria and one revision round

Out of scope

Building or cleansing new spatial data
Full rebuild of the existing system
Third-party map and API usage fees
Continuous monitoring of production servers

Scope and exclusions are defined before the work starts. The schedule and detailed terms are fixed in the SOW after we talk.

The problem this solves

Tables and lists alone make it hard to judge work where location matters. A screen that shows the situation on a map and leads straight into the next task removes steps between checking and acting.

How it runs

Review the workflow and the structure of the existing system.
Fix the screens, feature list, and acceptance criteria in the SOW.
Implement the screens and connected features with interim reviews.
Verify behaviour against the acceptance criteria and support deployment.

Scope versus additional development

Screens and features listed in the SOW that do not meet the criteria are defects. New screens, new data integrations, and new statistics are additional development handled through a change request.

FAQ

Frequently asked questions

Do you need access to the existing code?: Reviewing the existing screens and API structure is what makes an accurate scope possible. Where source access is not available, the scope is narrowed and based on documentation and the screens.
Which map library do you use?: Mainly OpenLayers and MapLibre. If the existing system already uses another library, that setup is reviewed first.

Need a particular setup?

Tell me which screens and integrations you need, and I will come back with what is feasible.

Ask about this setup