interim advice note 184/14 standard conventions, file ... › ha › ... · highways agency data...

Interim Advice Note 184/14 Highways Agency Data & CAD Standard

INTERIM ADVICE NOTE 184/14

Highways Agency Data & CAD Standard Instructions on naming conventions, file types and data structures for the delivery and transfer of CAD / BIM files to the Highways Agency and its supply chain. Summary The Government Construction Strategy requires fully collaborative 3D BIM by 2016. This IAN puts in place some key enabling measures to facilitate this on Highways Agency projects. It implements the methodology of BS1192:2007 to give a consistent approach to file naming across the whole supply chain. It specifies acceptable file formats and gives rules for their use. Instructions for Use This guidance is to be adopted for all new projects.


IAN 184/14 of 41 Sept 14

Amendments 08/2014 First edition


IAN 184/14 of 41 Sept 14

Table of Contents 1. General requirements for data files

1.1. Units 1.2. Coordinates 1.3. File types

2. File names

2.1. Project 2.2. Originator 2.3. Volume 2.4. Location 2.5. Type 2.6. Role 2.7. Number 2.8. Suitability and Revision

3. CAD model and drawing files

3.1. Content 3.2. File formats 3.3. CAD Layer names 3.4. CAD composition and presentation

4. Survey data

4.1. Topographic survey 4.2. Geotechnical survey 4.3. LIDAR point cloud 4.4. Orthorectified aerial survey 4.5. Underground asset survey 4.6. Overhead power cable survey

5. Geometric modelling data

5.1. Alignment 5.2. Terrain

6. Asset coding

7. Feedback and Enquiries 8. Normative References

Appendix A Ordnance Survey Data Supply Models Appendix B Project Information Search Table Appendix C Example CAD Layer Names Appendix D Explanatory Notes


IAN 184/14 of 41 Sept 14

Executive Summary The Highways Agency, as executive body to the Department for Transport, has adopted the UK Government Construction Strategy which requires fully collaborative 3D Building Information Modelling (with all project and asset information, documentation and data being electronic) as a minimum by 2016. The Agency shares the vision that significant improvement in cost, value and carbon performance can be achieved through the use of open sharable asset information. BIM will facilitate the delivery of consistently high quality asset data for use in operational, financial and engineering decision making and planning processes across the Agency. The HA will:

move from a control focus to a decision based delivery model integrate teams to accelerate delivery and reduce waste drive improvement, innovation and deliver value

The HA acknowledges the challenges that it and the supply chain will face in the adoption of BIM and as such is clear that HA will need to adopt a pragmatic but progressive approach to the adoption of BIM. This IAN has been produced as a first step to define the governance needed for the implementation of BS1192:2007 and PAS1192-2. It will enable the supply chain to configure their systems and Common Data Environments to produce and receive information in a consistent manner on behalf of the HA. The requirements of PAS1192-3 (for the operational phase) and BS1192-4 (UK Implementation of COBie) will be addressed at a later stage. As the Agency undertakes improvements to its Asset Management systems, and as technology and process for the design and construction of infrastructure improve, this IAN will be updated accordingly.


IAN 184/14 of 41 Sept 14

1. General Requirements for data files

1.1. Units All coordinated model files shall be in metres.

Standard detail drawings, sections and component models may be in metres or millimetres. Where such details are incorporated into coordinated models they shall be scaled to metres. Dimensions may be displayed in metres or millimetres in accordance with normal practice.

1.2. Coordinates

All projects shall be developed in the appropriate local grid as defined by IAN 99/07. All levels shall be relative to Ordnance Datum Newlyn (ODN). Supporting files of coordinated data may be in the Ordnance Survey’s National Grid 1936 (OSGB36) coordinates. The selected zone and height band identifier for the project, as defined in Section 5 of IAN 99/07 (e.g. B17H1), is to be recorded in the Highways Agency Supply Chain Portal. See Appendix B

1.3. File Types No limitation is imposed by this standard on the software, file formats or versions used within an organisation, or by mutual agreement between supply chain parties. However, where delivery is to the HA, or to a project data room, or where future recipients are unknown, or they use incompatible systems, then the appropriate file types, formats and structures defined in this standard shall be used. No file format version that has been fully released for less than two years may be used for such delivery without agreement.

1.4. Rationale of data structure This standard sets a consistent framework for the creation and development of information that may eventually feed into the HA asset databases. Property data may be attached to the geometric modelling during the design and construction phases.

No folder structure is stipulated. The supply chain is free to choose an appropriate document management method.

Files are named in accordance with BS1192:2007, using the conventions for each field set out in Section 2,

Layers within CAD files are named in accordance with BS1192:2007, using the conventions for each field set out in Section 3.3. The Classification field of the layer name adopts Uniclass2.

3D-modelled asset objects will each carry an assigned unique identifier (as an attribute, tag, GUID etc). Each object may correspond to all, or part of, one of the assets in the HA databases. The unique identifiers are used to link the modelled objects to tabular schedules, databases, details, specifications, photographs etc in BIM viewing and manipulation tools, and the HA databases.


IAN 184/14 of 41 Sept 14

2. File names All deliverable or exchanged computer files that are created specifically for the HA project shall be named in accordance with this standard. Files that are not specific to the HA project under consideration, and which have well recognised naming conventions, need not be renamed for each project. Examples of these include tiled Ordnance Survey vector or raster mapping, files from adjacent HA or other infrastructure projects or third-party record drawings that are named in accordance with BS1192:2007. BS1192:2007 defines that file names are composed of “fields”, separated by hyphens, in the specific order:

Project-Originator-Volume-Location-Type-Role-Number.Extension

The file extension is not affected, and remains associated with the relevant software.

No other hyphens are permitted in the file names. Where separators are needed within fields, the underscore character shall be

used.

In order to achieve file names that have readily understandable names across all HA projects, the conventions to be applied within each field are as follows:

2.1. Project

The project field shall be the characters “HA” followed by the Highways Agency 6-digit PIN (Project Identification Number). A lookup table of PINs will be held in the Highways Agency Supply Chain Portal

2.2. Originator The Originator field shall contain the unique abbreviation for the company or organisation that creates the file. Abbreviations may be from 2 to 6 characters long Suppliers shall register their abbreviation with the HA Registered abbreviations and their owners may be checked on the Highways Agency Supply Chain Portal. Examples

HA Highways Agency FBA Fred Bloggs Associates SJJV Smith and Jones Joint Venture


IAN 184/14 of 41 Sept 14

2.3. Volume The Volume field shall be a 3-character code from the Table 2.3. The first character denotes the category to aid recognition of the codes. Electronic document management systems for whole projects may need other categories that are outside the scope of this IAN, which concentrates on geographic aspects.

Table 2.3 Category Code Purpose General GEN Scheme wide generic information

Highways HAC Highway Approvals & Consents HAW Accommodation Works HDG Drainage HEL Power / Electrical HFE Fencing HGT Geotechnical HGN General HKF Kerbs, Footways and Paved Areas HLG Road Lighting HMC Motorway Communications HMK Road Markings HML Mainline Geometric Layout HPV Road Pavements HRR Road Restraint System (Vehicle and Pedestrian) HSC Site Clearance HSN Traffic Signs HSR Side Roads Geometric Layout

Structures SBR Bridges and Major Culverts SGN General SGT Geotechnical SGY Gantries SMA Masts SMN Minor Structures and Culverts SRW Retaining Walls SSP Special structures STU Tunnels

Environment EAC Environmental Approvals & Consents EAQ Air Quality EBD Biodiversity EGN General EGT Geology and Soils EHR Heritage/Historic resources ELS Landscape ENM Non-Motorised Users ENV Noise & Vibration ETS Townscape EWE Water Environment

SurVey VES Environmental Survey VGT Geotechnical Investigation VTR Traffic Survey VTO Topographical VUT Utilities

Legal LSI Statutory Instruments


IAN 184/14 of 41 Sept 14

2.4. Location

The Location field is flexible in order to accommodate the variety of disciplines and type of project. It may indicate a specific structure on a project, or a position along the route. The general form should be optional letters followed by an integer number. The overall field length should not exceed 10 characters. It is recommended that this number increases in the direction of mainline chainage, to facilitate sorting. It may be sequential, or represent a chainage. Leading zeros may sometimes be desirable.

Examples of Volume and Location Codes -HML-12000- Mainline road layout, starting at Ch 12000 -HRR-12000- Mainline road restraint, starting at Ch 12000 -HDG-12345- Mainline drainage network - outfall at Ch 12345 -HML-J16- Mainline road layout through Junction 16 -HRR-J16- Road restraint for Junction 16 -HDG-J16- Drainage network for Junction 16

-HML-A12000- Mainline option A, starting at Ch 12000 -HML-B12000- Mainline option B, starting at Ch 12000 -HML-M4_12000- Mainline M4, starting at Ch 12000 -HML-M5_25000- Mainline M5, starting at Ch 25000

-SBR-B05- Bridge No 5 -SGY-GA12345- Gantry at Ch 12345 on A-carriageway

2.5. Type The Type field shall be from the fixed list in BS1192 Section 9.2, or one of the additional codes in Table 2.5. It is recognised that other type codes will be required by projects for files managed in the CDE for functions beyond CAD and BIM. These are outside the scope of this IAN.

Table 2.5 Code Type

SK Sketch (not to scale) DE Detail Drawing (to scale, but not derived from model

information) Examples

