Transport Impact Assessment Guidelines for Developements

The scope of a Transport Impact Assessments (TIAs) can range from a simple junction assessment to an evaluation of a complex road network. This may vary depending on the type or nature of the development and the possible impact it may have on the surrounding road network and infrastructures. Currently, the extent of work involved in conducting a TIA is determined only at the scoping meeting. However, the resource estimation generally takes place way before this. There may thus be concern by the Developer and Consultant to provide a more accurate estimate of resources needed for the TIA which can affect the duration and quality of the TIA. To provide greater clarity, LTA will implement a system of TIA classifications to provide Developers and Consultants a clearer understanding of extent of resources required before the scoping meeting. In addition, the Technical Conditions of Tender (TCOT) for all Government Land Sales (GLS), Government Allocated Sites, Land Sales, etc, will state the TIA classification for the development site. For redevelopment of existing sites, the Developer is to pre-consult the LTA on the TIA classification for their site.

The TIA classification divides the TIA study duration into 2 phases. In general, the TIA submission process will be as shown in Figure 1.1. The TIA will start with a scoping meeting followed by the submission of the TIA report and then the review phase.

Phase 1 of the TIA starts from the Scoping Meeting and based on the TIA classification, the Developer and the Consultant will prepare and submit the TIA report within a given timeframe. Once the LTA receives and approves the TIA report for review, Phase 2 of the TIA begins.

Table 1.1 presents the TIA Classification. It is to be used as a general reference for the industry to estimate the resource requirements of a TIA to be undertaken.

Table 1.1: TIA Classification

Figure 1.2 presents the TIA classification in graphical format in terms of submission and review process.

Type 1 TIA involves an assessment of not more than 5 junctions. The analysis software for such a TIA will be SIDRA Intersection only. The Phase 1 duration for this type of TIA is generally 3 months and is expected to complete when LTA gives the approval for Phase 2 to commence. The number of review sessions/time taken for Phase 2 (i.e. review of TIA) is expected to be around three or 3 months respectively. In summary, the aim is to close the TIA within6 months.

Type 2 TIAs:

1. Require the assessment of more than 5 junctions;

2. Require micro-simulation and/or analysis with SIDRA Intersection.

Generally, the assessment should not exceed 12 junctions within the study area. For Phase 1, in general, the duration for Type 2 is about 4 months and should end once the LTA approves for Phase 2 to commence. The target to complete Phase 2 is within four rounds of review or 4 – 5 months.

Type 3 TIA comprises an assessment of a study area with more than 12 junctions. Typically, they are for larger study areas such as masterplan studies. The overall duration for Type 3 TIAs is largely dependent on the complexity of the study. However, as a general guide, based on planning parameters remaining constant throughout the study, the LTA and Consultant should aim to close the TIA roughly within 12 months. The first 6 months in general should be for report preparation i.e. Phase 1 with the final 6 months for the review i.e. Phase 2.

Taking reference from the TIA classification, the Consultant should produce a TIA programme schedule and incorporate it within the TIA inception report or its equivalent. For TIAs affected by long holidays/festive season or special event, the Consultant and the Developer may propose a suitable commencement date. The programme schedule can then reflect the period affected, the proposed TIA commencement date and key milestones for the TIA.

The new process and analyses requirements for the TIA have been added to ensure that analyses are comprehensive, up to date and takes into consideration current behaviour trends that may impact the study area or to report on additional information that are useful for future reference. This section further expands the process and analyses requirements for Scoping meetings, PTAL, Public Transport, Pick-up / Drop-off points and additional report submission requirement.

It is important that the scoping meeting covers key aspects of the TIA such as the agreed study area, data required, survey periods, methodology and accompanying assumptions, scenarios, technical analyses, programme schedule, milestones, etc. If necessary, the LTA will request the Consultant to document and submit the aforementioned features as discussed and agreed at the scoping meeting in the form of an inception report. The contents of the inception report may form part of the final TIA report that is submitted to the LTA at the end of Stage 1.

