GIS - Shapefiles and Web Map Services

Created by Ben Hayes, Modified on Mon, 27 Apr at 8:58 AM by Ben Hayes

Introduction

About this guide

This document has been produced to provide information on Shapefiles and WMS Overlays, helping teams create and import geo-spatial data into MCS.

Supported GIS Integration Methods

Option 1 – Shapefiles (File-based)

Static spatial datasets loaded directly into MCS

Suitable for boundaries, zones, and reference layers

Shapefile is applied to Service Request after submission

Updates require file resubmission and reload

Note - a standard charge applies for loading shape file data into the MCS Platform - please contact isupport@abavus.co.uk for further details.

Option 2 – WMS Map Overlay (Service-based)

Consumes externally hosted OGC-compliant WMS services

Dynamic rendering of layers within the Portal map

Optional feature interrogation using GetFeatureInfo

Suitable for live or frequently updated datasets

Layer is applied as part of Service Request submission

Note - a standard charge applies where URL whitelisting is required as part of integration with the MCS Platform.

Option 3 – Rest API (Service-based)

Consumes externally hosted OGC-compliant WMS services which are REST based

Suitable for live or frequently updated datasets maintained in your GIS

Layer attributes are queried as part of Service Request Submission and can be used to determine workflow

Note - a standard charge applies where URL whitelisting is required as part of integration with the MCS Platform. Charges may also apply as part of standard web service calling.

Shapefiles

About Shapefiles

Shapefiles are used to define static geographic features (such as boundaries, zones, and polygons) that can be visualised and referenced within the platform, typically within a council’s operational boundary.

The My Council Services (MCS) platform supports ESRI Shapefiles to enable geo-location-based determination for Service Request submission.

Shapefile data is pre-loaded into the system and is not queried dynamically in the same way as WMS overlays.

Technical Prerequisites and Constraints

Client Support

Shapefile-based mapping is supported within the MCS Portal

Behaviour and visibility are subject to configuration and testing prior to Production deployment

Data Format

Shapefiles must comply with the ESRI Shapefile specification and be provided as a complete dataset

The format is non-topological, storing geometry and attributes only

Required Shapefile Components

Each shapefile submission must include the following mandatory files:

.shp – Shape File (Mandatory)

Contains the geometric representation of each feature (e.g. polygons, lines)
Each record describes a shape using a list of vertices

.shx – Shape Index File (Mandatory)

Provides positional indexing linking geometry records in the .shp file for efficient spatial access

.dbf – Attribute Table (Mandatory)

One record per geometry
Record order must match the .shp file exactly
Geometry–attribute alignment is based on record number

The following file is optional but strongly recommended:

.prj – Projection Definition File (Optional but Recommended)
Defines the coordinate reference system (CRS) used by the shapefile

Coordinate Reference System (CRS) Requirements

Recommended CRS:

EPSG:27700 – OSGB 1936 / British National Grid

Alternatively supported:

EPSG:3857 – WGS 84 / Web Mercator

All shapefiles must be:

2D only
Contain X and Y coordinates only (no Z or M values)

Shapefile Structure and Attribute Requirements

Where multiple shapefiles exist, it is strongly recommended that they are:

Merged into a single shapefile
Provided with consistent and complete attribute data
Supplied as a single ZIP file containing all required components

Feature display within the MCS platform is driven by attribute data:

Each polygon or feature will be displayed using the value held in the 'Name' attribute column

If multiple polygons are merged:

Correct and complete attribute values must be provided for each feature
Any required attribute restructuring or reconciliation must be agreed in advance
Additional development effort may be required where merging or remapping is needed

Loading, Testing, and Deployment

Shapefile upload typically takes 2–3 working days, depending on size and complexity

All shapefiles are initially loaded into a demo environment for validation, functional testing, and customer review and sign-off

Following approval, deployment to the Production environment typically requires a further 2–3 working days, subject to development team resource availability

There is a cost associated with the loading of shapefiles into the MCS Platform.

Relationship to WMS Overlays

Here’s how shapefiles are related to WMS Overlays:

Shapefiles provide a static, pre-loaded spatial dataset

WMS overlays provide dynamic, service-based map rendering with optional GetFeatureInfo querying

Both methods:

Use aligned CRS expectations (EPSG:27700 / EPSG:3857)

Support polygon-based visualisation within the Portal

Rely on well-structured attribute data for meaningful display and use

Selection of the appropriate approach (WMS vs Shapefile) should be based on update frequency, ownership of spatial data, and operational requirements.

WMS Map Overlay

The My Council Services (MCS) platform supports the consumption of external OGC-compliant Web Map Service (WMS) layers for visualisation and feature interrogation within the Portal Location Picker. Configured layers are rendered as overlays on the base map, with optional GetFeatureInfo support to retrieve attribute data for population into Service Requests.

Technical Prerequisites and Constraints

Client Support:

WMS overlays are supported only on the MCS Portal
Mobile applications do not currently support WMS overlays

OGC / WMS Standards:

Supported WMS versions: 1.1.1 and 1.3.0
The service must support GetCapabilities, GetMap, and GetFeatureInfo

Security and Network Access:

HTTPS-only WMS endpoints are supported
The service must be network-accessible and whitelisted to allow attribute data to be returned
Layers must be open and publicly accessible with no authentication or access restrictions

Spatial Reference Requirements:

Layers must be available in EPSG:3857 (Web Mercator)

Querying and Attributes:

Layers must be marked as Queryable if attribute extraction is required
Attribute extraction is dependent on valid GetFeatureInfo responses

Layer Naming:

Layer identifiers must not contain spaces

Configuring WMS Overlays

If you want to configure a WMS Overlay, please follow the instructions below:

1. Access Plugin Configuration

Navigate to Administration > General > Plugin

2. Select Map Overlay Plugin

Select Map Overlay from the Plugin list to view or create overlays

3. Create a New WMS Overlay

Click Add to register a new WMS overlay

4. Configure WMS Service Parameters

Provide the core configuration details including Type (WMS), Name, Version, Service URL, Map Format, and Information Format.

Namespace Handling:

Set Is namespace available to Yes if attributes are namespace-qualified
Set to No to use default version-based attribute handling

5. Define Overlay Layers

Add one or more layers corresponding to WMS layer names returned by GetCapabilities

6. Layer Configuration

Configure each layer with the required spatial reference, CRS/SRS, map format, and query ability settings

Search Radius:

Controls spatial tolerance for feature selection
Defaults to 3 if not specified and may require tuning

REST API Integration

The My Council Services (MCS) platform supports the use of REST Api to query layers within your own GIS system for feature interrogation using data captured from the Portal Location Picker such as coordinates (Easting, Northing) or UPRN. The REST call is made via a form component which can return data stored in your GIS layer and capture this data in form fields in a Service Request.

Technical Prerequisites and Constraints

Client Support:

Layers being queried must be open and publicly accessible with no authentication or access restrictions

The REST URL require whitelisting for data to be returned to the form

We recommend that the REST URL root remains the same if additional layers are added as this will prevent further whitelisting from being required.

GIS System compatibility

Your GIS system will need to support REST API.

Security and Network Access

The service must be network-accessible and whitelisted to allow attribute data to be returned. Layers must be open and publicly accessible with no authentication or access restrictions

Spatial Reference Requirements

We recommend layers are available in EPSG:3857 (Web Mercator)

Querying and Attributes

Regarding the attributes and querying of the integration:

Layers must be marked as Queryable if attribute extraction is required
Attribute extraction is dependent on valid REST API response
Layer identifiers must not contain spaces