DR Drawing derived from model information M2 2D model M3 3D model


IAN 184/14 of 41 Sept 14

2.6. Role The Role field shall be either a single character from the fixed list in BS1192 Section 10.2 or one of the two-character codes from Table 2.6 Examples

D Drainage, Highway Engineer E Electrical Engineer S Structural Engineer

Table 2.6

Code Role GE Geotechnical Engineer LE Lighting Engineer TE Technology Engineer EN Environmentalist TR Traffic Engineer

etc

2.7. Number The number need have no significance, other than to give a unique file name. The originating organisation may choose to allocate blocks of numbers, or to generate them as needed. Each project should fix a consistent length from 4 to 6 digits, using leading zeros where necessary.

2.8. Suitability and Revision All file issues and transfers shall be accompanied by an electronic transmittal document that tabulates for each file:

File Name File Description Suitability code as specified in BS1192 Table 5 Revision code as specified in BS1192 Section 15.3.3. Software dependencies Warning to open Read-Only if dependent software unavailable

The text in the transmittal shall be capable of being copied as characters, not solely as an image. Example File Name

HA539859 -FBA-HLG-J17-M3-LE-0001.dgn

Project HA539859 M1 J19 to J16 (HA PIN) Originator FBA Fred Bloggs Associates Volume HLG Lighting Location J17 Junction 17 Type M3 3D model Role LE Lighting Engineer No 0001 1 Extension dgn Microstation


IAN 184/14 of 41 Sept 14

3. CAD model and drawing files

3.1. Content

The goal of 3D interoperable BIM brings a change in the primary purpose of CAD drawings. They are no longer intended purely for interpretation by the human eye. With BIM they need also to be capable of interrogation and analysis by software processes. CAD entities that bound or enclose 3D space are preferred to wireline representations. Entities such as solids and “watertight” (topologically closed) meshes have intrinsic properties of volume. These, along with other meshes, surfaces and faces, have surface area. Some extruded shapes may have readily found length and cross-sectional area. Adopting these kinds of entities for the components of the design will facilitate time and cost modelling. Where both 3D and 2D representations are required, they shall be consistent.

One form shall be derived automatically from the other. The accuracy and completeness of the 3D modelling shall be appropriate to the

stage of the project and the intended use of the model. Unique identifiers, other than the internal identifiers of the CAD system, should be

assigned to each component. Schedule information shall be prepared in database-ready form. For example

database tables or spreadsheets (for each relevant discipline) that give all properties for each component in single-line records. The property names shall be the column titles, starting with the unique identifiers in the first column.

Attention shall be paid to the property requirements of the HA Asset Data Management Manual (ADMM). Individual designed components shall not include more than one Asset Type from the ADMM.

Point Assets Point Assets shall be represented by dimensionally correct 3D components,, and

optionally by 2D symbols where the true size of the component could be overlooked on the finished drawing.

The insertion point and axes of such components and symbols shall be meaningful and logical in the context of that object’s purpose on the project.

Linear Assets Linear Assets shall be represented by dimensionally correct 3D components, and

optionally by 2D line styles where the true size of the component could be confusing in a plan view.

It is acceptable to model thin components, such as safety fence rails and posts, as extruded profiles

The “spine” line of any extrusion shall be in a meaningful and logical position on the cross section.


IAN 184/14 of 41 Sept 14

3.2. File Formats As there is no widely used open format for CAD, the commonly used proprietary dwg, dgn and rvt, and the open BuildingSmart ifc formats are acceptable. Files that have software dependencies beyond standard CAD, for example 3rd-party add-on products or primary vendors’ layered products, shall declare these in the transmittal information. Those that would be corrupted if re-saved without those software products shall be declared Read-Only.

3.3. CAD Layer names The term “Layer” here indicates generic grouping functionality in the chosen CAD system. An optional Usage field has been added to the fields defined by BS1192:2007 in the position shown below. See section 3.3.4 for explanation Role-Classification-Presentation[-Usage]_Description

The field separator shall be hyphen. No other hyphens may be used within a field If separators are required within a field, the underscore character shall be

used. No characters may be used apart from upper-case and lower-case letters,

digits, space, dollar, underscore and hyphen. 3.3.1. Role The Role field is as defined in Section 2.5

3.3.2. Classification The Uniclass2 classification system from the Construction Project Information Committee (CPIC) shall be used. For feasibility stages, classes will generally be taken from the tables: Entities (En), Entities by Form (EF), and Elements (Ee). For detailed design, the classes should be taken from the tables: Systems (Ss) and Products (Pr). The table for CAD (Zz) is applicable to drawing-related matters at all stages.

This consists of a two-character table identifier, followed by two to four pairs of digits, each pair separated by underscores.

Example “Ss_25_36_90_16” [Concrete safety barrier (CSB) system]

For items that are covered by Asset Codes in the HA Asset Data Management Manual, the Asset code shall be appended to the Uniclass2 code, after a space

Example “Pr_35_31_85_90 LORM” [Thermoplastic road marking – Longitudinal road marking]


IAN 184/14 of 41 Sept 14

3.3.3. Presentation The Presentation field shall be from the fixed list in BS1192 Section 12.2

D Dimensioning H Hatching and shading M Model related P Paper related T Text

3.3.4. Usage The Infrastructure Asset Data Dictionary for the UK (IADD4UK) defines Physical Asset Status in Asset Data Dictionary Definition Document (AD4) Generic Attributes.

Object-based systems should set this attribute directly on the asset’s object. Proposed and existing assets defined in layer-based systems shall include an additional Usage field that encodes the appropriate AD4 Asset Status from Table 3.7

Table 3.7

Code AD4 Asset Status Description Dn Design

Asset being designed, but not yet approved for construction

Ma Manufactured

Asset has been manufactured/ Fabricated but has not entered the logistics supply chain

Lo Logistics

Asset is in transit from its place of manufacture but has not arrived in the site depot

Si On Site

Asset is in the depot/store and is ready for use in construction

Cn Construction

Asset being procured, built and installed but not yet under formal testing or commissioning

Tc Test And Commissioning

Asset under formal test and commissioning programme, but not commissioned

Cd Commissioned

Asset that has passed testing and commissioning but is not under control of the Infrastructure Manager

Op Operational

Asset that has been commissioned and is under control of Infrastructure Manager

Se Spare

Equipment that is available for use, but is not installed

Ty Temporary

Asset which supports a programme of works but will not be handed over to an Infrastructure Manager

Dc Decommissioned

Asset decommissioned, but remaining on site

Rm Removed

Asset decommissioned and removed from site


IAN 184/14 of 41 Sept 14

3.3.5. Description

3.3.5.1. Descriptive Text The description should give a clear and concise explanation of the Uniclass2 code. The full text description from the CPIC table is generally unsuitable, as these can be long and may contain punctuation characters. Consistency is strongly encouraged in the descriptive text used, through the use of template / seed files appropriate to each discipline. Example layer names with descriptions are given in Appendix C

3.3.5.2. Options Where it is necessary to distinguish between different types or configurations of items that fall under the same classification code, one or more options may be appended to the description. Each option shall be of the form <underscore>OptionName<space>OptionValue

Example D-WR_90_25_24-M-Dn_Ducts_Dia 110_Cover 600_Count 1_Type multi (Single proposed multiduct) D-WR_90_25_24-M-Cd_Ducts_Dia 100_Cover 850_Count 4 (Block of 4 commissioned ducts to be retained) The options can be interpreted by software to turn polylines into schedules, quantities, 3D models etc. It is not proposed to limit or dictate how any optional information is used, but clarity is encouraged.


IAN 184/14 of 41 Sept 14

3.4. CAD Composition and Presentation Specific guidance is given for AutoCAD and Microstation. The general guidelines also apply to presentation from other systems.

3.4.1. Composition Drawing sheet files shall compose the necessary reference files, frames and

notes to achieve the required drawing. Drawing sheet files shall not contain more than one drawing (ie multiple tabs

are not permitted), so that management and version control are not compromised.

Drawing sheet files shall not be attached as reference files, except where the capabilities of the CAD system make this unavoidable, for example vertical profiles, developed elevations etc.

Model drawings may reference other model drawings during development, but shall not retain those references when shared or used by drawing sheet files.

However, for convenience, otherwise empty arrangement drawings may be saved with assemblies of reference files such as survey tiles. These arrangements can thus be attached in a single command.

Drawing sheet files shall attach model drawings on dedicated layers, one for unclipped content and one for each clip boundary such as cut lines.

Model files shall be attached in model space; frames etc shall be attached in paper space

Example title block layout

3.4.2. Interoperability Interoperability issues shall be resolved at project outset to ensure consistent appearance of CAD elements (e.g. line type/styles, text, dimensioning, hatching, etc.) when translating between software packages. The following guidelines for AutoCAD/Microstation shall be adopted:

Use the native Microstation Line Styles and AutoCAD Line Types where possible.

When editing AutoCAD files in Microstation, use the Line Types that import with the drawing.

When editing AutoCAD files converted from Microstation, use the Line Styles that import with the drawing.


IAN 184/14 of 41 Sept 14

Note that the AutoCAD annotative functionality does not translate to Microstation.

3.4.3. Text Style

The following settings shall be adopted: Arial True Type font shall be used for all annotation. Text width factor = 1. Line Spacing for interoperability:

AutoCAD = 1.0x (default): Microstation = 0.667. Justification = Left Centre (except for titles which can be Centre justified). UPPER CASE is preferred and should be used for all annotation, titles and