The computation of a PTAL score was introduced in the 2017 TIA Guidelines to inform of how well connected a proposed development would be to the public transport system through the surrounding transport node(s). The LTA now also requires the Consultant to calculate the PTAL score of an existing adjacent development (to be agreed with the LTA at the scoping stage), and compare it with the PTAL score of the proposed development. Refer to the TIA Guidelines for the PTAL score calculation.

The aim is to ensure that the Consultant has maximised the public transport accessibility potential of the proposed development through suitable non-public transport (non-PT) improvement. Examples of non-PT improvements include introducing additional pedestrian access points for the development site and new pedestrian crossings on a public road that will improve walking distances to surrounding PT nodes.

In considering the public transport accessibility potential of the proposed development, the LTA will benchmark it with selected nearby developments. Should the PTAL score of the proposed development remain lower than that of the selected nearby development after such efforts, the Consultant will have to provide contextual reasons for the shortfall. This may allow the LTA to understand underlying issues affecting public transport accessibility.

Type 2 and 3 TIAs involve the analysis of a study area using either micro-simulation and/or high-level models or both. The micro-simulation models applied should include all road public transport (PT) details. For example, public bus services that ply in the study area, along with their service frequencies. It should be able to simulate the form of conflict(s) that is/are observed on site between general traffic and the PT services. This allows the simulation and analyses of the proposed development traffic impact on the PT service performance in the study area. The Consultant will include the analysis in the TIA report and propose or recommend improvement(s) if the analysis show worsening PT service performance for the scenario(s) that are tested.

In analysing the traffic performance of future year scenario(s), the Consultant is to make a request to the LTA for information on planned or future PT services and /or PT schemes. The schemes can be in the form of planned new bus services or routing, bus lanes, PT priority and/or etc.

For Type 2 and 3 TIAs, the Consultant will undertake the following:

1. Collect PT related information during stage 1 of the TIA. This may include but may not be limited to bus service routes and frequencies in the study area, travel times, bus lane information if any, dwell time at stops, etc and to ensure that these information are incorporated in the model calibration stage;

2. Confirm with LTA on possible PT schemes to be included in the TIA analysis and the performance measures for them ; and

3. The Consultant is to incorporate in the simulation models any PT plans/schemes that the LTA requires to be included in the scenarios for the TIA. Where there are planned/future PT schemes, the Consultant is required to assess the trade-offs between private vehicles and buses for the study area if the scheme is implemented

4. When there is no planned/future PT schemes, the existing schemes for public transport services will remain in the models for future year(s) scenario tests and analysis, but the Consultant is to then propose PT-priority schemes/measures based on the observed conflicts/bottlenecks. Effort is to be undertaken to show preferential treatment to PT movements and reduce factors attributing to PT delay, such as the following but are not limited to,

   1. Weaving friction near to road junctions between buses and cars

   2. Interrupted flow of buses due to development traffic accesses

5. The Consultant is to mitigate these factors and evaluate the traffic impact, with appropriate traffic schemes/signal interventions.

6. Analyse the PT service performance in terms of speed and travel time, and make comparisons of the scenario(s) that are tested. The Consultant is to propose/recommend improvements where PT performance for future year scenarios are worse off than the existing year.

For areas where there is a high volume of public buses, when required (for example, key transport nodes or Integrated Developments) or due to strategic interests, LTA may request more stringent traffic performance criteria to facilitate and safeguard the efficiency of the public transport mode, i.e. public bus movements.

Section 7.1 of the TIA Guidelines for Developments states that the Consultant is to assess whether there is a need for a PUDO facility at the proposed development and to estimate the number of bays it will require. For this, the Consultant is to estimate the traffic generated by proposed development’s PUDO activity first followed by an analyses of the proposed PUDO in terms of the queue length, proposed number of bays and circulation space. Therefore information such as (but are not limited to) traffic composition, trip rate, dwell time, etc, are to be collected to form the basis for the analysis.

