Data Layer Formats for WinCan Enterprise
- Steve Peregrine
- Paul Woodhouse
- Keith Schrott
Â
Author
Steve Peregrine BEng Hons, Senior Technical Manager
Page Contents
Introduction
This is a generic guide to the basic requirements of data layers for getting the best and most user-friendly results from WinCan Enterprise.
Layers
Layers can be imported from well known formats including Shapefile, Geo Database and hosted online feature services.
The absolute minimum that WinCan Enterprise requires is a line layer for pipes and a point layer for manholes/nodes. The line layer must include a unique reference for each object and also the upper node and lower node point IDs. Where this can be done, every point item ID referenced in the line layer should exist in the point layer to avoid data problems further down the line. The advantage of adding the point data is that the points can now carry their own attributes which expands the inspection capabilities of the nodes.
Currently, we can only use 1 point layer and 1 line layer in an Enterprise project for assets. There are plans to extend this in the future.
Optionally, for even further improved user experience, access to the customer’s background mapping via web feature service is also very useful. This is not an asset layer and is used to make the assets viable against their surroundings to ease the workflow for operators and managers.
Layer Attributes
The absolute minimum requirements for data layers are described in the section above ‘Layers’.
The user-friendliness of the data can be further enhanced in almost all global drainage inspection standards by adding the following data where items in red are mandatory, all rows where the layer exists:
Line Layer
Unique Asset ID
Asset Upper Node Unique ID (Asset must exist in the point layer)
Asset Lower Node Unique ID (Asset must exist in the point layer)
Major Dimension (usually height or diameter)
Minor Dimension (usually width)
Asset Material
Asset Shape
Asset Usage
Alternative Asset ID
Town Name
Street Name
District Name
Asset Depth at Upper Node
Asset Depth at Lower Node
Asset Type (i.e. gravity sewer, rising force main etc.)
Point Layer
Unique Asset ID
Alternative Asset ID
Cover Level AOD
Asset Depth
Asset Type (i.e. manhole, gully, catchpit etc)
Asset Style (i.e. real node or virtual modelling node)
Asset Usage
Town Name
Street Name
District Name
Depending on the target standard being used, it may be possible to use many more useful pieces of information over and above what is described here.
Column names should be intuitive.
In the attributes of points and lines, we need to understand measurement units for numeric data where applicable.
Dissolved Lines
It is important for us that lines are not split into sub-segments at virtual nodes.
Think of how you would insert a CCTV camera into a drain - you need a manhole at each or either end to do this and you cannot do it mid-way through a pipe at a virtual modelling node.
It is common for line data in asset management systems to be broken down into multiple sub sections and this doesn’t work for our inspection teams. Please ensure that pipe segments are dissolved into single lines between accessible node types, like manholes, gullies, catch basins etc and not between virtual modelling nodes.
Note - this does not mean that the virtual modelling nodes have to be removed. They can be very useful for example like where a lateral connects to a main sewer. This would be the downstream node of the lateral.
What it means is that the lines of the sewers must be continuous from one access point to the next.
Field Translations
What are we talking about? Consider a database structure where the shape code used for circular pipe is CIRC as an example, but the target standard only understands C for this information. Here we must translate CIRC into C by understanding the meaning of the customer’s database keys. Another example could be a material code where there is no equivalent lookup in the target standard, but there as an option for ‘Other’, so we can make a suitable translation by deduction.
Where codes are used for values in data columns, we need to either have for every column that has database internal keys:
The lists translated into those used in the local inspection standard up front.
'Plain language’ lookup lists of all possible (may include some that are not in the current data set) field values so that we can create translation mappings into the target standard on WinCan Enterprise.
Note - the target standard may possibly not include all of the options in the customer’s data, so assumptions may need to be made, or field values nulled in some cases.