labels. Sentence case is permitted. Abbreviations such as ‘mm’, ‘kg’ and ‘kN’ shall

use lowercase appropriately. Text case adopted shall be used consistently across a set of drawings. Text shall not obscure content. Text shall be legible when printed at reduced size (e.g. A1 to A3).

3.4.4. Text Sizes

The following text sizes shall be adopted

Plotted Height (mm) (At full size)

Purpose

1.8 A4 & A3 sketches 2.5 General annotation, labels and dimensions 3.5 More prominent notes, labels, dimensions and minor

headings 5.0 Headings, titles and grid text 7.0 Larger headings

3.4.5. Dimensions The following settings shall be adopted:

Filled 2.5mm arrow heads shall be used Text Justification = Above and Centred (Default). Dimension line weight shall be set to 0.18mm. Dimension text height shall be consistent with general text height. Dimensions shall be created using the software application dimensioning

tools. Dimensions styles and text heights shall be consistent

across a set of drawings. Dimensions shall be legible when printed at reduced size

(e.g. A1 to A3). Dimensions shall be Associative without dimension overrides. Dimensions should be Annotative (ACAD) or Annotation Scale (MS). AutoCAD annotative dimensions are preferred, but are not compatible with

Microstation. Dimensions shall reside on one or more dedicated Layers


IAN 184/14 of 41 Sept 14

3.4.6. Linework The following guidelines shall be adopted:

For interoperability use standard Line Types and Styles provided by the CAD application software where possible. Refer to tables below.

Where these are not suitable, additional custom line types may be defined Element line type designation shall be determined at project outset and used

consistently across a project. In general, Line Types shall be defined by Layer

AutoCAD Line Types Microstation Line Styles

ACADISO.lin lstyle.rsc Line Type Line Style Description

Continuous 0 Continuous Dot Dot2 1 Dot

Hidden Hidden2 2 Medium dash Dashed Dashed2 3 Long dash Dashdot Dashdot2 4 Dot, dash Divide Divide2 5 Short dash Center Center2 6 Dash, dot, dot Border Border2 7 Long dash, short

dash Phantom Phantom2

AutoCAD Line Type Settings LTSCALE PSLTSCALE Element 1 Model Space Finished drawing scale

e.g. 500 n/a

Paper Space 1 1

Microstation Custom Line Style Settings Global Line Style Scale

Finished drawing scale e.g. 500

Reference: Global Line Style Scale

Master

References: Scale Line Styles by Reference Scale

On

3.4.7. Line Weights and Colours To enable interoperability and obtain consistent printed output

Permitted plotted line widths are: 0.05mm; 0.13mm; 0.18mm; 0.25mm; 0.35mm 0.5mm; 0.7mm; 1.0mm; 1.4mm; 2.0mm.

Pen widths shall be set by object line weight, not by pen table Setting line weights by layer is preferred to by element Colours 0 to 9 inclusive shall plot as black lines. Other colours shall plot in

monochrome or their drawn colour according to the chosen plot settings.


IAN 184/14 of 41 Sept 14

3.4.8. Hatching and Toning Hatching and shading shall be kept to the minimum necessary to define areas clearly. In order to keep CAD file sizes down to a minimum, it is acceptable and preferred to show only patches of the material hatch pattern sufficient to clearly show the intent of the hatching. Guidance for hatching is as follows:

Default patterns should be used where possible. Custom hatch patterns

maybe used where necessary Hatching shall be consistent across a project for the same element

designation. Hatching/patterning shall be created using the relevant tools available within

the software. Care shall be taken to ensure that the draw order and transparency settings

of filled regions do not cover required graphical information. All hatching shall be Associative and Annotative. All hatching shall reside on dedicated layers to allow easy control of visibility. All hatching shall reside in model space /design view. Each hatched area shall be defined as a single hatched entity and not

grouped with other hatched areas. For large regions of hatching and zoning, creation of a separate model

drawing shall be considered. This will aid drawing update order and speed of display (e.g. landscaping, zoning and staging drawings).

3.4.9. Drawing Scales Scales used on drawings shall be selected from the following table:

The number of scales used on a drawing shall be kept to a minimum. The scale box contained within the standard title block shall be populated to

show the scales of drawn elements. Plans, details, sections and elevations shall clearly indicate the scale to which

they are drawn. On multi-disciplinary projects, wherever practical the adopted scale should be

the same for similar areas covered across all disciplines. Where a scale is not relevant to the drawing sheet the following may be used:

Permitted drawing scales 1:1 1:10 1:100 1:1000 1:10000

1:125 1:1250 1:2 1:20 1:200 1:2000 1:20000

1:25 1:250 1:2500 1:5 1:50 1:500 1:5000 1:50000

Scale Text Usage As Shown Multiple scale drawings (Show scale with the detail title),

Non-standard scales, NTS Not to Scale. Schematic views etc. N/A Not Applicable. Standard notes drawing, schedules etc.


IAN 184/14 of 41 Sept 14

3.4.10. Revision Clouding

The technique of clouding shall be used to highlight changes to a drawing between drawing issues.

AS-BUILT drawings shall contain no clouding.

3.4.11. Ordnance Survey (OS) Data OS data products are used in drawings for contextual mapping. Products come in a variety of scales from OS MasterMap (1:1250-10,000) to OS MiniScale (1:1,000,000). OS data includes products which can be purchased and free (OpenData) datasets. There are two supply models for purchased data: the traditional method and the Multi-Client Contractor Licence. These supply models are described in Appendix 1. When using OS purchased data the following licence statements shall be placed within the printed area of any drawings produced. To be placed on any prints larger than A4:

“This map is reproduced from Ordnance Survey material with the permission of Ordnance Survey on behalf of the Controller of Her Majesty’s Stationery Office © Crown copyright. Unauthorised reproduction infringes Crown copyright and may lead to prosecution or civil proceedings. AL XXXXXXXXX (year published)."

To be placed on prints of A4 or smaller or static images on the Internet or media labels:

“© Crown copyright. All rights reserved. AL XXXXXXXXX (year published).” When using OpenData the following licence acknowledgement shall be used.

“Contains Ordnance Survey data © Crown copyright and database right (year published)."


IAN 184/14 of 41 Sept 14

4. Survey Data 4.1. Topographic Survey

A topographic survey is the production of an accurate map of specified features within a specific area.

Topographic survey shall be delivered as 3D CAD model files in accordance

with the requirements of Sections 3.1 to 3.6 Unless otherwise specified, symbols and annotation in topographic survey

drawings shall be suitable for presentation at 1:500 scale. Where the objects surveyed extend up or down from ground level, separate

layers shall be provided for the ground level lines and the other vertical extent. For example, the tops of walls, fences, ditches shall be in separate layers from their bases.

Features at ground level shall not cross except at a common point. Features at ground level shall not be continuous across bridge decks. They

shall stop and restart at the ends of the deck. Features that represent closed boundaries shall be geometrically closed. Property information relating to point assets (spot levels, references etc)

shall be provided as linked attributes, not as unrelated text. Within AutoCAD the association shall be achieved through attributed blocks and within Microstation through tags.

4.2. Geotechnical Survey

Survey data for boreholes and trial pits shall be presented in AGS (Association of Geotechnical and Geoenvironmental Specialists) format in accordance with HD22/08.

File format shall be AGS version 3.1 or later (within the limitations of

section 1.3) A strategy for unique borehole numbering shall be implemented and

maintained, in accordance with BS8574.

4.3. LIDAR Point Cloud Survey File format shall be one of the following open standards

o LAS version 1.1 or later (within the limitations of section 1.3) o ASTM E57

The data shall have been processed to remove background noise,

atmospheric interference and sensor-related artefacts The metadata shall include capture method

4.4. Orthorectified Aerial Survey Aerial survey photographs shall be georeferenced to OSGB36 They shall be orthorectified to a representative digital terrain model that has

levels based on OS Datum Newlyn The delivery format shall be one of the following

o .ecw o .jpeg 2000 o .jpeg


IAN 184/14 of 41 Sept 14

4.5. Underground Asset Survey Underground asset data shall be delivered in accordance with PAS 128, Specification for underground utility detection, verification and location.

4.6. Overhead Power Cable Survey

Overhead Line Clearances shall be checked in accordance with the Technical Specification 43-8 from the Energy Networks Association. For all cable routes across or within 40m of existing or proposed roads that are affected by HA projects, the following information shall be gathered:

The line voltage For the lowest layer of conductors, the coordinates of the attachment points of

the cables to the insulators Where these are high voltage transmission lines, the coordinates of the

attachment points of the insulators to the arms of the pylon The “design sag” diagram for all relevant spans of the power line from the

infrastructure owner, giving the worst case to be considered.

The plan length of the “design sag” line shall be scaled to fit the surveyed distance between the attachment points for each cable. Where there is the possibility that

lighting columns, masts, gantries etc may be located within 40m in plan of a

cable, changes to the width and type of the road may change the required clearance

to the road surface

the safety clearance surfaces for swaying and vertical configurations of each cable shall be modelled in 3D.


IAN 184/14 of 41 Sept 14

5. Geometric modelling data 5.1. Alignment

Horizontal and vertical alignments shall be delivered in one of the following formats LandXML 1.2 [ideally using the restricted schema of the Model View

Definition – but no software validated against it yet. This is a stopgap until the shared-concept BuildingSmart IfcAlignment & OGC GML Alignment are available and supported by commercial software]