In the event micro-simulation modelling is not applied to analyse the PUDO facility requirements, the Consultant is to propose a technical methodology to analyse the proposed number of bays and the resulting queues. For PUDO design proposals that result in queues extending onto the public road, the Consultant is to comment on the layout, identify potential traffic problems associated with the proposed pick-up/drop-off facility and recommend feasible improvements to the design.

The key outputs in the evaluation of a PUDO facility is to include the following but are not limited to:

1. Average queue length at the PUDO area for the proposed design;

2. Average waiting time in queue for the proposed design;

3. Average time in the PUDO system (duration from entering to exiting the PUDO) for the proposed design; and

4. Number of PUDO bays required to address vehicle queue(s)

Based on the key outputs, the Consultant is to determine if the PUDO provisions and layouts are adequate to cater to the forecasted PUDO demand.

The TIA guidelines provide detailed information and explanation on key topics a TIA report is to cover. To enable review/assessment of submissions with greater confidence, it is important that the Consultant submits a comprehensive TIA report consisting of the key topics. As such, a TIA report is to include the following but is not limited on:

1. Executive summary;

2. Report structure;

3. Information on proposed development;

4. The agreed study area and relevant junctions for assessments;

5. Methodology and assumptions to adopt for TIA;

6. Surveys data collection, findings & analysis;

7. Base year analysis for PT, PTAL and road traffic;

8. Proposed development trip rates, traffic production/attraction and distribution;

9. Walk Cycle Plan (WCP);

10. Future year(s) do minimum/ do nothing scenario analysis for PT, PTAL and road traffic

11. Proposal for Transport Improvement Measures;

12. Analysis of future year(s) scenario with proposed improvements/mitigation measures;

13. PUDO analysis and recommendations/improvements;

14. Site access and traffic circulation

15. Development Traffic Operation Plan (when required);

16. Traffic management during construction (when required);

17. Conclusion and Recommendations; and

18. Relevant appendices for the TIA report.

To ensure that a complete report is submitted, the consultant may use the aforementioned as a checklist for his/her TIA report, though it is not necessary to maintain the order of the topics. The Consultant may choose to organise the report the way that best presents the TIA findings. For example, information such as notes of meetings (NOM) and survey data, etc, may be included as part of the appendices for better organisation/presentation of the report. Lastly, to ensure quality submissions, the LTA now requires the Transport Consultancy’s Director to review and endorse the TIA report prior to submission to the Authority.

Traffic and transport simulation modelling has a key role in the analysis of a TIA. Today, traffic and transport simulation is widely used in the field of transport planning to assist transport professionals in analysing scenarios and undertake sensitivity tests. It is therefore essential for Consultants to ensure that the traffic and transport simulation models that they develop are input with the correct parameters. This section highlights aspects of traffic and transport model parameter settings, calibration and feedbacks for purpose of TIAs conducted in Singapore.

As part of the analysis requirements, a TIA report is to recommend improvements so that the road network (including junctions) performance in the study area operates within an acceptable performance criteria. One of the common recommendations is optimisation of a signalised junction. However, it is important for the Consultant to take into consideration the following when recommending junction optimisation as an improvement.

1. Green time for pedestrians to cross the junction; and

2. Safety aspects when revising phase sequences.

The average pedestrian walking speed at crossings in Singapore is about 1.0m/s but some crossings may adopt a 0.8m/s walking speed. This can be the basis to compute the minimum green time required for a pedestrian to cross a junction or mid-block crossing. When the analysis for a junction uses an isolated junction software package such as SIDRA Intersection, the Consultant will need to ensure that the 1.0 m/s is used for the pedestrian walking speed and crossing speed parameter. In addition, the modelled minimum pedestrian time should minimally be the minimum crossing time + 6 seconds (minimum). The minimum crossing time is defined as:

When developing a micro-simulation model, in addition to setting the average crossing speed to 1.0m/s, the Consultant will also need to ensure that the effects of pedestrian crossing and the impact on junction delays are coded in accurately. Most micro simulation softwares do not include built-in capabilities where the simulated pedestrians can identify situations that are unsafe to cross a road, such as inadequate green time. Therefore, the Consultant is to apply the appropriate modelling technique so that realistic simulation of pedestrian impact on traffic at crossings is possible.

