GIS Process Guide

Background

Spatial information was being created, structured, checked and delivered differently on every project. Without a standard, quality depended on who happened to be doing the work.

What I built

A formal standard governing how GIS work is produced across all Taylor Woodrow projects, aligned with ISO 19650, UK MUDDI and NUAR underground asset standards, and the company ArcGIS Enterprise schema.

It covers the route to software access and the training expected before someone uses it, project data requirements covering source formats, licensing and coordinate reference systems, and the default authoring parameters that apply where a project does not specify its own.

How it works

The core is an eight-step workflow: Common Data Environment setup, data identification, data acquisition, data ingestion and processing, hosting and review, quality assurance and peer review, submission and distribution, and archiving and traceability.

It defines named roles, GIS Engineer and Senior GIS Engineer, with distinct self-check and peer-review responsibilities, an ISO 19650 aligned WIP, Shared and Published status model, and a formal versioning scheme using P01 and S0 to S4 for delivery datasets.

Outcome

Authored by Hamish Visser, peer reviewed and formally approved by the digital engineering leadership. Now the reference standard for spatial delivery across projects.

Technical reference

The standard itself is a Taylor Woodrow document and is not reproduced here. What follows is the thinking behind it: the problems a spatial standard has to solve on a contractor's projects, and the position taken on each one. All of it applies to any contractor delivering spatial information under ISO 19650.

What a spatial standard is for

Five properties, and every rule in a document like this exists to produce one of them. Data should be consistent, produced using standard methods, parameters and naming; traceable, supported by metadata, version control and quality checks; compliant with ISO 19650, client requirements and internal standards; interoperable with BIM, CAD, survey and the rest of the digital environment; and fit for purpose, reliable enough for engineering, construction and assurance to depend on.

The first decision is that it complements project and client standards rather than replacing them. Where a contract mandates a method, format or submission process, the contract takes priority, and any deviation from the default is recorded in the project GIS Execution Plan. A standard that cannot yield to a client requirement gets ignored on the first project that has one.

Where it sits against published standards

ISO 19650 is the spine. GIS data forms part of the project information model and is managed through the lifecycle under ISO 19650 principles, which is what drives the work in progress, shared and published states and the revision format. UK MUDDI and NUAR inform data structure and attribute standards where underground asset data is in scope, without overriding project or client requirements. Beneath both sits an internal default schema, which is the part that has to be a company's own.

Schema and authoring positions

The defaults are unremarkable and deliberately so: British National Grid for UK projects, other regions confirming their coordinate reference system at initiation, Esri File Geodatabase as the authoring format, ArcGIS Pro publishing to ArcGIS Enterprise as the primary environment, with FME for automated conversion and QGIS and QField where ArcGIS access is limited or field capture is needed.

The schema rules are more opinionated than most internal standards bother to be, and the reasoning is the transferable part. Field naming is fixed to one convention and held consistent in type and length across datasets, because inconsistent naming is what breaks automation later. Schemas are kept lean, since an oversized text field costs nothing to create and something on every subsequent read. Numeric attributes use numeric types rather than strings, which protects data integrity and avoids the performance overhead. Standard point, polyline and polygon geometry is the default, and multipart geometry is avoided unless a requirement demands it, because multipart features survive the round trip through other software far less reliably than people expect.

Every incoming dataset carries accreditation covering data owner and source reference, licensing terms and usage restrictions, capture date and method, and capture location with spatial accuracy notes. Without it a dataset cannot be defended at handover, and licensing in particular cannot be reconstructed after the fact.

The eight steps, and the one that catches people

The lifecycle runs from Common Data Environment setup through data identification, acquisition, ingestion and processing, hosting and review, quality assurance and peer review, submission and distribution, to archiving and traceability.

One detail in step one is worth pulling out, because it is the kind of thing only learned by being caught by it: delivery formats have to be confirmed at the start, because some GIS formats are incompatible with CDE constraints. If the CDE does not permit ZIP files, shapefiles cannot be used at all, since they depend on several separate files to function. Agreeing formats early avoids finding that out at submission.

The single source of truth rule

Once a dataset is published, the hosted layer becomes the working layer and local files are no longer edited. Editing happens against the hosted feature layer, or through agreed automation.

The reason is downstream: tools such as Civil 3D pull the latest data through the Esri connector, and that only works if the hosted layer is genuinely the most current version. Side copies break it silently. The rule does not apply to datasets authored in applications other than ArcGIS Pro, such as InfraWorks or QGIS, where the authoring application stays the system of record and read-only views are published for coordination.

Roles and the review gate

Two roles, and the gate between them is the mechanism the whole document depends on. A GIS Engineer creates, processes and manages datasets, self-checks their own outputs against a defined list and flags issues upward. A Senior GIS Engineer owns governance, maintains the templates and schemas, approves changes to them, and reviews all data before formal submission.

The self-check covers geometry validity, coordinate reference system, attribute and metadata completeness, naming compliance and third-party licensing. The peer review covers spatial alignment against base mapping and other project datasets, schema consistency, and confirmation that the self-check was actually done, before sign-off. Splitting it that way matters, because the checks a person can run against their own work are not the same as the ones that need a second pair of eyes, and a single combined checklist tends to get treated as one person's job.

Information states and versioning

Data moves through three ISO 19650 states before formal submission. Work in progress, actively being created or edited and not visible outside the immediate team. Shared, internally reviewed and available for wider project comment, which is where the peer review happens. Published, having passed all checks, with sign-off required for formal client submissions.

Only delivery datasets carry formal version control, in the ISO 19650 format: P01 upward for preliminary issues for review and comment, then S0 suitable for coordination, S1 for information, S2 for construction or client use, S3 as a construction record and S4 as-built. Internal working data is dated and described clearly instead, without revision numbering.

Each version records the changes made, the date and the author. Superseded versions are retained and archived rather than deleted. Where a client CDE uses a different revision format, that format takes precedence and the deviation is documented.

Declared limitations

The standard states its own limits, which is the part most internal standards skip. Project and client requirements take precedence over everything in it. It is specific to one business unit and does not claim to be a group-wide standard. It does not cover every scenario, and bespoke configurations, custom tools or unusual formats are handled through the project's information management process instead. And it accepts that tools, client platforms and industry standards change during a project lifecycle, so it points at the current standards rather than presenting itself as permanent.