MX Genio text files. Alignments as 12-dimensional Geometry strings, and using default 23D17 number format to preserve accuracy

5.2. Terrain

Triangulated surfaces may be delivered in the following formats

LandXML 1.2 (ideally using the restricted schema of the Model View Definition)

MX Genio text files OGC GML 3.3 or higher (within the limitations of section 1.3)


IAN 184/14 of 41 Sept 14

6. Asset coding

Until instructed differently, the provisions of IAN 182/14 “Major Schemes: Enabling Handover into Operation and Maintenance” remain in force However, BS1192-4 “UK Implementation of COBie” is likely to be the eventual mechanism for transfer of asset data between project phases.


IAN 184/14 of 41 Sept 14

7. Contacts Questions on this IAN should be submitted to the Standards Feedback and Enquiries email box:

Standards_Feedback&[email protected]

Or Alex Bywaters

Email [email protected]


IAN 184/14 of 41 Sept 14

8. Normative References

BS1192:2007: Collaborative production of architectural, engineering and construction information – Code of practice BS8574: Code of practice for the management of geotechnical data for ground engineering projects PAS1192-2:2013: Specification for information management for the capital/delivery phase of construction projects using building information modelling PAS128, Specification for underground utility detection, verification and location. HD 22/08: Managing Geotechnical Risk IAN 99/07: Implementation of Local Grid Referencing System for England IAN 182/14: <ajor Schemes: Enabling Handover into Operation and Maintenance Uniclass2: Construction Project Information Committee (CPIC) classification http://www.cpic.org.uk/uniclass/ AD4 Generic Attributes: Infrastructure Asset Data Dictionary for the UK http://www.bimtaskgroup.org/wp-content/uploads/2014/02/IADD4UK-AD4-generic-attributes-V2-0.pdf ENA-TS-43-8 Issue 3, 2004 with Amendment 1, 2004 Overhead Line Clearances Energy Networks Association www.energynetworks.org

Appendix A Interim Advice Note 184/14 Ordnance Survey Data Supply Models Highways Agency Data & CAD Standard

IAN 184/14 of 41 Sept 14