Consultant may consider the following techniques to simulate realistic effects of pedestrian crossings at a junction:

1. Compute the flashing green man (Min Crossing Time)

2. Compute static green man (6 seconds, unless observed or stated otherwise)

3. Compute the total green man (total pedestrian green time)

Example 1:

In the case of Example 1, a pedestrian will take 16 seconds to complete the crossing. Pedestrians are therefore assumed to not attempt/begin to cross the carriageway during the flashing green man phase, as they will not be able to complete their crossings in time. As such, pedestrians in the micro-simulation will only start crossing during the static green man.

For optimisation of signal timing at signalised junctions, the Consultant will need to ensure that the respective traffic phase timing is sufficient to accommodate the total green man.

Another key consideration for signal optimisation is the phasing sequence of a signalised junction. Sometimes revisions of a phase sequence may result in improved junction performance. However, the Consultant is to ensure that recommendations to revise the phasing sequence do not compromise the safety of both pedestrians and vehicles. It is advisable for Consultants to adopt the standard Diamond or Split Phase sequences, which are more common on Singapore streets. The Consultant is to seek LTA’s approval first if the intention is to run a scenario in which the phasing sequence of one or more junctions is/are different from what is currently on site and/or is not common on Singapore streets.

In addition, the Consultant is to consider traffic signal coordination between junctions (i.e. the traffic signals for the junction in question is coordinated with the other junctions nearby or in the corridor to provide green wave for the peak traffic stream). For this, the consultant may observe and record the traffic arrival patterns at an approach. Information such as volume of traffic that clears the junction during the green phase of the approach and the platooning effect of traffic can be used as an indication if the junction is coordinated with an upstream junction.

One of the advantages in utilising micro-simulation models, as an analysis tool for TIA, is the ability to simulate detailed vehicle interactions. Simulations of road side friction effects such as access points, bus priority, lane reductions, etc, in a network as well as driving behaviour such as aggressiveness of the motorist, weaving in/out of lanes for lane changing, etc, are possible for road network analysis in a study area. Hence, for a TIA that requires micro-simulation modelling as its analysis tool, it is essential that the model reflects the effects of these occurrences. This is possible when the model calibration stage takes into consideration the information / data of the travel time for selected corridor(s) within the study area.

In general, the travel time section(s) will be along the main corridor of the network of the study area. However, there may be situations where the travel time of the corridor(s) of lower hierarchy are of interest and included as part of model calibration. The Consultant is to seek the LTA’s agreement in the selection of the travel time corridor(s) for the TIA that they will undertake.

Currently there are two possible methods to obtaining travel time information:

1. Floating car survey

2. Google maps (extract at actual time)

When using the floating car survey method, the survey vehicles are to travel in both directions of the selected corridor(s) if the corridor(s) is a dual carriageway. To ensure correct data recording, the surveyor is to start his/her travel time counter (usually a stopwatch) once the front of the survey vehicle passes the stop line of the starting junction. A corridor may consists of more than one travel time section/checkpoint. For such an arrangement, the travel time will be recorded once the survey vehicle passes a travel time section/checkpoint. Thereafter, the travel time count is to end once the survey vehicle has completely passed the last junction in the corridor and the time is recorded.

There are two possible ways to extract travel time information from Google map.

1. Through scripting & automation

2. Through graphical user interface (GUI), in Google map website.

In the event that scripting & automation is used, the Consultant will need to submit the travel time output in an appendix to the TIA report/technical note. The output must include the date and time stamp of information extracted. For travel time that are obtained directly from Google map GUI, the Consultant is to ensure that screen captures of the corridor in the map, the start & end coordinates and the time stamp on the screen are also compiled as part of the appendix in the TIA report/technical note.

