Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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 point layer for manholes and other point objects. This layer must include a unique reference for each object.

Better data can be created by adding a line layer to the point layer for the linear assets. This layer must include a unique ID for each object and also the upper node and lower node point IDs from the point layer. Every upper and lower node in the line layer should exist in the point layer.

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:

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

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.)

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.


Back to the top.

  • No labels