Appendix A: Ordnance Survey Data Supply Models Multi-Client Contractor Licence (MCCL) The HA can supply contractors working on their behalf with copies of OS data they hold. This is permitted under the terms of the Public Sector Mapping Agreement (PSMA). Contractors only have the right to hold and use data for the duration of the specific contract they have been employed by the HA to deliver. The HA has traditionally supplied contractors with OS Data separately. The contractor then has managed each set of data separately and used it solely to deliver the contract for which it was supplied. This can be very inefficient for the contractor, especially where the company is managing a number of contracts over a number of different divisions or different offices, each with separate holdings and versions of OS data. It is difficult and expensive to maintain an integrated approach to data management in such circumstances. The MCCL provides another option. For qualifying contractors the OS provides direct data supply and maintenance. It removes the requirement for separate management of multiple data supplies of differing currency from different licensees. Once qualifying contractors hold OS data as part of the MCCL then all that is required is for a signed agreement to be in place between the HA and the contractor. This agreement is available from the OS website and is called a Schedule 3 Permitted Subcontractor Licence. The signed agreement needs to be completed for each project. Traditional Method For those not using the MCCL then the HA will need to supply OS data and sign the Schedule 3 Permitted Subcontractor Licence with the contractor. The licence statements to be used on the drawings are the same as for the MCCL method. OS OpenData Ordnance Survey makes a number of datasets available free of charge under the terms of an OS OpenData Licence. These datasets which include raster and vector mapping, height and gazetteer products are available from the OS OpenData area to download (http://www.ordnancesurvey.co.uk/business-and-government/products/opendata-products.html). The OS OpenData licence allows you to copy, distribute the data, adapt the data and exploit the data commercially. Who to contact about OS data in the HA Within the HA, Will Willcocks can assist with the supply of OS data

[email protected] 0123 4796226

Appendix B Interim Advice Note 184/14 Project Information Search Table Highways Agency Data & CAD Standard

IAN 184/14 of 41 Sept 14

Appendix B: Project Information Search Table The HA will make available via the HA Supply Chain Portal the following searchable information about each project: PIN The HA 6-digit Project Information Number Title The official title of the project Route(s) The road number(s) of the principal routes, separated by spaces if

necessary Start Date Date of first Task Order End Date Blank until completion Local Grid The IAN 99/07 Zone and Height band Designer Designer(s) associated with this PIN, separated by spaces if necessary Contractor Contractor(s) associated with this PIN, separated by spaces if necessary

This information is to give context to files that are named in accordance with this IAN, and to enable searches for adjacent or previous project data that may be relevant to current projects.

Appendix C Interim Advice Note 184/14 Example CAD Layer Names Highways Agency Data & CAD Standard

IAN 184/14 of 41 Sept 14

Appendix C: Example CAD Layer Names The following list shows the form that layer names should take to meet the requirements of Section 3.3. The list is not exhaustive but gives reasonable coverage of highways and associated structures.

Usage is mostly shown as Dn (Design). Layers for other usages should be made as necessary

The descriptions have been kept short and are in CamelCase, with words in decreasing order of significance

Where there is not yet an available code in Uniclass2, a temporary code has been created starting “Ha_”. When Uniclass2 has been extended, temporary layer names will need to be changed to the final version.

ROADS GENERAL D-Zz_35_10_40-M-Dn_AlignHoriz D-En_81_10_19-M-Dn_PaveEdge

D-Zz_35_10_90-M-Dn_AlignVert D-Zz_85_05_60-M-Dn_SweptPath

D-Zz_35_10_80-M-Dn_SuperElev

BOUNDARIES D-Zz_50_10_10-M-Cd_BdryExist D-Zz_50_60-M_BdryLandParcel

D-Zz_50_10_70-M-Dn_BdryProposed D-Zz_50_95-M-Dn_ZoneEnvir

PAVEMENTS D-Ss_30_14_40 HWAY-M-Dn_Pavement D-Ha_01_05 CERE-M-Dn_CResGen

D-Ss_30_14_15 HWAY-M-Dn_PaveRigid D-Ss_30_14_15_16 CERE-M-Dn_CResRigid

D-Ss_30_14_05 HWAY-M-Dn_PaveFlex D-Ss_30_14_05_35 CERE-M-Dn_CResFlex

D-Ss_30_14_35-M-Dn_PaveUnbound D-Ss_30_14_35_33-M-Dn_CResUnbound

D-Sp_81_10_46 LABY-M-Dn_PaveLayBy D-Ha_01_06 XOVE-M-Dn_CResCrossover

VERGES D-Sp_81_10_80-M-Dn_VergeGen D-Ha_02_03-M-Dn_VergeUnbound

D-Ha_02_01 HDST-M-Dn_VergeRigid D-Sp_40_20_59 RSTA-M-Dn_RestArea

D-Ha_02_02 HDST-M-Dn_VergeFlex

NMU PATHS D-En_81_70_19 FOOT-M-Dn_PathGen D-Pr_25_93_60_23 FOOT-M-Dn_PathTactile

D-Ha_02_04 FOOT-M-Dn_PathRigid S-Sp_81_10_20 BIKE-M-Dn_PathBikeLane

D-Ss_30_14_05_50 FOOT-M-Dn_PathFlex S-Sp_40_83_39 BRDW-M-Dn_PathBridleway

D-Ha_02_05 FOOT-M-Dn_PathUnbound

ROAD ISLANDS AND KERBS D-Sp_81_10_64 CEIS-M-Dn_IslandGen D-Pr_25_93_60_18 KERB-M-Dn_KerbPrecast

D-Ha_02_06 CEIS-M-Dn_IslandRigid D-Ss_30_75_45_45 KERB-M-Dn_KerbExtruded

D-Ha_02_07 CEIS-M-Dn_IslandFlex D-Pr_25_93_60_21 KERB-M-Dn_KerbSafety

D-Ha_02_08 CEIS-M-Dn_IslandUnbound D-Pr_25_93_60_15-M-Dn_KerbEdging

D-Ha_02_09 CEIS-M-Dn_IslandBlocks D-Ss_20_05_15_91-M-Dn_KerbBedding

D-Ss_30_75_45 KERB-M-Dn_KerbGen

EARTHWORKS D-Ss_15_10_75-M-Dn_EwksSiteClearance D-Pr_15_31_26_26-M-Dn_EwksFillSoil

D-Zz_40_20-M-Dn_EwksTadpoles D-Pr_15_31_26-M-Dn_EwksFillBulk

D-En_81_10_14-M-Dn_EwksCutGen D-Pr_15_31_26_13-M-Dn_EwksFillChalk

D-Ha_03_01-M-Dn_EwksCutSoil D-Pr_15_31_26_14-M-Dn_EwksFillClay

D-Ha_03_02-M-Dn_EwksCutSuitable D-Pr_15_31_26_33-M-Dn_EwksFillGran

D-Ha_03_03-M-Dn_EwksCutUS D-Pr_15_31_26_46-M-Dn_EwksFillLScape

D-Ss_15_10_26-M-Dn_EwksFillGen D-Zz_60_45_60-M_EwksOriginal


IAN 184/14 of 41 Sept 14

ROAD MARKINGS D-Pr_35_31_85_90-M-Dn_RdMkGen D-Ha_04_07 ROST-M-Dn_RdMkStud_Clr Red

D-Ha_04_01 LORM-M-Dn_RdMkLinear D-Ha_04_08 ROST-M-Dn_RdMkStud_Clr Green

D-Ha_04_02 HARM-M-Dn_RdMkHatch D-Ha_04_09 ROST-M-Dn_RdMkStud_Clr Yellow

D-Ha_04_03 TRRM-M-Dn_RdMkSym D-Ha_04_10 ROST-M-Dn_RdMkStudLit

D-Ha_04_04 TRRM-M-Dn_RdMkChar D-Ha_04_11 ROST-M-Dn_RdMkStudLit_Clr White

D-Ha_04_05 TRRM-M-Dn_RdMkTrans D-Ha_04_12 ROST-M-Dn_RdMkStudLit_Clr Red

D-Pr_35_90_60_71 ROST-M-Dn_RdMkStud D-Ha_04_13 ROST-M-Dn_RdMkStudLit_Clr Green

D-Ha_04_06 ROST-M-Dn_RdMkStud_Clr White D-Ha_04_14 ROST-M-Dn_RdMkStudLit_Clr Yellow

SIGNS D-Ss_40_10_25_30-M-Dn_SignGen D-Ha_05_04-M-Dn_SignFoundGen

D-Pr_40_10_77_72 SGFA-M-Dn_SignFace D-Ss_20_05_50_90-M-Dn_SignFoundConc

D-Ha_05_01 SGFA-M-Dn_SignFace_Mount Gantry D-Ha_05_05-M-Dn_SignFoundPiled

D-Ha_05_02 SGFA-M-Dn_SignFace_Mount Post D-Ha_05_06-M-Dn_SignLighting

D-Ha_05_03-M-Dn_SignSuppGen D-Ha_05_07-M-Dn_SignSundries

D-Pr_20_76_64 SGPO-M-Dn_SignSuppPostGen D-Ha_05_08 RFMP-M-Dn_SignMarkerPost

D-Pr_20_76_64_14 SGPO-M-Dn_SugnSuppPostSteel

D-Ss_25_36_90_10 SABO-M-Dn_SignBollard

D-Pr_20_76_64_04 SGPO-M-Dn_SignSuppPostPassive

D-Pr_80_77_47_63 SABO-M-Dn_SignBollardLit

DRAINAGE D-Ss_50_30_08_85-M-Dn_DrainageGen D-Ss_50_30_06_18 DRCP-M-Dn_DrainageCatchpit

D-Pr_65_52_20 DRCU-M-Dn_DrainageCulvert D-Pr_65_54_95_33 DROC-M-Dn_DrainageValve

D-Ha_06_01 DRLI-M-Dn_DrainageCarrier D-Pr_65_52_01_95 DROC-M-Dn_DrainageVortex

D-Ss_50_30_45_30-M-Dn_DrainageFilterGen D-Pr_65_52_01_58 DROC-M-Dn_DrainageOrifice

D-Ha_06_02 DRLI-M-Dn_DrainageFilterPipe D-Ss_50_70_05_83 DRIN-M-Dn_DrainageInterceptor

D-Ha_06_03 DRFD-M-Dn_DrainageFilterMaterial D-Ss_50_70_05_85-M-Dn_DrainageStorageTank

D-Ha_06_04-M-Dn_DrainageFilterMembrane D-Pr_65_52_24_34 DROL-M-Dn_DrainageHeadwall

D-Ha_06_05 DRCS-M-Dn_DrainageSlotGen D-Pr_65_52_01_01 DRRI-M-Dn_DrainageRoddingEye

D-Ss_30_75_45_50 DRCS-M-Dn_DrainageSlotPrecast

D-Pr_65_52_24 DRGU-M-Dn_DrainageGully

D-Ss_30_75_45_75 DRCS-M-Dn_DrainageSlotSlipform

D-Ss_50_70_05_84 DROS-M-Dn_DrainageSeparator

D-Ha_06_06 CHAN-M-Dn_DrainageChanGen D-Ss_50_70_05_79 DRSK-M-Dn_DrainageSoakaway

D-Ss_30_75_45_50 CHAN-M-Dn_DrainageChanPrecast

D-Ss_50_70_05_95 DROF-M-Dn_DrainageOutfallGen

D-Ss_30_75_45_75 CHAN-M-Dn_DrainageChanSlipform

D-Ha_06_10-M-Dn_DrainageOufallHeadwall

D-Ha_06_07 DRDI-M-Dn_DrainageDitchGen D-Ss_50_70_05_79 DRSO-M-Dn_DrainageOutfallSoakaway

D-Pr_25_93_60_12 DRCK-M-Dn_DrainageKerb D-Ha_06_10-M-Dn_DrainageFittingGen

D-Ha_06_08-M-Dn_DrainageStoragePipe D-Pr_65_52_01_02-M-Dn_DrainageFittingCover

D-Ha_06_09-M-Dn_DrainageBedding D-Pr_65_52_01_03-M-Dn_DrainageFittingGrating

D-Ss_50_30_06 DRIC-M-Dn_DrainageChamberGen

D-Ss_50_70_95-M-Dn_DrainagePond

D-Ss_50_30_06_14 DRMH-M-Dn_DrainageManhole

D-Ss_50_70_85_85 DRSC-M-Dn_DrainageSUDS


IAN 184/14 of 41 Sept 14

VEHICLE RESTRAINT SYSTEMS D-Ss_25_36_90 VRS-M-Dn_VrsGen D-Pr_20_85_07 VRS-M-Dn_VrsMetalRail

D-Zz_85_05_60 VRS-M-Dn_VrsSpine D-Pr_20_76_64 VRS-M-Dn_VrsMetalPost

D-Zz_85_05_85 VRS-M-Dn_VrsWorkingWidth D-Ss_25_36_90_14 VRS-M-Dn_VrsMetalGroundBeam

D-Ss_25_36_90_16 VRS-M-Dn_VrsCsbGen S-Pr_20_85_07_11 MCPR-M-Dn_VrsBikeProt

D-Pr_25_71_57_18 VRS-M-Dn_VrsCsbPrecast D-Pr_20_85_70_16-M-Dn_VrsMetalTransition

D-Ha_07_01 VRS-M-Dn_VrsCsbSlipform D-Ha_07_04 EDTM-M-Dn_VrsMetalAnchor

D-Ss_25_36_90_97 VRS-M-Dn_VrsWireGen D-Ha_07_05 CRCU-M-Dn_VrsCrashCushion

D-Ha_07_02 VRS-M-Dn_VrsWireRope D-Ss_25_36_95_96 ARBE-M-Dn_VrsArresterBed

D-Ha_07_03 VRS-M-Dn_VrsWirePost S-Ss_25_15_30 PEGR-M-Dn_VrsPedBarrier

D-Ss_25_36_90_50 VRS-M-Dn_VrsMetalGen

LIGHTING D-Ee_70_30-M-Dn_LightingGen D-Pr_70_70_49 LIPO-M-Dn_LightingLuminaire

D-Pr_65_52_01_01-M-Dn_LightingChamber D-Pr_20_85_09_15-M-Dn_LightingBracket

D-Pr_65_70_11_93-M-Dn_LightingDuctGen D-Pr_80_77_48-M-Dn_LightingColumn

D-Ha_08_01-M-Dn_LightingDuctLong D-Ee_80_30_85 FEPI-M-Dn_LightingPowerSupply

D-Ha_08_02-M-Dn_LightingDuctTrans D-Pr_65_70_48-M-Dn_LightingCable

D-Ee_70_30_80 LIPO-M-Dn_LighingPointGen

TECHNOLOGY TE-Pr_65_52_01_01-M-Dn_TechChamber TE-Ha_09_04-M-Dn_TechSignalSupport

TE-Sp_75_30_88-M-Dn_TechSiteGen TE-Ha_09_05-M-Dn_TechSignalFound

TE-Pr_20_85_13_63-M-Dn_TechSitePlinth TE-Pr_70_75_90_73 NMUX-M-Dn_TechCrossingNMU

TE-Ss_30_14_90-M-Dn_TechSitePave TE-Pr_70_75_90_62 PEDX-M-Dn_TechCrossingPed

TE-Ss_25_15_05_35 HNDR-M-Dn_TechSiteHandRail

TE-Ha_09_06 DELO-M-Dn_TechLoop

TE-Ss_35_10_25-M-Dn_TechSiteSteps TE-Pr_70_75_88 EMTB-M-Dn_TechPhone

TE-Pr_65_70_11_93-M-Dn_TechDuctGen TE-Pr_60_75_86-M-Dn_TechCctvGen

TE-Ha_09_01-M-Dn_TechDuctLong TE-Pr_60_75_75_86_86-M-Dn_TechCctvCamera

TE-Ha_09_02-M-Dn_TechDuctTrans TE-Pr_60_75_75_86_85-M-Dn_TechCctvSpeed

TE-Ha_09_03-M-Dn_TechCableBridge TE-Pr_80_77_27_85 CCTV-M-Dn_TechCctvMast

TE-Sp_65_90_85 SWRM-M-Dn_TechSwitchroom TE-Pr_75_30_59_94-M-Dn_TechTollGen

TE-Ee_75_30_85 DIPO-M-Dn_TechPowerSupply TE-Ss_75_60_50-M-Dn_TechSensorFog

TE-Pr_80_77_28_98 COCB-M-Dn_TechCabinet TE-Pr_80_51_51_05-M-Dn_TechSensorWind

TE-Zz_85_05_85-M-Dn_TechWorkingSpace TE-Pr_75_50_53_70-M-Dn_TechSensorRadar

TE-Ss_75_30_35-M-Dn_TechSignalGen TE-Ss_75_10_94-M-Dn_TechCableGen

TE-Pr_70_75_90_53-M-Dn_TechSignalLane TE-Pr_65_70_48-M-Dn_TechCablePower

TE-Pr_70_75_90 TRSI-M-Dn_TechSignalTrafficLight

TE-Pr_65_70_15_58-M-Dn_TechCableFibre

TE-Pr_75_30_59_94-M-Dn_TechSignalRamp TE-Pr_65_70_15-M-Dn_TechCableComms

FENCES AND GATES D-Ee_25_40 FEBW-M-Dn_FenceGen S-Pr_25_96_35_03 CATL-M-Dn_FenceCattleGrid_Mat

Aluminium D-Ss_25_14_65 FEBW-M-Dn_FencePostRail S-Pr_25_96_35_11 CATL-M-Dn_FenceCattleGrid_Mat

Steel D-Ha_10_01 FEBW-M-Dn_FenceGen S-Pr_25_96_35_71 CATL-M-Dn_FenceCattleGrid_Mat

Plastic D-Ss_25_14_67_95 FEBW-M-Dn_FenceMesh S-Ss_25_32_50 CWGA-M-Dn_FenceGateCWay

D-Ss_25_14_63 FEBW-M-Dn_FencePanelled S-Ss_25_32_35 FEGA-M-Dn_FenceGate

D-Ss_25_14_67 FEBW-M-Dn_FencePostWire S-Ss_25_32_50 SNGA-M-Dn_FenceGateSnow

D-Ss_25_25_05 FEBW-M-Dn_FenceAcoustic S-Ss_25_32_35_85 STIL-M-Dn_FenceStile

S-Pr_25_96_35 CATL-M-Dn_FenceCattleGrid S-Sp_65_10_93 STPS-M-Dn_FenceSteps


IAN 184/14 of 41 Sept 14

RETAINING WALLS D-Ss_15_10_28 REWA-M-Dn_RetwallEmbedGen D-Ss_25_13_30 REWA-M-Dn_RetwallGabion

D-Ss_15_10_32 REWA-M-Dn_RetwallGravityGen D-Ss_15_10_32_75 REWA-M-Dn_RetwallReinforcedEarth

D-Ha_11_01 REWA-M-Dn_RetwallSlipform D-Ha_11_02 REWA-M-Dn_RetwallCappingConcrete

D-Ss_15_10_32_70 REWA-M-Dn_RetwallInsitu D-Ha_11_03 REWA-M-Dn_RetwallCappingSteel

D-Ss_15_10_28_85 REWA-M-Dn_RetwallSheetPile

D-Pr_15_57_33-M-Dn_GeotechTextile

D-Ss_15_10_28_15 REWA-M-Dn_RetwallBoredPile

D-Ss_15_10_80-M-Dn_GeotechSoilNail

D-Ss_15_10_32_50 REWA-M-Dn_RetwallMasonry D-Pr_20_29_03_33-M-Dn_GeotechGroundAnchor

GEOTECHNICAL D-Ss_15_50_75_34-M-Dn_GeotechBorehole D-Ss_15_50_75-M-Dn_GeotechSurvey

D-Ha_12_01-M-Dn_GeotechTrialPit

ENVIRONMENT EN-Ss_45_70_05_85-M-Dn_EnvironSpeciesGen EN-Pr_75_75_76_02-M-Dn_EnvironAirQualitySurvey

EN-Ss_15_50_30-M-Dn_EnvironSurvey EN-Ha_14_08-M-Dn_EnvironTypeGen

EN-Ss_45_35_08_38-M-Dn_EnvironHabitatProtection

EN-Ha_14_09-M-Dn_EnvironTypeBuild

EN-Ss_45_35_08_85-M-Dn_EnvironSpeciesBarrier EN-En_30_20_11-M-Dn_EnvironTypeForest

EN-Ss_45_35_08_37-M-Dn_EnvironSpeciesProvision

EN-Sp_30_20-M-Dn_EnvironTypeAgric

EN-Ha_14_01-M-Dn_EnvironVisualGen EN-Ha_14_10-M-Dn_EnvironLscapeGen

EN-Ha_14_02-M-Dn_EnvironVisualSurvey EN-Ss_45_35_30-M-Dn_EnvironLscapePlant

EN-Ha_14_03-M-Dn_EnvironVisualBarrier EN-Ss_45_35_30 TREE-M-Dn_EnvironTree

EN-Ha_14_04-M-Dn_EnvironNoiseGen EN-Ss_45_35_30 HEDG-M-Dn_EnvironHedge

EN-Ha_14_05-M-Dn_EnvironNoiseSurvey EN-Ha_14_11-M-Dn_EnvironLscapeHard

EN-Ha_14_06-M-Dn_EnvironNoiseBarrier EN-Ha_14_12-M-Dn_EnvironArchGen

EN-Ha_14_07-M-Dn_EnvironAirQualityGen

UTILITIES D-Ee_55_10-Op_UtilPipedGen D-Ee_75_10_10-Op_UtilTelcoOverhead

D-Ss_55_70_95_50-Op_UtilWater D-Pr_65_54_95_34-Op_UtilWaterValve

D-Ss_50_30_08_30-Op_UtilFoulGravity D-Ss_35_13_50-Op_UtilFoulChamber

D-Ss_50_30_85-Op_UtilFoulPumped D-Pr_65_54_95_34-Op_UtilGasValve

D-En_55_90_58-Op_UtilGas D-Pr_65_54_95_34-Op_UtilOilValve

D-En_55_90_18-Op_UtilOil D-Pr_20_76_88_77-Op_UtilElecLvSupport

D-Ss_70_30_35_35-Op_UtilElecHvBuried D-Pr_75_72_37-Op_UtilElecLvTransformer

D-Ss_70_30_40_40-Op_UtilElecHvOverhead D-Ss_35_17_45-Op_UtilElecHvPylon

D-Ss_70_30_45_45-Op_UtilElecLvBuried D-Zz_85_05_85-Op_UtilSafetyOverhead

D-Ss_70_30_45_40-Op_UtilElecLvOverhead D-Zz_85_05_85-Op_UtilSafetyBuried

D-Ee_75_10_10-Op_UtilTelcoBuried

MAINTENANCE D-Sp_30_90_50 DEPO-M-Dn_MaintDepot D-Ha_13_01 SOFT-M-Dn_MaintSoftEstate

D-Ss_15_30_22 SPKT-M-Dn_MaintSpillKit

TRAFFIC MANAGEMENT D-Ss_25_95_85-M-Ty_TmBarrier D-Pr_25_30_86-M-Ty_TmCones


IAN 184/14 of 41 Sept 14

STRUCTURES

FOUNDATIONS S-Ss_15_10_28-M-Dn_FoundPileGen S-Ha_20_06-M-Dn_FoundPilesLateralLoad

S-Ha_20_01-M-Dn_FoundPileGen S-Ha_20_07-M-Dn_FoundPilesInfill

S-Ha_20_02-M-Dn_FoundPilesEndBearing S-Ha_20_08-M-Dn_FoundStrip

S-Ha_20_03-M-Dn_FoundPilesFriction S-Ss_20_05_15_72-M-Dn_FoundRaft

S-Ha_20_04-M-Dn_FoundPilesSettlementReducing S-Ss_20_05_15_70-M-Dn_FoundPad

S-Ha_20_05-M-Dn_FoundPilesTension S-Ha_20_09-M-Dn_FoundCaisson

PILES S-Ss_20_05_15_71-M-Dn_StructPileCapGen S-Ha_21_02-M-Dn_StructPileCapPrecast

S-Ha_21_01-M-Dn_StructPileCapInsitu

ABUTMENTS AND PIERS S-Ee_30_70_10-M-Dn_StructAbutGen S-Ha_21_09-M-Dn_StructAbutWingCoping

S-Ha_21_03-M-Dn_StructAbutBankSeat S-Ss_25_15_05_35-M-Dn_StructAbutWingParapet

S-Ha_21_04-M-Dn_StructAbutGroundBeam S-Ee_30_70_10-M-Dn_StructPierGen

S-Ha_21_05-M-Dn_StructAbutWall S-Pr_20_85_15_15-M-Dn_StructPierConcInsitu

S-Ha_21_06-M-Dn_StructAbutCurtain S-Ha_21_10-M-Dn_StructPierContPrecast

S-Ha_21_07-M-Dn_StructAbutMask S-Ha_21_11-M-Dn_StructPierSteel

S-Ha_21_08-M-Dn_StructAbutWing

DECKS S-Ee_30_70-M-Dn_StructDeckGen S-Ha_21_15-M-Dn_StructDeckSteelGen

S-Ha_21_12-M-Dn_StructDeckConcGen S-Pr_20_76_51_12-M-Dn_StructDeckSteelRolled

S-Pr_20_85_08_15-M-Dn_StructDeckConcInsitu S-Pr_25_71_51_15-M-Dn_StructDeckSteelPlateGirder

S-Ha_21_13-M-Dn_StructDeckConcVoided S-Pr_25_71_51_15-M-Dn_StructDeckSteelBoxGirder

S-Pr_25_71_29_37-M-Dn_StructDeckConcVoidForm

S-Pr_25_71_51_15-M-Dn_StructDeckSteelDiaphragm

S-Ha_21_14-M-Dn_StructDeckConcSegment S-Pr_25_71_51_15-M-Dn_StructDeckSteelStiffener

S-Ha_21_16-M-Dn_StructDeckConcDiaphragm S-Pr_20_76_03_11-M-Dn_StructDeckSteelBracing

S-Pr_20_96_71_14-M-Dn_StructDeckConcRebar S-Ss_25_36_90_14-M-Dn_StructDeckParapetGen

S-Pr_20_96_71_97-M-Dn_StructDeckConcMesh S-Pr_20_29_03_05-M-Dn_StructDeckParapetAnchor

S-Pr_20_85_08_66-M-Dn_StructDeckConcPrecast

PARAPETS S-Pr_20_76_64-M-Dn_StructDeckParapetPost S-Pr_25_71_50_16-M-Dn_StructDeckParapetMesh

S-Pr_20_85_07-M-Dn_StructDeckParapetRail S-Pr_25_71_50-M-Dn_StructDeckParapetSheet

BEARINGS S-Pr_20_29_06-M-Dn_StructDeckBearingGen S-Ha_21_18-M-Dn_StructDeckBearingRoller

S-Ha_21_17-M-Dn_StructDeckBearingFixed S-Pr_20_29_06_29-M-Dn_StructDeckBearingElastomeric

S-Pr_20_29_06_62-M-Dn_StructDeckBearingSlide

WATERPROOFING S-Pr_35_31_68-M-Dn_StructWaterproofingGen S-Ha_21_20-M-Dn_StructWaterproofingMembrane

S-Ha_21_19-M-Dn_StructWaterproofingBoard S-Ha_21_21-M-Dn_StructWaterproofingCoating

STRUCTURAL CONNECTIONS S-Ha_21_22-M-Dn_StructConnGen S-Pr_20_29_31_08-M-Dn_StructConnBolted

S-Pr_20_29_97-M-Dn_StructConnWeld S-Pr_20_96_71_51-M-Dn_StructConnRebarCoupler

STRUCTURE PRESTRESSING S-Ha_21_23-M-Dn_StructPrestressingGen S-Pr_20_29_03_97-M-Dn_StructPrestressingAnchor

S-Pr_20_29_29_66-M-Dn_StructPrestressingDuct S-Zz_85_05_85-M-Dn_StructPrestressingClearance

S-Pr_20_96_71_15-M-Dn_StructPrestressingTendon


IAN 184/14 of 41 Sept 14

SUSPENSION S-Ha_21_24-M-Dn_StructSuspensionGen S-Pr_20_29_03_86-M-Dn_StructCatenaryHangerAnchor

S-Ha_21_25-M-Dn_StructCatenaryGen S-Ha_21_28-M-Dn_StructCatenaryHangerBar

S-Ss_20_16_07-M-Dn_StructCatenaryCable S-Ss_20_16_05-M-Dn_StructStayGen

S-Pr_20_29_03_86-M-Dn_StructCatenaryAnchor S-Ha_21_29-M-Dn_StructStayCable

S-Ha_21_26-M-Dn_StructCatenaryHangerGen S-Pr_20_29_03_86-M-Dn_StructStayAnchor

S-Ha_21_27-M-Dn_StructCatenaryHangerCable

EXPANSION JOINTS S-Pr_35_90_27-M-Dn_StructExpansionGen S-Ha_21_31-M-Dn_StructExpansionDowel

S-Ha_21_30-M-Dn_StructExpansionSeal S-Ha_21_32-M-Dn_StructExpansionMechanical

GANTRIES S-Ss_35_17_35-M-Dn_GantryGen S-Pr_20_76_52_16-M-Dn_GantryBoomSteel

S-Ss_15_10_28-M-Dn_GantryPile S-Pr_20_85_08_65-M-Dn_GantryBoomConc

S-Ss_20_05_15_71-M-Dn_GantryPileCap S-Ha_22_02-M-Dn_GantrySignSupport

S-Pr_20_76_52_16-M-Dn_GantrySupportSteel S-Pr_70_75_90_53-M-Dn_GantrySignalSupport

S-Ha_22_01-M-Dn_GantrySupportConc S-Pr_80_77_12_17-M-Dn_GantryCableTray

TUNNELS S-EF_90-M-Dn_TunnelGen S-Ss_20_14_75-M-Dn_TunnelLiningSegmental

S-EF_90_10-M-Dn_TunnelBored S-Ss_35_11_10-M-Dn_TunnelBored

S-EF_90_20-M-Dn_TunnelCutCover S-Ss_35_11_20-M-Dn_TunnelCutCover

S-EF_90_40-M-Dn_TunnelImmersed S-Ss_65_40_94_91-M-Dn_TunnelVent

S-EF_90_70-M-Dn_TunnelShaft S-Ee_35_30_30-M-Dn_TunnelOpeningAccess

S-En_81_10_12-M-Dn_TunnelRoadMajor S-Ee_35_30_35-M-Dn_TunnelOpeningNonAccess

S-En_81_50_12-M-Dn_TunnelRoadMinor S-Ee_35_30_40-M-Dn_TunnelCovering

S-En_81_70_12-M-Dn_TunnelPath S-Ee_35_30_45-M-Dn_TunnelFinish

S-En_80_10_12-M-Dn_TunnelRailHeavy S-Ee_35_30_55-M-Dn_TunnelBarrier

S-En_80_50_12-M-Dn_TunnelRailLight S-Ha_23_01-M-Dn_TunnelPortal

CAD

Z-Zz_10_20-P_CadFrame Z-Zz_20_80_40-P_CadKeyplan

Z-Zz_10_20_45-P_CadLogo Z-Zz_20_80_50-P_CadLegend

Z-Zz_10_20_95-P_CadViewport Z-Zz_20_80_55-P_CadNorth

Z-Zz_10_40-P_CadHoldCloud Z-Zz_20_90-T_CadTitle

Z-Zz_10_70_20-P_CadRevCloud Z-Zz_30_40-P_CadImage

Z-Zz_10_80-P_CadStatusStamp Z-Zz_30_90-T_CadTable

Z-Zz_20_10-T_CadTextAnno Z-Zz_35-P_CadSetout Z-Zz_20_10_40-T_CadTextKeynote Z-Zz_35_20-M_CadCL

Z-Zz_20_10_45-T_CadTextLabel Z-Zz_35_40-M_CadGrid

Z-Zz_20_10_50-T_CadTextLeader Z-Zz_35_80-P_CadSurveyControl Z-Zz_20_10_55-T_CadTextNote Z-Zz_40_15-M_CadContour Z-Zz_20_20-D_CadDims Z-Zz_40_15_50-M_CadContourMajor Z-Zz_20_30_50-P_CadMask Z-Zz_40_15_55-M_CadContourMinor Z-Zz_20_30_95-P_CadWipeout Z-Zz_60_45_20-P_CadDatum

Z-Zz_20_40_05-H_CadHatchFill Z-Zz_60_50_20-P_CadCallout Z-Zz_20_40_35-H_CadHatchBdry Z-Zz_60_50_30-P_CadElev

Z-Zz_20_40_60-H_CadHatchPatt Z-Zz_60_50_80-P_CadSection

Z-Zz_20_40_80-H_CadHatchSolid Z-Zz_60_55-P_CadMatchline

Z-Zz_20_70_20-P_CadRedlineComment Z-Zz_70_05-P_CadView3D

Z-Zz_20_70_50-P_CadRedlineLines Z-Zz_90_20-P_CadInfoConstruction

Z-Zz_20_80-P_CadSymbol Z-Zz_90_30-P_CadInfoXref Z-Zz_20_80_10-P_CadScalebar Z-Zz_90_70-T_CadInfoReadme

Z-Zz_20_80_15-P_CadCrossRef

Appendix D Interim Advice Note 184/14 Explanatory Notes Highways Agency Data & CAD Standard

IAN 184/14 of 41 Sept 14

Appendix D Explanatory Notes A B C D

Level 2 BIM demands far more than uniform file naming and structure, but this is a fundamental step. The expectation is that the supply chain will adopt as minimum these aspects of BS1192 and PAS1192-2

CDE - Common Data Environment BEP – BIM Execution Plan, incorporating

o MIDI – Master Information Delivery Index D.1.1 Units The overriding requirement is that files may need to be combined into federated BIM models. Traditionally, structural drawings are dimensioned in millimetres, and highway drawings in metres. While this is most obviously achieved by adopting different units for each type of drawing, it is also simple to use metres throughout and set a dimension scale factor where millimetres are required. This approach eliminates the significant risk that clashes are missed because some components had been inadvertently modelled a thousand times too large or too small.

D.1.2 Coordinates Ideally BIM assets would be created and updated in the same coordinate system through their whole lives. This approach was considered, using National Grid throughout. However, any long structure would then need locally distorted control to make it fit during construction. The disadvantages outweigh the apparent convenience of a single system. Thus design and construction need to be in an appropriate local grid, for which guidance already exists in IAN 99/07. Operation and maintenance cover larger networks and need to remain in National Grid. The concept of IAN 99/07 ensures that local grids are readily distinguishable from National Grid, so there is little risk in using both where appropriate. However, for legacy data to be correctly overlaid with new projects, it is vital that the chosen local grid for each project is recorded and remains searchable in perpetuity. Local grids from IAN 99/07 are simply defined by zone and height band, making this the obvious information to record. Highway authorities outside England, so not covered by IAN 99/07, would need to record the local grid origin and scale factors chosen for each project.

D.1.3 File Types The IAN aims to minimise loss of information at project handover stages by limiting the number of file types that may be encountered. But it does not stifle innovation during a project phase: organisations may use any formats internally or by mutual agreement between themselves.


IAN 184/14 of 41 Sept 14

D.2 File Names Compatibility with BS1192 / PAS1192 is an essential requirement as part of the UK Government BIM Strategy. However, there is considerable scope within these standards on the detail of the implementation. BS1192 filenames are inevitably fairly long. They may be kept as short as possible by encoding some fields using a project-specific key. But it is desirable that they can be sorted into a logical order, which implies some provision for non-consecutive codes to allow insertion or deletion. The IAN aims to retain some human readability in the overall structure, so that even unfamiliar projects are reasonably comprehensible. It is fairly flexible in a few fields in order to accommodate the wide range of project types and stages. D.2.1 Project Mervyn Richards’ (author of BS1192) advice on the Project field is that it should be a recognisable mnemonic that is valid across the supply chain for the whole life of the project. Initially it was attempted to create the field from the road name, junction numbers etc. This approach was rejected because

It does not work for trunk roads that have no junction numbers; they then need

abbreviated place names The field can become unacceptably long

There is no guarantee of uniqueness over time: two projects could occur on the

same length of road. Adding a 2-digit year would make the field even longer. The HA PIN for the Project field Remains unchanged for the duration of the project Does not change in style between motorways and trunk roads, or between

different stages Is recognisable as such, provided that the digits are preceded by “HA” (otherwise

it may be confused with a supplier’s internal job number) But it is comprehensible to the supply chain only if the PINs and their descriptions

are accessible and searchable in perpetuity. D.2.2 Originator A fixed 3-character abbreviation was considered. However, the difficulty of accommodating joint ventures uniquely dictates the need for flexibility. D.2.3 Volume (and Location) The PAS1192 Volume and Location fields (previously Zone and Level in BS1192) have brought the most discussion and change. In concept they were originally two spatial subdivisions, typically which building and which floor. For the purpose of this IAN, the “site” is the whole of England. Plan subdivision would be arbitrary, and vertical subdivision would be meaningless. The most relevant subdivision of the files is by discipline. Whether in design, construction or maintenance, a discipline team can then have ownership of a set of files. Within each discipline, the location field can be used as a spatial subdivision in a manner that is relevant to that discipline.


IAN 184/14 of 41 Sept 14

Considered protocols for Volume and Location

i) Volume from the “Series numbers” from MCHW Volume 1 This well-known classification works quite well for most highway design aspects, but not well for structures or maintenance. For example, a composite bridge could be split among