The Consultant is to use the travel time information to calibrate the micro-simulation models. Table 3.1 presents the travel time threshold acceptable for calibration purpose. This table excludes travel time that is below 3 minutes as it becomes impractical beyond this threshold.

Table 3.1: Travel time calibration threshold

The TIA report/technical note for the micro-simulation models is to include this.

The LTA is mindful that to calibrate the traffic and transport simulation models, the Consultant may want to change or adjust certain default parameters or settings in the analysis software. However, it is important for the Consultant to understand that he/she is also responsible in ensuring that the submitted traffic and transport simulation models applies sensible parameters or setting values and adhere to planning principles. As such, the Consultant must consult and obtain the approval of the LTA coordinating officer, before specific parameters or settings are changed.

To assist the LTA in reviewing the submitted models, the TIA report or technical note must include a table listing the agreed changes to the parameters or settings. Justification or explanations are required for each of the changes made. This will allow the LTA to have a better understanding when reviewing the TIA report or technical note of the models and help expedite the review process for TIA approval.

With the TIA classification and the streamlining of the review process, the Consultant is to ensure that he/she checks thoroughly the micro-simulation or high-level models before submitting them to the LTA. The Consultant may send his/her base models to LTA for a general feedback on model coding and output settings during the Phase 1 of the TIA. However, the Consultant will need to be mindful that the LTA will generally need between 10 -15 working days to provide response to the feedback. Hence, there is the need to factor this into the TIA’s programme schedule if the Consultant plans to obtain LTA’s feedback on their models. As such, the time taken for LTA to provide the general feedback cannot be the reason for late submissions.

The purpose of this section is to assist transport modellers to prepare the necessary documentation, configure the necessary model settings and conduct internal checks of model(s) submission to LTA.

The submission of the model(s) is to include the following processes:

1. Model verification;

2. Model calibration;

3. Model validation; and

4. Evaluation output.

The TIA report must include a section briefly describing (1) the objective of the modelling exercise, (2) the area that the model covers, (3) the methodology adopted as agreed during the scoping meeting, (4) model calibration & validation (5) scenario tests, outputs & analysis.

Conclusions and recommendations that are based on the modelling analysis can be tabulated/reported in the final section of the TIA report, i.e. the Conclusion & Recommendations section. Alternatively, the Consultant may also choose to produce a separate technical note/report for the modelling works and attach it to the TIA report as an appendix. For such cases, it is preferable for the technical note to have a clear title/labelling, for example, “Project ‘A’ - Transport Model Technical Note 1 (Revision 1, Feb 2019)”. A model submission is incomplete without a section on modelling works and/or a technical note as an appendix in the TIA Report.

The submission of the model files must include the following (all in one folder):

1. Network Model:

   1. Graphical / view settings in the submitted models and descriptions / explanations to show clearly:

      1. road hierarchy;

      2. capacity (links and turns);

      3. free flow speed;

   2. Background files (e.g. CAD drawings in the DWG or DGN format, PDF files, JPG/PNG files) that were used as reference to develop the network model.

   3. Ensure that details such as number of lanes, permitted / banned turn movements, lane allocations, signal phases etc, have been checked, verified and properly coded in before submitting the model(s).

   4. Approach links to junctions, key corridors and expressways must be labelled/named accordingly with valid and self-explanatory road names.

2. Matrix estimation / correction

   1. Ensure that the starting matrix first assigned to the base model is included in the submitted models.

   2. Provide a comparison diagram showing the difference between the starting / initial matrix and the final matrix assigned in the model’s highway assignment.

   3. Provide a description on the source, assumptions and zone disaggregation / aggregation (if any) of the starting / initial matrix.

The submission must include the following in an Excel spreadsheet:

1. Table with a list of link volume calibration with GEH statistics and R-square graph.

2. Table with a list of turn volume calibration with GEH statistics and R-square graph.

3. A list of network object attributes (user-defined or default) that were used for model calibration.

4. Visual diagrams of key corridors or routes where the travel time is to be analysed and the accompanying observed travel time data collected from site. This may not be in Excel spreadsheet.