1600 Piling and Embedded Retaining Walls, 1700 Structural Concrete, 1800 Structural Steelwork, 1900 Protection of Steelwork against Corrosion 2000 Waterproofing for Concrete Structures 2100 Bridge Bearings 2300 Bridge Expansion Joints and Sealing of Gaps 2500 Special Structures

Location was a further discipline subdivision followed by a position based on start chainage.

ii) Volume as a two-character code for the subdivision of the discipline

Location as purely positional information Although possible to make enough codes, they were not easy to recognise or remember.

iii) (Current proposal) Volume as a three-character subdivided discipline code, with the first character indicating the overall grouping: H for Highways, S for Structures etc. These codes are far more memorable because they have a context to start from. Location is positional, either directly or by structure number etc. There is flexibility to handle the variation in project types.

D.2.4 Location See above D.2.5 Type Where possible the standard codes from BS1192 are used. Consideration was given to changing the codes “M2” and “M3” to “2D” and “3D” respectively, to avoid confusion with the motorway names. As road names are not now used in the Project field, this confusion should not arise. The standard is therefore adopted unchanged in this matter. D.2.6 Role In the same way as above, where BS1192 has a role code it is adopted unchanged. Any new codes shall have two characters to distinguish them from the standard list.


IAN 184/14 of 41 Sept 14

D.2.7 Number No number of digits has been stipulated, but it should be consistent within a project. Small projects should not clutter already long filenames with unnecessary leading zeros. Large projects will need longer filenames. D.2.8 Suitability and Revision It is anticipated that these aspects will increasingly be handled by electronic document management systems (EDMS). Consideration was given to requiring filenames to carry Suitability and Revision fields when being transmitted. But the renaming processes before and after transmittal would have a high risk of errors


IAN 184/14 of 41 Sept 14

D.3 CAD model and drawing files D.3.1 Content The content of CAD drawings is changing rapidly in response to initiatives such as BIM. The IAN is intended to cover the range from traditional 2D drawings to data-rich 3D solid modelling. D.3.2 File Formats Consideration was given to including Navisworks nwd in the list of acceptable formats. It was rejected because its export options are very limited, so it cannot be used as a delivery platform without the source files used to create it. D.3.3 CAD Layer names In object-based modelling, one or more Classification systems would be assigned as properties of the objects. But Layer-based CAD is likely to remain predominate in highway infrastructure for some years. BS1192 puts “computer readable” information at the start, and “human readable” information at the end of fairly long layer names. CAD operators are likely to differentiate between layers only by the description. The ergonomics of the CAD screen mean that less efficient working methods when setting layers are a likely consequence. It is likely that a standard set of layer names will be required. D.3.3.1 Role The repetition of role in layer name and file name comes from BS1192 D.3.3.2 Classification The coverage of the original Uniclass for roads and bridges is too sparse for it to be a viable option, and it is now considered deprecated for this purpose. Uniclass2 is therefore the only serious choice available now to a UK Government agency.