5. Table showing the comparison between observed and modelled travel time of key corridors in the study area. The table should also include columns showing differences in terms of time (seconds) and percentage.

6. A graph with the trip length distribution (can be in excel spreadsheet) and its skim matrix(s).

7. Table with the comparison between observed and modelled average travel speed of key corridors. The table should also include columns with the difference in terms of kilometre-per-hour and percentage

Minimally, the following evaluation output must be included in the TIA report or the technical note attached to the TIA report.

1. Visual diagrams of key corridors or routes with the travel time (both observed and modelled).

2. Table with the comparison between observed and modelled travel time of key corridors in the study area. The table should also include columns with differences in terms of time (seconds) and percentage.

3. A graph with the trip length distribution (can be in excel spreadsheet) and its skim matrix(s).

4. Table with the comparison between observed and modelled average travel speed of key corridors. The table should also include columns with the difference in terms of kilometre-per-hour and percentage.

Furthermore, additional evaluation may be required / requested as and when required.

The submitted model(s) is to include graphical settings and/or views that allow the reviewing officers to view these outputs. In the case where graphical or view settings are not possible in the model(s), other form of presenting these outputs such as using Microsoft PowerPoint, Word or Excel software may be considered.

The outputs presentation must be map based with clear indications on the units of measurements, location of junctions, roads and/or corridors. The TIA report accompanying the submission is to include a compilation of these outputs.

The submission of the model files is to include the following (all in one folder):

1. Network model

   The micro-simulation network model is to include the following:

   1. Background files (e.g. CAD drawings in the DWG or DGN format, PDF files, JPG/PNG files) used as reference to develop the network model.

   2. Ensure that details such as number of lanes, permitted / banned turn movements, lane allocations, signal phases, bus lanes (broken / continuous), etc, had been checked, verified and properly coded in before submitting the model(s).

   3. Approach links to junctions, key corridors and expressways must be labelled/named accordingly with valid and self-explanatory road names.

   4. List of assumptions made in network development stage (example: aggregation of access points, speed reduction due to side frictions, etc.). Include visual diagrams in the TIA report or the technical note attached to the TIA report to support these assumptions and aid the review of the submission.

   5. Realistic vehicle speeds for all turn movements in the network to simulate the impact of geometric delays.

   6. Proper coding of the posted speed limit for all road links in the network.

   7. Proper coding of priority movements (e.g. vehicles turning onto a major road from a minor road must give way to traffic on the major road), Bus Mandatory give way boxes or yellow boxes in the network using priority rules.

   8. Signalized junctions must include traffic signals. Green phase times must take into consideration the minimum green time required for pedestrians to cross the road.

   9. The model must include pedestrian crossing for locations with high volume of pedestrian flows.

2. Vehicle inputs and Demand matrices

   The submission must include the following in an Excel spreadsheet:

   1. For static routing models – Table of vehicle inputs with the following information:

      1. a clear and legible name / description for the input

      2. the road name of the input link

      3. the input volume

      4. vehicle classes / types (example: development traffic, background traffic, etc.)

   2. Bus services and their frequencies / timetable

   3. Settings for the simulation of vehicles entering the network model must be as close as possible to the input volume. For example, if the Vissim software is used as the simulation tool, the “volume type” for all traffic inputs must be set to “Exact”.

   4. List the traffic compositions for the vehicle classes / types defined in the model. For example, the proportion of coaches and minibus for vehicle class labelled as Company Shuttle Bus.

   5. For assignment with matrix(s) – provide matrix(S) with the following information.

      1. Zones with the road names or development names as identifier

      2. Rows total

      3. Column total

The submission must include the following in an Excel spreadsheet:

1. Table with a list of link volume calibration with GEH statistics and R-square graph.

2. Table with a list of turn volume calibration with GEH statistics and R-square graph.

3. Table with a list of queue length calibration with queues within the threshold defined in Table 3.1 in section 3.2.2 of this Addendum.