Its coverage has fewer gaps, but they will need to be filled by CPIC, or assigned

temporary codes by HA in order to get the IAN into use. With underscores between pairs of characters, the layout is long – typically 14

characters The UK BIM Task Group is currently procuring a “free to use digital tool” that,

among other things will “use the CPIC classification system to structure the data storage”. It is envisaged that the successful tenderer will aim to complete Uniclass2. It is possible that a different classification system will result. As the UK Standard it would have to be adopted, but this should be possible by script files to rename layers.

The HA ADMM Asset Codes are also a classification, representing the subset of assets that are currently handled by IAM IS. Identifying the assets that will ultimately be entered into IAM IS, by including their asset codes in the layer names, will assist eventual automation of the transfer. D.3.3.3 Presentation The presentation code list is unchanged from BS1192. For clarity, “D” (Dimensioning) is to include relevant text, lines and arrows.


IAN 184/14 of 41 Sept 14

D.3.3.4 Usage Usage is important to understanding the drawing. It is not covered by BS1192, so has been included as an optional field. The IADD4UK list covers design, construction and operation. D.3.3.5 Description The Description may be extracted from the layer name using the logic “the part to the right of the first underscore after the last hyphen”. In practice, only the Uniclass2 classification will contain underscores before the description. Options may be parsed by splitting the description at underscores. The description will play a more significant role than intended by BS1192.

Differentiation beyond the scope of Uniclass2 (e.g. colour of road studs) has to

be accommodated within the description. The remaining part needs to be adequate as the explanation to the operator, but

also concise. The most efficient way to achieve consistency within an organisation may be to

create template files for each discipline, containing the layers that might be needed. A logical extension of this would be to share template files through the supply chain, but this would need administration and ownership. Given the number of versions of CAD that would need to be supported, it would be far less complex to make script files that create the required layers in any CAD version.

D.3.4 CAD Composition and Presentation This section is based on harmonised best practice from many previously differing approaches across a large multidisciplinary consultancy. It has worked well for several years.


IAN 184/14 of 41 Sept 14

D.4 Survey Data No notes


IAN 184/14 of 41 Sept 14

D.5 Geometric modelling data

D.5.1 Alignment Currently the only open exchange standard that covers alignment is LandXML. It is highly flawed, with a wide range of definition options that may be contradictory. There is no guarantee of a clean transfer between different systems. Bentley MX Genio is a de-facto plain text exchange standard that can include alignments. Bentley has added features over the years, such as rail cant and design speed, that are sometimes present in data sets. They may cause errors in 3rd party Genio import software. An international open standard, BuildingSmart IfcAlignment, is under development. A conceptually identical alignment class will also be added to the Open Geospatial Consortium (OGC) standard GML. It is expected that these will be adopted by all software vendors when published. D.5.2 Terrain The same caveats apply to the transfer of triangulated terrains. LandXML can define a surface, but there are optional parts of the definition that might not be implemented by export routines in all software packages. Import is yet more variable, because the terrain has to be converted to the internal format of the software package. Many importers effectively re-triangulate the points but might not retain the same triangle edges or boundaries. MX Genio is used to some extent for this purpose. However, it is probably exported only by MX, and will give consistent results only between installations using MX. OGC GML version 3.2.1 (also known as ISO19136) implemented a Triangulated Irregular Network (TIN) class. Its efficiency has been enhanced in version 3.3. This may well be a good option in the future.


IAN 184/14 of 41 Sept 14

D.6 Asset Coding In the fullness of time it is expected that data upload to the unified asset database IAM IS will be through suitable data drops using COBie, in accordance with BS1192-4, which is currently under development. Further details of the required formatting of different asset classes will be added when known. This may include the specification of asset locations using either a Facility/Region/Location hierarchy, geospatial location (representative point, bounding box, or feature id), and linearly referenced locations.

interim advice note 184/14 standard conventions, file ... › ha › ... · highways agency data...

Documents