4. Visual diagrams and table of key corridors or routes for the travel time calibration. The table with the comparison between observed and modelled travel time of key corridors/routes in the study area. The table should also include columns showing differences in terms of time (seconds) and percentage.

5. A list of:

   1. Newly created / modified driving behaviour with clear explanations on the need to create a new driving behaviour and/or modify the default value(s) of parameters for driving behaviour.

   2. Other parameters that were modified / edited to calibrate the model.

   3. A list of network elements attributes (user-defined or default), if any, that were used for model calibration.

The submission must include:

1. Table with the comparison between observed and modelled average travel speed of key corridors. The table should also include columns with the difference in terms of kilometre-per-hour and percentage.

2. Table comparing the observed with the modelled number of signal cycles to clear a junction for all signalized junctions.

Minimally, the TIA report will include the following evaluation output.

1. Delay by movement and classified by vehicle type/class including PT

2. Maximum and average queue length by movement - classified by vehicle type/class including PT.

3. Number of cycles for queues to clear a junction by approach and movement and by junction.

4. Average travel time for private vehicles and public buses on key corridors.

5. Average travel speed for private vehicles and public buses on key corridors.

6. The trade-offs between private vehicles and buses for study area with bus lane, transit corridor or etc.

7. Comparison of above-mentioned outputs across all scenarios shall be shown explicitly.

Furthermore, additional evaluation may be required / requested as and when required.

The submitted model(s) must include graphical settings or views that allow the reviewing officers to view these outputs. In the case where graphical or view settings are not possible in the model(s), other form of presenting these outputs such as using Microsoft PowerPoint, Word or Excel software may be considered.

The output presentations must be map based with clear indications on the units of measurements, location of junctions, roads and/or corridors. The TIA reports accompanying the submissions must include a compilation of these outputs.

A submission is to comprise model files, related figures or spreadsheets and the TIA report neatly arranged in a folder. For a typical micro-simulation modelling submission, there should be at least two sub-folders. For a submissions of high level and microsimulation models, there should be three sub-folders. The folders should be as follow:

1. Technical Documentation (spreadsheet, figures / diagrams, presentation of outputs, TIA/technical report);

2. High Level Models (all files necessary for the models in this folder); and/or

3. Micro-sim Models (all files necessary for the models in this folder).

Annex A at the end of this Addendum provides a checklist. The objective of the checklist is as follow:

1. To assist transport modellers to ensure that the requirements for model submission are met.

2. To ensure that the model(s) have been vetted / checked prior to submission.

The transport modeller is to prepare the model(s) according to the requirements stated in this section and duly fill in the fields in the “Prepared by” part at the bottom of the checklist and sign it. A senior modeller or manager will be required to check / vet the models before the submission. He/she may come from the same organisation that is doing the submission or someone that is independent from it. The checker can provide his comments in the “Remarks” column. Once the comments are incorporated/addressed, the check box at the bottom right corner of each “Remarks” column can then be checked-off and the checker will then sign off the checklist. The report for Type 2 and 3 TIA must include the checklist with the “Prepared by” and “Checked by” boxes duly completed.

The 2017 TIA Guidelines also introduced the need for a Post Implementation Review (PIR) for larger developments or developments with uncertainty on whether the adoption of certain Transport Improvement Measures are necessary. Now, the PIR may also be applicable to single developments. Developers are strongly encouraged to pre consult with the LTA before the TIA, to ascertain this requirement on their proposed development.

Section 7.5 of the TIA Guidelines lists the scope that may be required for a PIR. This includes:

1. classified traffic and/or pedestrian and/or cyclist counts;

2. Observation traffic and/or transport situation;

3. Other types of surveys;

4. Traffic/transport assessment; and

5. Propose improvement(s)/mitigation(s).

Prior to commencing with the PIR, the Developer / Consultant is to discuss and seek agreement from the LTA to determine the scope and requirements. The Developer is strongly encouraged to seek LTA’s advice at an early stage to outline the scope and requirements of the PIR, even before a Consultant is involved.