Envision Scenario Planner (ESP) Help


Envision Scenario Planner (ESP) is a web-based 3D scenario sketch planning and assessment toolset for urban planning projects. The system was developed collaboratively by Curtin University, Swinburne University of Technology, the University of Melbourne and the University of Canterbury with support from the Cooperative Research Centre for Spatial Information (CRCSI) and the Australian Urban Research Infrastructure Network (AURIN).

ESP was developed to supply end users with a tool for investigating and comparing options for redevelopment sites that would bring together scenario visualisation and quantifiable assessment outputs. As such, in addition to providing users a 3D volumetric virtual world to design their precincts the system also reports on a range of performance categories including embodied and operating carbon, energy demand, water demand, transport, construction and operating cost, and more.

The ability for urban planners to design, assess and communicate redevelopment options is an important and valuable innovation for urban planning. Not only does this support evidence-based planning by providing quantifiable project outcomes, but the visual nature of the system can convey massing and density that can be highly contentious with various project stakeholders and community groups. While there are a number of software applications in existence that can be used to design, visualise or assess precinct plans, to our knowledge there are none that do them all in one package and thus intrinsically link the visualisations to the performance outputs and allow rapid scenario option creation in as short of a time as a few minutes.

Unlike most precinct assessment tools in existence that are built using spreadsheets, ESP uses an object-based architecture. While spreadsheet-based assessment tools work on aggregate values summarising land uses or broad building types on the basis of gross floor area (GFA), in ESP everything is an object with it’s own properties and attributes that can altered, providing endless opportunities for new types of precinct objects to be added to the system and altered within it. Additionally, the spatial nature of the system means that no two lots will be assessed the same due to their different sizes and a user’s vision for a redevelopment area can guide the creation of scenarios.

A guiding principle when designing ESP was to ensure the system would be intuitive and relatively easy to use while not sacrificing the quality and sophistication of the modelling that happens within it. While sophistication and ease of use tend to be opposing concepts, ESP accomplishes this balance by including default modelling parameters that are specific to Western Australia, Victoria and New Zealand and designing a user-friendly interface that is cleanly laid out and feels intuitive to the user. Moreover, all the calculated fields and algorithms are not exposed to the user in order to hide the complexity of the system. For Western Australia, Victoria and New Zealand we also provide a default precinct object library for users to use when designing their precincts. The result is a system that is ready to use at the outset in the aforementioned locations and yet is flexible enough to be used anywhere in the world and allow new precinct objects to be created or imported into it.

While designing a precinct, users of ESP are able to import and/or create land parcels, subdivide and amalgamate lots, zone and rezone land, experiment with lot height limits, visualise the existing built form by extruding building footprints, populate their precinct with precinct objects using a number of methods including drag-and-drop and auto-allocation, draw in roads and pathways, and more. During the design process the system generates feedback on the performance of the design being created, modelling a wide variety of outputs including the following:

  • Operating Energy (Gas and Electricity)
  • Carbon (Embodied and Operating)
  • Operating Water (Internal and External Demand)
  • Stormwater Run-off
  • Parking (Street-level, Garage and Underground)
  • Cost (Construction and Operating)
  • Transport (Mode Split, VKT and GHG)
  • Planning Metrics (Density, Plot Ratio, Number of Residents, Number of Jobs, etc.)

The remainder of this manual will go into detail about the functionality of ESP. Sections are presented in the order in which an end user might approach a new project and then the manual concludes with an example use case. It is also presented in the video below

System Requirements

ESP uses Cesium for its 3D WebGL rendering, so the system requirements are similar to those of Cesium:

  • Browser: Chrome, Firefox, Internet Explorer 11, Opera
  • Note that development of the tool primarily used Google Chrome, so this will provide the best user experience.
  • Note also that Safari may require WebGL to be enabled manually.
  • Graphics: Any graphics processor that supports WebGL

ESP is designed for relatively small precincts, on the order of dozens to hundreds of lots. Most relatively modern systems should perform well at this scale, especially those with dedicated graphics cards. Cesium is capable of rendering thousands of lots simultaneously, but will require more powerful hardware for the best user experience

Understanding the System

ESP was designed to be fun and simple to use and almost game-like in how users interact with the system. Behind the scenes, however, is an inheritance model that object-oriented programmers will recognise.

Every building, public open space, or street placed or drawn into a precinct can be considered a “precinct object”. Each precinct object is an instance of a typology that can be found in the Typology Library. In essence, every typology is a template for a precinct object and this template can be used to produce a specific precinct object over and over again. Moving up the hierarchy, every typology has a land use class that it belongs to, whether it is “Residential”, “Commercial”, or something else. Each of these land use classes have a different set of fields that are used to describe how a typology of this class is defined. For example, while there is a field in the “Residential” class to indicate the number of residents in a building, the “Commercial” class instead has a field indicating the number of jobs provided by the establishment.

It is important when using ESP that users be aware of what happens when an object’s or typology’s properties are changed, as this can be a powerful way of customising a scenario or possibly a dangerous way of changing a scenario’s properties unexpectedly. As explained previously, when a user places a typology into their precinct, a precinct object is created that is an instance of the selected typology. A user may wish to do this repetitively to place multiple instances of a typology as they are designing their precinct. At any stage in the precinct design process, a user is able to go into a typology and change some of its properties. For instance, a user may change the proportion of external land to a typology covered by lawn. Doing so will enact this change for all objects in the precinct that inherit from this typology. A property of a precinct object, however, can be decoupled from the typology it inherits from by going into the object and overwriting that property. Doing so enacts this change only for that precinct object and no longer will it inherit this property from its typology.

The inheritance system in ESP makes it easy for a user to quickly test the impacts of making blanket changes for all instances of a typology while leaving instances of other typologies unaffected. For example, a user may wish to change the appliance fit-out of all 2-bedroom houses while leaving all other residential typologies unaffected. At the same time, a user may want to apply this modelling assumption to only a specific subset of 2 bedroom houses placed in a precinct and as such would do so by overwriting the appliance property for the select individual buildings. It is important to note, however, that once a property is overwritten it cannot be undone. A user will have to delete the precinct object and place a new one of the same typology in order for it to inherit all of its properties from its typology once again.

Users need to be aware of this inheritance system that is the foundation of ESP. Understanding this aspect of the system provides users the power to quickly make changes to their modelling assumptions, while failing to understand it means that users could unknowingly make changes to their scenario that they did not intend. The diagram below depicts this relationship between the precinct, precinct object, typology and land use.

Figure 1

[Click to Enlarge]

While designing a project in ESP, a user is able to allocate the following land use classes to land parcels: Residential, Commercial, Institutional, Mixed Use, Open Space, and Pathway. The land use classes have been kept broad in order to allow the system to be used easily in any location, regardless of the specifics of that location’s planning scheme. As ESP is primarily a system for scenario modelling redevelopment options in the middle suburbs, the focus of the system is on the residential land use. As such, the modelling and outputs for residential typologies are more detailed and specific than for the other classes. The schema for residential typologies has been designed in part to use some of the outputs of an AccuRate Sustainability assessment; however, the form for specifying a residential typology is still generic enough to allow the fields to be populated from other tools or resources. One benefit of using AccuRate, however, is that in ESP one is able to see how heating and cooling energy requirements change as a building is rotated on site. Greater detail will be provided on this in Section 8. All other land use classes in ESP have their typologies assessed entirely within the system using a set of default modelling parameters that can be edited by the user.

In ESP there are two levels of scope of the modelling parameters than can be modified for testing outcomes of different scenarios. The parameters that can be found in the Project Properties Screen (accessed from the Projects Screen or from the Project Design Screen) can be considered “global”. A global parameter is one that users would either not expect to change across precinct objects in a project, or not expect to change for different typologies in a land use class. For instance, the amount of carbon generated by every kWh or MJ of scheme electricity is an example of a global parameter, as users would not expect this to vary across objects in their precinct, since the same centralised system would be providing the power for all the objects. Another example is the embodied carbon per square metre of a road made of full depth asphalt, as a user would not expect this value to change from one road to another if the two roads are made from the same material. If users wish to change any of the global parameters from their default values they can do so from the Project Properties Screen.

The second level of scope of modelling parameters in ESP is at the typology level. When users define a new typology they must first select a land use class, which will present them with a form specific to that land use. The form to define a new typology of a particular land use class will contain default values that users can change before saving their new typology. Thus users can have different typologies of the same land use class with different values for their shared attributes, and changing these values in a typology will not impact other typologies of the same land use class. For instance, each land use class representing buildings or open space will have a default proportion of extra land covered by lawn, annual plants, hardy plants and impermeable surfaces. Having parameters at the typology level means that a townhouse, for instance, can have a different proportion of extra land covered by lawn than a high rise apartment building as users would not necessarily expect these values to be constant across the precinct (i.e. global). Users should be aware of the defaults at both the global/precinct level and the typology level when preparing their precinct scenarios.

Having introduced ESP’s inheritance model, its assessment method, and the different scopes of modelling parameters in the system, greater detail is provided over the remaining sections of this manual to familiarise users with the details of the system and the user interface.

The Projects Screen

When users log into the ESP system, the first screen they will encounter is the Projects Screen (shown below)

[Click to Enlarge]

[Click to Enlarge]

From here, users can double-click a project to launch it, search for a project by typing its name into the ‘Filter’ field that appears in the top right, respecify the number of projects they would like to view on one page by changing the number in the bottom left of the window, or navigate through different pages of projects by click the arrows in the bottom right. Importantly, toggling the icon will switch the list of existing projects to a list of existing templates. Templates can be a quick way of starting a new project with housing typologies and project parameters already set for your desired project locality or region. Templates cannot be opened or edited by basic users, only duplicated. Once a template is duplicated it is added to the project list where it can then be renamed and edited like any other project.

Selecting a project from the list will open up a series of icons in the toolbar above the project list window (shown below).


The icons allow users to do the following (in order from left to right):

  • Create a new project: Users will be redirected to a new window where they will be able to provide information about a project and adjust the global modelling parameters.
  • Edit a project’s parameters: Users will be redirected to the Project Properties Screen, allowing them to change a project’s details or global modelling parameters.
  • Delete a project: Users will be prompted to agree or cancel the action of deleting the project from the list. Agreeing to this action cannot be undone.
  • Duplicate a project: An exact duplicate of the selected project will be created with a number trailing the project name indicating a new version. The duplicate project can be renamed by clicking on the ‘Edit’ icon. This is an excellent way of tweaking scenarios for comparison later on.
  • Export/Download a project: Clicking this icon will prompt a download action of the project’s data to a KMZ format capable of being viewed in an augmented reality (AR) application being developed separately from ESP. The file contains both the 3D spatial content and some of the reporting outputs from the scenario.
  • Launch a project: Clicking this icon will launch a project and redirect the user to the Project Design Screen. This has the same effect as double-clicking a project’s name.
  • Show templates: Administrators of ESP are able to create and edit template projects that can be duplicated, but not opened or edited by end users. To end users, duplicating a template can be a quick way of getting started on a new scenario that has its precinct parameters already customised for a given location and a set of typologies already loaded in the library. Note that not all users will have access to all templates. Consult an ESP administrator to learn more.

Starting a New Project

Users can start a new project in ESP by clicking on the New Project icon on the Projects Screen or by duplicating an existing project or template by clicking on the Duplicate icon and then the Edit icon to edit the project’s properties. This will bring up the screen shown below

[Click to Enlarge]

[Click to Enlarge]

The form in the Project Properties Screen allows users to provide some general information about their project and edit their project’s global parameters if desired.  Fields marked by a red asterisk (*) are mandatory fields that will prevent the project from being saved if left blank.

Within the Location section that appears near the top of the form, the Suburb, Post Code, and SA1 Code fields have been provided to allow users to supply additional location information in case they wish to merge census data with their project outside of ESP. As such these fields are purely optional. The fields Latitude, Longitude, and Camera Elevation on the other hand should be left blank by the user as these fields get populated automatically once land parcel data has been imported or created in a project.

The Climate Zone field in the Environment section is not specifically used in any calculations in ESP but it is important to make sure this value corresponds with the climate zone selected during the AccuRate assessments for the typologies imported into the project. Heating and cooling energy requirements will vary significantly across different climate zones and for this reason the climate zone has been included as a field in the list of precinct attributes for reference purposes.

The remaining fields in the list are global parameters used for calculating the report outputs generated by ESP. Default values are supplied but users should review them to see if any should be changed to better suit their particular project area. When users use a project template that matches their project area, however, it is unlikely that they will have to change many of the project parameter values from their defaults, although this is optional if they would like to test some assumptions or if they possess project specific parameters that would be more accurate than those provided. The exception is for the land value parameters and the transport modelling parameters at the end of the list that users will mostly likely want to adjust, as these parameters will be very spatially specific. More is discussed about the transport model later.

Project Design Screen

When a user launches a project they will be redirected to the Project Design Screen (shown below), where all of the design and scenario modelling work is done in ESP. If the launched project already contains property data then they will be zoomed to the extent of the precinct.

[Click to Enlarge]

[Click to Enlarge]

The left panel of the Project Design Screen contains all that is required for designing a precinct. The Objects section lists the precinct objects that have been placed into a precinct. The Typologies section contains the library of objects available to be placed into a precinct. The Lots Section lists all the lots that have been imported or drawn into a precinct. The Footprints section is where building footprint data is managed. All four of these sections offer a variety of user functions that are discussed later in the manual.

The right panel is the Reports panel that contains all the assessment output information for all of the land use classes, plus a Transport Report and a Precinct Report that provides an overview of the project. The precise report being shown can be chosen by selecting it from the dropdown list.

The centre panel contains the 3D design window and is where all the precinct design and visualisation is carried out. Users can navigate the globe in the following ways:

  • Zoom in and Out: Scroll up and down with the mouse
  • Move Around: Click and drag with the mouse
  • Rotate and Tilt: Hold Control (Google Chrome) and click and drag with the mouse

The centre window also contains a legend in the top left corner displaying the colours associated with each land use, and in the top right users can find a button allowing them to select a different basemap from the default satellite imagery layer provided. Note that not all basemaps will work at all zoom levels. Among those that work best at a relevant range of zoom levels are Open Street Map, Stamen Watercolour and Stamen Toner.

Importing and Editing Lots

When a user begins a new project, no lot data will be present. Users can bring in lot data in three different ways. Two of the ways involve importing data and the third involves drawing in the land parcel data manually. Importing data begins by clicking the import icon (shown below) at the top of the screen


Creating data manually begins by clicking the create icon (shown below) in the “Lots” section of the left panel


Uploading an Envision File

An Envision file is a zipped file containing two other zipped files and a text file that is provided as an output from the Envision precinct identification system (See Envision documentation). One of the contained zipped files is a building footprint dataset in ESRI Shapefile format and the other is a land parcel dataset also in ESRI Shapefile format. The text file contains information on average land value per square metre by land use category that users can use to manually change the default land values in the global parameters list of the project.

After clicking the icon, the panel on the left will change and show a grey box where the user can either drag-and-drop the zipped precinct (lot data) Shapefile, or click on the grey box to open a window in which they can navigate to the file to upload (shown below). The upload process can take several seconds to several minutes depending on the size of the precinct.

[Click to Enlarge]

[Click to Enlarge]

The Envision land parcel dataset is simply a Shapefile of lot data containing two additional fields that ESP can use to get the user started on their scenario-modelling project. The first is a “develop” field containing 0’s and 1’s, where a 1 indicates that a lot has been flagged for redevelopment in Envision, and the second is a “landuse” field telling ESP which land use classes to apply to the land parcels. A user can check this out by opening the land parcel Shapefile in any GIS application and viewing the attribute information.

Uploading Custom Lot Data

If a user does not have access to Envision, or simply has their own data they would like to import into an ESP project, this can be done very simply. In fact, any zipped file containing a polygon Shapefile dataset can be uploaded into ESP as a starting point for a project. A user just has to follow the same steps described above: click the Import icon and either drag-and-drop the zipped Shapefile onto the grey box that appears or click the box to navigate to the file. Just note that doing this will mean all the lots will render with the colour grey, meaning no land use classes have been applied to the lots (shown below)

[Click to Enlarge]

[Click to Enlarge]

Also, none of the lots will be flagged as being developable. Users can provide this information on their own, however, simply by including landuse and develop fields in their Shapefile. The land use class values that are expected by ESP include RESIDENTIAL, COMMERICAL, MIXED_USE, INSTITUTIONAL, and OPEN_SPACE. Note that polygons representing roads or other pathways should not be included in the import dataset as they are handled separately in ESP. Also note that users can optionally include a height field in their Shapefile if they wish to apply building height restrictions in their project or simply visualise 3D extrusions of their lots. The heights of lots, however, can also be set from within ESP (see section 7d for more information).

When importing custom lot data into ESP the individual files of the Shapefile must be zipped together. Importantly, the individual files should not be placed in a folder before being zipped otherwise ESP will not be able to read in the data.

Drawing in Lots Manually

Lots can be drawn manually into ESP if land parcel information is not available to the user or if the user wishes to add more lots to their project than is included in their import file. Simply click the + icon in the Lots category of the left panel to open the Lot form. Under the Space heading there is a button that reads “Create” that once clicked will begin an editing session during which a polygon can be drawn. As the user clicks on the globe, yellow handles will appear showing the vertices of the polygon being drawn. After the user is content with shape of the lot, double-clicking anywhere on the globe will complete the polygon. Note that the final double-click does not produce a new vertex unlike drawing in some GIS applications.

Once the polygon/lot has been drawn, the Lot form can be used to apply a land use class and height to the lot and a box can be checked indicating whether or not the lot is developable. At this point, a few options remain for the user. Either the Cancel or Create buttons at the bottom of the form can be clicked, or the user can click on the newly created lot to select it and then click Edit or Delete if they wish to maintain the edit session and either make some adjustments to the lot or remove it and start again.

It is worth noting that if a user wishes to draw several smaller lots it is far more efficient to create one large lot and subdivide it rather than drawing each small lot individually.

Editing a Single Lot’s Properties

After a lot has been created or imported, a few options exist regarding the management of that lot. Double-clicking a lot in the Lot list or on the virtual globe will open the Lot form and allow a user to change the land use class of the lot and flag/un-flag it for development. Clicking the Edit (pencil) icon in the Lot panel will also open the Lot Edit form. Users can also apply a height limit to a lot or toggle the Edit button to change its geometry (shape).

Lot Filtering and Selection

While users can make a selection of a subset of lots manually by holding down the Shift key and clicking on individual lots, this can make selection of a large number of lots a tedious affair. For this reason ESP includes a Filter Lot Selection tool that can be accessed by clicking on the Filter (funnel) icon in the Lots panel. Clicking this icon opens up a form that allows users to set values for parameters that will be used to filter and select all lots that meet the conditions of the filter. Parameters include the land use class, whether or not a lot is developable, minimum and maximum lot area, and minimum and maximum lot height. Users can even provide a value in the Limit field that will limit the number of lots being selected. This may be useful if users wish to use the Filter Lot Selection tool along with the Auto-Allocation tool discussed later. Note that any filter parameters in the filter form left blank will not be factored into the selection, and by default the minimum and maximum filter parameter values are set to those of the lots in the precinct.

Bulk Editing of Lots

If users wish to edit the properties of several lots at once, this can be done by first using the Filter Lot Selection tool, or holding down the Shift key and clicking on all the desired lots to make a subset selection, and then clicking on the Edit (pencil) icon in the Lots panel. This will open a form allowing users to change the land use class, whether or not a lot a developable, and the maximum height. Unlike editing when only a single lot is selected, selecting multiple lots does not allow the user to change the lot’s name, description or geometry.

Visualisation Options of Lots

ESP supports three visualisation options for lots: Footprint, Extrusion and Extrude Non-Develop. The first renders lots in 2D, the second extrudes all lots to their maximum height limit and the third only extrudes the non-developable properties so the user can still see the building objects they are placing on developable lots. To change how lots are visualised, simply click the Visualise (camera) icon in the Lots panel.

Displaying Building Footprint Data for Context

ESP allows users to optionally import building footprint data to visualise along with the typologies that are being added to a precinct. The building footprint dataset must include a height field otherwise the footprints will not be visible behind the lots. Clicking the Import icon in the Footprints panel will allow the user to navigate to and select the appropriate file.

When this layer is turned on (controlled by the checkbox next to the layer) the extruded footprints render in grey to be easily differentiated from the precinct building objects that are rendered in white (shown below).

[Click to Enlarge]

[Click to Enlarge]

Clicking the Visualise (camera) icon allows users to select from two different visualisation options. Selecting the Extrude Non-Develop option will only render footprints on non-developable lots to provide context for the existing built form as users go about designing their precincts. Note that unlike precinct object footprints and lots, individual building footprints cannot be selected or edited. The building footprints layer is purely for context visualisation.

Creating New Typologies

Starting a New Typology

At any point in time during the precinct design process, users can click on the + icon in the Typologies panel on the left to submit a new typology to the list/library. A user will encounter the Typology Creation Form allowing a name, description and land use class to be specified for the new typology. Once a land use class has been selected from the list, the form will expand to show the class-specific fields that need to be populated to define the new typology.

Spatial Data for Typologies

Building footprints

At a minimum, users are required to provide a 2D building footprint to represent any precinct typology that is not of the Open Space or Pathway class. As such, if this is not provided then the form will not allow a user to save their new typology and submit it to the library. Most GIS applications support the drawing and creation of 2D data that can be used to create typology footprint data for uploading to ESP. The software used in preparing the library for the template projects was MapInfo. When creating a typology footprint to import into ESP, the following points must be kept in mind:

  • Footprints must be drawn to scale, so use a projected coordinate system when drawing them or make sure your measurements are metric.
  • The front door/entry of the building is assumed to be south facing.
  • The location of the drawn footprint can be anywhere in the world. The coordinates of the receiving lot replace the coordinates of the footprint when the typology is placed in a precinct.
  • Footprints must be saved as Shapefiles in the EPSG 4326 coordinate referencing system.
  • All files associated with the Shapefile must be zipped together and given the “.zip” extension. Do not zip a folder containing the files (i.e. zip the files together directly), otherwise will the file will not upload.
  • Try to adopt a consistent naming convention. For the default building library the following convention for residential typologies was chosen: [state]_[climate zone]_[subclass]_[storeys]_[bedrooms]_[type]. The chosen convention applied to a single storey 3 bedroom single house in Western Australia looks like this: WA_CZ13_SH_1St_3Bed_Basic.
  • To upload a zipped Shapefile, simply click the “Choose File” button under the 2D Geometry heading in the Typology Creation Form and navigate to the desired file.

3D meshes

When creating a new typology in ESP, users can optionally include a 3D mesh of their typology for more detailed visualisation in the system. When creating a 3D mesh for import into ESP, the following points must be kept in mind

  • Any 3D drawing software suite can be used, however the final file must be saved as a COLLADA file (i.e. the “.dae” extension). Google SketchUp is an option that is effective for this purpose and can be downloaded for free.
  • Meshes must be drawn to scale and ideally have a footprint that is identical to the 2D footprint supplied along with the mesh. ESP does not have validation to ensure that the mesh and footprint match.
  • As with the building footprint, the front of the building is assumed to be south facing.
  • Colours and textures may be added to the mesh for styling.
  • The number of vertices does not matter; however, note that simpler meshes (fewer vertices) will render more quickly and easily in the system and allow more objects to be visualised simultaneously. This will be more of an issue with larger precincts containing several hundred or thousand objects.
  • Once a COLLADA file is prepared representing the typology, users must create a KMZ file that includes the COLLADA file before uploading it to ESP. A KMZ file is a zipped file given the “.kmz” extension that contains a “doc.kml” file and a “mesh” folder containing the COLLADA file. Just ensure that the name of the mesh file (indicated in bold in the example KML) is replaced with the appropriate name chosen for the typology. The coordinates of the mesh are inconsequential as ESP translates them when the typology is eventually placed in the precinct.
  • When naming the mesh, user the same name as applied to the typology footprint.
  • The “doc.kml” file and the “mesh” folder containing the COLLADA file should be zipped together directly and not put in another folder first. Once the KML and the “mesh” folder have been zipped together, the resulting file should be renamed with the appropriate name for the typology and given the “.kmz” extension (i.e. not the “.zip” extension).

Note: Users can test whether their building model/mesh renders properly in Google Earth before importing it into ESP. If it renders in Google Earth, it should render in ESP.

To upload a KMZ file containing the building mesh, simply click the “Choose File” button under the 3D Geometry heading in the Typology Creation Form and navigate to the desired file.

Residential Typologies

The Residential typology class is the only class in ESP that expects its typologies to be partially assessed using third party software. The assessment software used when preparing the default residential typology library was AccuRate Sustainability, a fully featured software package developed by CSIRO for rating the energy efficiency of residential building designs. AccuRate was used as it provides the standard for the Nationwide Housing Energy Rating Schema (NatHERS) in Australia.

While the Residential Typology Creation Form expects inputs that are outputs from an AccuRate assessment summary report, users are free to provide values derived from other sources. One benefit of using AccuRate, however, is that assessments can be done for various azimuth rotations of a building to test how aspect and ventilation impact heating and cooling energy demand. For the default library, assessments were carried out for all 45 degree rotations from 0 to 360 degrees, allowing heating and cooling energy demand values to change as buildings are rotated on a site.

While some attributes of a property’s performance can be assessed on the basis of the building typology itself, other property attributes cannot be determined until the size of the parent lot is known. As such, ESP models several residential typology attributes pertaining to external land internally by making use of default coefficients that can be overridden by users. ESP also models some building performance attributes internally by giving users control over heating and cooling appliance efficiency, the energy derived from PVs, stove and oven type, appliance fit-out, capital and operating costs, and parking.

Most of the Residential Typology Creation Form’s fields are self-explanatory; however, a few could use some further explanation. This information can be found below:

  • Gross Floor Area (GFA) vs. Conditioned Floor Area (CFA): For the Residential class, ESP uses GFA in the calculation of planning metrics like plot ratio. CFA only accounts for the spaces in a residence that are heated and cooled. As such, usually the garage and laundry areas are omitted from a CFA calculation. CFA is used to calculate heating and cooling energy demands in ESP when the user provides heating and cooling energy arrays
  • Proportion Extra Land: As the size of a property’s lot, and hence its extra land, is unknown until a building typology is placed on a lot, these proportions are used to determine the amount of external land allocated to various surface types. These proportions impact things like stormwater, landscaping costs, external embodied carbon, irrigation demand, and non-garage parking on the lot. Users may wish to increase the proportion allocated to impermeable surfaces if the residential subclass is walkup or apartment and the majority of parking is expected to ground-level and on the property.
  • Orientation: The default orientation of a building in ESP is 0 degrees with the front of a building being south facing. This is how a residential typology should be assessed in AccuRate and drawn. If this value is not overridden then a building placed in a precinct will auto-orientate itself to be street facing. If the azimuth is overridden then a building will always initially render with the provided orientation.
  • Heating and Cooling Energy Arrays: Use of these arrays is optional. If users wish to use the per square metre heating and cooling values from an AccuRate assessment then they can be provided here and rotating a building will consequently impact its heating and cooling energy requirements. Inputting values for these arrays will hide the Heating and Cooling fields in the form. If even a single value of an array is left blank, the system will expect a Heating or Cooling value to be provided instead. This was done to make the system amenable to being used by users without access to the AccuRate software. IfHeating and Cooling values are provided instead, rotating a building will have no effect on its heating and cooling calculations. Note, these values represent the thermal heating and cooling energy requirements for space conditioning, not the energy required to operate the heating and cooling appliances that are calculated internally using the COP and EER values.
  • PV System Size: ESP models the effects of PV systems on buildings internally by allowing users to select the PV system size (default is 0 kW). As such, PVs should be excluded from AccuRate assessments. Users can change the default PV system size from 0 to any value they wish for modelling purposes.
  • Water Demand: Once users have provided a water use intensity value (kL/occupant/year) for the typology they are creating, they have the option to add a rainwater capture system and greywater recycling system. Rainwater supply, if checked, is calculated based on average annual rainfall, roof area and a rainwater capture efficiency value, while grey water supply is calculated based on a percentage of internal water use that is being expelled as greywater. It is assumed that rainwater can be used internally and externally while greywater is only used externally.
  • Building Type and Cost: Users who know the construction cost of their typology are free to provide this value directly into the form. In most cases, however, it is expected that construction cost will be unknown so users are given the option of selecting a build quality type from the dropdown menu and a cost will be calculated internally based on GFA and the typology subclass.
  • Underground Parking: Specifying the number of underground parking spaces has three outcomes. First, it adds to the number of parking spaces available. Second, it factors the construction of these underground bays into the construction cost calculations. Third, it adds the embodied carbon of the parking space to the embodied carbon calculations.
  • Parking Land Ratio: This ratio specifies how much of the impermeable extra land surfaces are available for parking


Commercial and Institutional Typologies

Unlike the Residential typology class, the Commercial and Institutional class typologies are assessed entirely within ESP using default parameters that can be overridden by the user. The reason for this is that AccuRate is only for residential buildings. While the level of detail behind the commercial and institutional assessments is not as great as in the residential class, which is the focus of ESP and middle suburb redevelopment, the benefit of this simpler assessment model is that it is much faster to prepare new commercial or institutional typologies and no other software is required. Also, the parameters used for the assessment calculations can be found with relative ease by scanning widely available reports, journal articles and papers.

Once either the Commercial or Institutional class has been selected in the Typology Creation Form, many of the fields that render will look similar to those in the Residential class form. One new field, however, is the Job Intensity field that contains a parameter used for calculating the number of jobs that will be generated by the building. Users will also see electricity use, gas use and internal embodied carbon intensity fields replacing the direct input fields in the Residential class form. These parameters are used to calculate electricity use, gas use and internal embodied carbon respectively when multiplied by the building’s GFA. When a user selects a subclass from the dropdown menu then default values will automatically be populated for the subclass specified. This means that once an appropriate subclass is selected, all users have to do is provide the geometry data for the typology and their new commercial or institutional typology is nearly complete. The final field to consider is the Build Type field in the Financial section of the form that will automatically filter down once a subclass is selected, allowing subsets of that typology subclass to automatically be costed or users to specify their own costing if the Custom option is selected.

Users should note that the default Proportion Extra Land parameter values differ from those in the Residential section. This is because it is typical of commercial and institutional buildings that the majority of extra land is impermeable and allocated to street-level parking. The amount of impermeable extra land available for parking can be adjusted by changing the Parking Land Ratio parameter as with the Residential class.

Mixed Use Typologies

The Typology Creation Form for the Mixed Use class is somewhat of a hybrid between the forms for the Residential class and the Commercial and Institutional classes. Like the Commercial and Institutional classes, assessment is carried out entirely within ESP but a few extra fields are present to account for the residential component. These include fields reporting the number of dwellings of varying bedroom numbers and the number of occupants expected to be housed. Also, since it can be expected that electricity use, gas use, and water use intensities will differ between residential and commercial spaces, separate intensity fields exist for the two components and well as separate fields for reporting GFA.

Open Space Typologies

The Open Space class is the simplest of all of ESP’s typology classes to define new typologies for. There is no 2D footprint or 3D mesh to upload for this typology class. Instead a textured pattern will render on a lot once a typology of this class is placed in a precinct. An open space typology is essentially defined the same as extra land for typologies that have buildings associated with them. Users simply provide the proportion of land allocated to each of the four surface types: lawn, annual plants, hardy plants and impermeable surfaces. Note that edible plants will fall under the category of “annual plants”, however food production is not calculated in ESP due to the extreme variability of this reporting metric that depends on rainfall, soil conditions, and more.

Pathway Typologies

The Pathway typology class can be deemed the most different of all the classes in the way that a new typology is defined. A pathway can be anything from an eight-lane freeway to a simple pedestrian footpath that meanders through a subdivision. Users define a new typology of this class by specifying the number of lanes and the width of each lane for each of the cross-sectional elements. The cross-sectional elements available for users to choose from include the following: road lanes, parking lanes, footpath lanes, bicycle lanes, and verges. For each cross-sectional element, users are also able to specify a construction profile that is used to determine the construction cost and embodied carbon of the pathway being defined.

As with the Open Space class, no 2D or 3D geometry data needs to be uploaded when creating a new typology of this class. ESP handles the geometry creation of a pathway object when users draw it into a precinct. The number of lanes and width of each lane of each cross-sectional element as defined in the typology determine the width of a pathway being drawn, while a pathway’s length is determined as user draws it into a precinct. Once a pathway is drawn, its length is used internally in ESP to calculate the area of each surface type as well as a variety of other reporting attributes like stormwater runoff and embodied carbon.

Designing a Precinct

Amalgamating Lots

To amalgamate lots in ESP, a user simply needs to hold down the Shift key while clicking on adjacent (touching) lots to select them and then click on the Amalgamate (converging arrows) icon in the Lots panel to amalgamate them. This icon only appears when more than one lot is selected. There is no need for the land uses of the lots to be the same as ESP will allocate the land use of the first lot clicked to the destination lot being created. Amalgamation will only occur for lots that are adjacent (touching).

Subdividing Lots

When one or more lots have been selected in ESP, the Subdivide (diverging arrows) icon will appear in the Lots panel. Toggling this icon will begin a drawing session where users can begin drawing a line that will be used to split the selected lots. When a user has finished drawing the line intended for subdivision, clicking the Subdivide icon will end the drawing session, remove the line and split the intersecting selected lots. Alternatively, double-clicking anywhere on the globe will complete the line and subdivision while keeping the drawing mode active. Note that after the vertex of a line is place it can be moved by clicking and dragging the yellow handle. This is useful for fine-tuning the position of the subdivision line.

Placing Precinct Objects

Placing objects via the lot form

One way of placing a building or Open Space object on a lot is by double-clicking a lot to open up the Lot Edit form. If the “For Development” checkbox is selected a dropdown menu will be present allowing users to select from a list of typologies in the library that correspond with the lot’s land use class. Clicking the “Save” button at the bottom of the form will commit the object to the lot. If the object is a building it will be auto-aligned such that the front of the building will be street facing. Note that if the building is too large to fit the lot then the Lot form will not allow the user to save. Open Space typologies can be placed on any lot zoned with the Open Space class and will automatically take up the entire area of the lot.

Pacing objects via drag-and-drop

An alternative to placing a precinct object via the Lot form is to click and drag the typology from the Typology Library onto the desired lot. Note that if the typology’s and lot’s classes do match that the object will not be added to the lot. Also, the object will not be added if it is a building and too large to fit on the lot. Open Space typologies can be placed on any lot zoned with the Open Space class and will automatically take up the entire area of the lot.

Drawing pathways

Pathways are the only typology not requiring a lot boundary to be present in the precinct in order to add them as precinct objects; instead, they are simply drawn into the precinct where desired.

To add a pathway object to the precinct, first select a pathway typology from the Typology Library and notice that the Pathway (road) icon will appear in the Typologies panel toolbar. Toggling this icon on will start a drawing session where the user can begin clicking on the globe to place the vertices of the linestring representing the road. Clicking the icon again to toggle it off will complete the linestring and render the pathway with its appropriate width. Alternatively, double-clicking anywhere on the globe will also complete the pathway but keep the drawing session active if the user wishes to draw another pathway of the same type. Note that double-clicking does not add another vertex, so the pathway should be drawn as desired first.

In many cases the width of the pathway may be too narrow or too width for the space available between lots. The consequence of a pathway being too narrow is that gaps will be present that will not contribute to the assessment of the precinct while a consequence of it being too wide is that some land will be double-counted. Users can make fine adjustments to a pathway after double-clicking the pathway object and changing the width of any of the cross-sectional elements using the Object Form that will appear in the left panel. As there may not be too much flexibility when specifying road or footpath widths due to design code requirements, adjusting the verge width will typically be the most suitable way of widening or narrowing a pathway object.

Rotating and Auto-Aligning Buildings

When building objects are initially added to a precinct, ESP runs an algorithm to automatically detect which side of the lot is street-facing and automatically aligns the building accordingly. For residential typologies, this impacts the heating and cooling energy demand calculations while for building objects of other land use classes the change is merely one of appearance. Users can, however, customise the rotation of a building object by double-clicking it to open up its Object Form in the left panel, scroll down to the Orientation section, and change the azimuth of the object to whatever angle is desired. Note that the default/reference point of the building (0 degrees) will be the front door, which is assume to be south-facing. Objects are rotated clockwise from this reference point when degrees are added to the azimuth. At any time users can re-run the auto-align algorithm for a building object by selecting it’s lot and clicking on the Rotate icon. This process can be executed for multiple building objects by holding down the “Shift” key and clicking on multiple lots.

Removing objects

Removing objects from a precinct in ESP can be done in several ways. Perhaps the easiest and most intuitive way is to click on the precinct object to select it and then click on the X icon in the Objects panel on the left. Similarly, users can select the object from the list in the Objects panel and then click the icon to delete it rather than selecting it on the globe. Selecting an object from the list in the Object panel, however, will select the object on the globe and vice versa.

Another option for removing an object from a precinct is to double-click the parent lot to open up the Lot Form on the left, select the None typology option from the Typologies dropdown menu or unchecking the For Development checkbox, and then clicking the Save button at the bottom of the form.

Auto-Allocation of Typologies to Lots

As dragging and dropping typologies onto lots or applying typologies via the Lot form may be onerous in circumstances where users wish to populate a large number of lots with the same typology, ESP includes an auto-allocation function to expedite the process. The first step when auto-allocating typologies to lots is to select the destination lots to be affected by the Auto-Allocation tool. Selection of multiple lots can be done either manually or by using the Filter Lot Selection tool. With the appropriate lots selected, users can then click on the Auto-Allocate (wand) icon in the Lot panel to open the Auto-Allocation tool’s menu. Users will see a list of all the typologies present in the Typology Library, from which they will be able to select one to auto-allocate to all the selected lots. In addition to selecting a typology, users are also able to select whether running the tool should replace a precinct object if a selected lot has already been populated and whether to allow auto-allocation of typologies to non-developable lots. Selecting the Allow non-developable checkbox will first convert the lot to “developable” before allocating the typology.

Note that the same validation when dragging and dropping typologies occurs when using the Auto-Allocation tool. A typology will only be allocated to a lot of the same land use class and only if it will fit inside.

Visualisation Options of Building Objects

ESP allows users to visualise building objects in three ways: 2D footprint, 3D extrusion, and 3D mesh. To change how building objects are visualised in a precinct, simply click the Visualise (camera) icon in the Objects panel and select a different visualisation setting.

Changing Typology Parameters for Scenario Modelling

Once typologies have been created in ESP or placed in a precinct, opportunities still exist to tweak their characteristics for modelling purposes. At any point in time, the Edit (pencil) icon can be clicked in the Typology Library to open up a selected typology’s details form. This is the same form that users see when created a new typology. Any changes to these values will filter down to all precinct objects that were created from said typology, as long as the changed values have not been overwritten at the precinct object level. To open this form, a typology in the library can also be double-clicked.

Users should also be aware that it is possible to double-click a precinct object and see the Object Form render in the left panel. This form contains a subset of the fields available in the typology creation form, allowing users to only edit and overwrite values that do not fundamentally change how the typology is defined. For instance, users can add PVs to a precinct object but not change the number of storeys, as the former can be considered and add-on to the object and the latter would fundamentally change its structure and form. Users must keep in mind that overwriting values in this form decouple the particular field from the typology the object inherits from. This enables precincts to be further customised by allowing two objects inheriting from the same typology to have different properties. Note that clicking the Edit (pencil) icon next to the typology name in the precinct object form will open up the Typology Form for that precinct object, enabling users to make changes that will affect all objects of that typology.

Generating Reports

As users go about designing their precinct by adding or creating lots and placing objects from the Typology Library, the reports on the right side of the screen will be automatically updated. Users can change the report being viewed by using the dropdown menu. There exists a detailed report for every land use class, plus a Transport Report and a Precinct Report. The Transport Report will be explained in greater detail in Section 12. The Precinct Report is a simplified report that aggregates values from all land use classes. It presents some of the more salient metrics that can be used to summarise a precinct’s performance while being general enough such that most metrics apply to most of the land use classes.

If users wish to only receive reports on a subset of precinct objects, this can be achieved by holding down the “Shift” key and clicking on the objects desired to be included in the reports. Note that when selecting one or more objects from the same land use class only the report for that class and the Precinct report will be available. If the subset of precinct objects selected belong to more than one land use class then the only report available for viewing will be the Precinct Report.

As the number and type of reporting metrics for urban development can be seemingly endless, the intention when designing the ESP reports was to make them detailed enough to allow users to use the returned values to construct their own indicators if desired. For instance, if users wish to calculate the area of open space per resident or per household, this can be done by dividing the Total Lot Area in the Open Space Report by the number of residents or dwellings reported in the Residential Report.

ESP allows users to download a CSV file of any report by clicking on the Export icon at the top of the report panel. This enables users to carry out their own analyses or make their own charts for their own personal reports if they desire.

Using the Transport Model

The transport model in ESP is almost entirely manipulated and influenced by the parameters at the bottom of the precinct (global) parameters list (see the above image). This list can be accessed by selecting a project from the Projects Screen and clicking the Edit (pencil) icon, or by clicking the Edit (pencil) icon in the top right of the Project Design Screen. Apart from using these parameters for modelling the outputs presented in the Transport Report, ESP also uses the number of dwellings placed in a precinct to determine the total annual precinct vehicle kilometres travelled (VKT), the total annual precinct transport-related greenhouse gas (GHG) emissions, and the total annual number of trips made by travel mode.

It is important for users to be aware that to get the best and most reliable results from the transport model, the transport model parameters must be adjusted to best reflect the context of the precinct being design. If the precinct covers a very large area then assume average values for the parameters. The VKT and mode split models were estimated using 2009 travel survey data for the Melbourne metropolitan area and the parameters appearing as defaults in the parameters list are average values taken from the dataset. More information is given on the parameters when the user hovers over them with their mouse cursor. Note that all distance parameters are using road network distance and not Euclidean distance, while the land use mix (LUM) and residential density indicators are calculated for a 1600 metre road network catchment around a household. This means that if the user’s precinct is smaller than what would be included in a 1600m walking catchment then areas outside of the precinct should be considered when populating the LUM and residential density parameters for the transport model.

Lastly, it is also important to note that the transport model uses the average number of residents per household specified in the transport parameters list and not the average number of residents per household as calculated for the precinct being designed. Users can adjust this transport parameter to match what is being achieved by the precinct design, but the two were decoupled to allow for more flexible transport scenario modelling without having switch out and delete residential building objects to test different transport scenarios.

Using the Cogeneration/Trigeneration Models

[Click to Enlarge]

[Click to Enlarge]

The cogen/trigen model in ESP allows users to freely set the specifications of the district energy system and separately have full control over which typologies and precinct objects are connected to the system and for what end uses. Put very simply, users have full control over the supply and demand of a cogen/trigen system’s energy services in ESP.

The cogen/trigen system’s specifications, and hence supply of energy, are determine by parameters in the Precinct Properties Form that can be accessed from the Projects Screen by clicking the “Edit” icon in the toolbar or from the Project Design Screen by clicking the “Edit” icon in the top right corner. The parameters allow users to specify the system size, the system efficiency, the operating schedule and whether the system is in fact a cogeneration system or a trigeneration system by specifying the proportion of primary thermal heat recaptured to be converted to hot thermal versus cold thermal. The impacts of changing these parameter values can be observed by referring to the cogen/trigen report in the Reports panel on the right of the Project Design Screen.

When connecting a typology to the cogen/trigen system, users have full control over which end uses connect to the system and the share of the typology’s electricity requirements to be sourced from the grid versus the cogen system. Users can connect to a cogen/trigen energy system by selecting the “Cogen/Trigen” energy source option for space heating, space cooling and hot water heating, and by specifying the mix of scheme versus cogen/trigen electricity in the Typology Form that can be access from the Project Design Screen. When the “Cogen/Trigen” option is selected, the COP field for the respective energy use category is hidden because it longer applies. A typology’s electricity mix can be adjusted by changing the value in the “Proportion Electricity – Scheme vs. Cogen” field, where values should range between 0 (100% cogen/trigen) and 1(100% grid) and the default is 1 for 100% grid energy. Note that it is possible to set the energy sources for space heating, space cooling and hot water heating to “Electricity” and then make the typology source all of its electricity from the cogen/trigen system, but this is not a conventional way of making use of a cogen/trigen system as the potential efficiency gains of capturing the primary thermal energy from the system are lost.

Connecting a typology to a cogen/trigen system automatically updates the fields in the “Energy Demand” category of the Cogen/Trigen Report. The report also shows the balance of energy supplied by the district energy system after the demand for energy is subtracted from the system’s supply, allowing users to change the size and operating settings of the system to suit the precinct’s needs. If an oversized system is specified (i.e. supply is set to exceed demand) in order to export energy from the precinct, the precinct objects will only be assessed on the basis of the energy they are using. Also, setting the system too small for the precinct so that it does not generate enough energy to meet demand will not impact the energy available to the precinct objects. If a precinct object is connected to the cogen system it is assumed that the energy is available. As such, editing the cogen/trigen system parameters is completely optional.

Finally, users should be aware that in the current version of ESP, only residential typologies can connect to a cogen/trigen system due to limitations of the Mixed Use, Commercial and Institutional typology schemas.

Example Use Case

In this section, a use case is provided demonstrating how a potential end user might approach a new project or scenario using ESP. In this example use case, two possible redevelopment scenarios for an existing residential precinct are examined: one that looks at a business as usual (BAU) approach to redevelopment with a focus on grouped dwellings, and another that is less conventional by considering opportunities for lot amalgamation and multi-unit housing. Before these two scenarios are discussed, however, a third scenario representing present day or “base case” development patterns is prepared for comparison with the two future growth alternatives.

For brevity and simplicity, the use case focuses on residential and open space typologies, and does not involve adding pathway, commercial, institutional or mixed use building objects to the precinct. Additionally, the use case assumes that the user has access to template projects with pre-loaded housing typologies. Also note the use case only demonstrates some of ESPs functionality, as demonstrating every feature or function would make it too lengthy and difficult to follow. Some discussion, however, is given regarding other options or alternatives an end user may choose to take.

Setting up the Project

The first step in setting up a project involves duplicating a project template and renaming it. The name “User Manual Use Case” was attributed to this project. With this done, the project is launched and an Envision dataset is loaded into the project.

[Click to Enlarge]

[Click to Enlarge]

After the precinct file has finished importing, an accompanying building footprint dataset is also imported. The purpose of this dataset is to provide some context for the existing built environment when designing a new precinct.

[Click to Enlarge]

[Click to Enlarge]

The land parcels that are being considered for redevelopment are those in the centre of the precinct file. The precinct file was intentionally cut larger than necessary to provide the surrounding context for the precinct being designed. The centre lots are selected and a bulk edit is performed to make them all developable. This automatically hides the building footprints on these lots because the Extrude Non-Develop view option has been selected, as opposed to the Extrude All option.

[Click to Enlarge]

[Click to Enlarge]

Setting Up the Base Case Scenario

The Filter Lot Selection tool is used to quickly select all the developable lots, followed by the Auto-Allocation tool to add single storey 3 bedroom attached houses to all of the lots. This typology seems to accurately resemble the type of residential development that currently exists on the redevelopment site. The Residential Report is selected from the Reports panel and subsequently downloaded for comparison with the BAU and Regenerative scenarios that will follow.

[Click to Enlarge]

[Click to Enlarge]

Setting Up the Business as Usual (BAU) Scenario

To generate the BAU redevelopment scenario, the Filter Lot Selection tool is used once again to quickly select all of the developable lots. This is followed by use of the Auto-Allocate tool with the “Replace” option selected and a grouped dwelling typology chosen. This applies the grouped dwelling typology to all of the developable lots while replacing the single house typologies currently in place. The Residential Report for this scenario is downloaded for comparison with the Base Case and Regenerative scenarios.

[Click to Enlarge]

[Click to Enlarge]

Setting Up the Regenerative Scenario

In order to quickly select all of the grouped dwellings placed in the precinct, the grouped dwelling typology is selected in the Typology Library (selection in the library is linked to selection on the globe). In the Objects panel, the “Remove” icon is clicked to delete the grouped dwelling objects from the precinct. The end lots are then amalgamated and rezoned as open space. Groupings of the inner residential lots are amalgamated as well to allow for larger, attached and multi unit typologies to be placed in the precinct. A couple lots are left with their original boundaries for the placement of duplexes.

[Click to Enlarge]

[Click to Enlarge]

On the two largest residential amalgamated lots, 5 storey apartment buildings with a mix of one and two bedroom units are placed using the drag-and-drop approach. The three remaining amalgamated residential lots receive the 2 storey 2 bedroom attached house 6-plex typology and the two non-amalgamated lots receive 2 storey 3 bedroom duplexes. A community garden typology is then created and added to one of the open space lots, and a park typology is created and added to the other open space lot. The Residential Report for this scenario is downloaded as well for comparison with the Base Case and BAU scenarios.

[Click to Enlarge]

[Click to Enlarge]

Finally, before comparing the reports the “Mesh” view option for the precinct objects is selected and a screenshot is taken of the scenario for future reference.

[Click to Enlarge]

[Click to Enlarge]

Comparing the Scenarios

ESP is capable of modelling a wide variety of precinct performance metrics and as such a complete discussion of this simple example project is beyond the scope of this use case. A brief summary of the findings of the 3 scenarios, however, is provided below.

The Base Case scenario had 20 dwellings and achieved a dwelling density of 14.4 dwellings per net hectare. It had 9,300 square metres of extra land, but 40% of this area was allocated to impermeable surfaces. The precinct did not contain any open space to provide local amenity. The BAU scenario doubled the number of dwellings and density but at a loss of 8,900 square metres of extra land. The smaller dwellings, however, meant that heating energy demand only increased by 12% and cooling energy demand actually was reduced by 16%. The regenerative scenario produced a total of 102 dwellings and a density of nearly 89 dwellings per net hectare while adding over 4,000 square metres of open space in the form of a park and community garden. Despite having over 150% more dwellings than the BAU scenario, heating energy demand is nearly 17% less and cooling energy demand is only 96% more.

In addition to the simple modelling steps taken in this example use case, basic typologies could have been replaced with more efficient versions (i.e. better building envelop performance and increased water appliance and fixture efficiency) and several modifications on the typologies could have been made. Some of the potential modifications include improved heating and cooling appliance energy efficiency, a change in stove and oven type, more efficient household appliances, and the addition of rainwater capture or greywater recycling systems. If changes to the transit system were part of the precinct plan then transport metrics could have been modelled and examined as well. For larger precincts, a greater mix of land uses could have been included in the designs by zoning and placing precinct objects representing mixed use development, shops, restaurants, grocery stores, schools, hospitals and more.


KML File Template

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no” ?>

<kml xmlns=”http://www.opengis.net/kml/2.2″ xmlns:gx=”http://www.google.com/kml/ext/2.2″>




<description>Created with &lt;a href=”http://sketchup.com”&gt;SketchUp&lt;/a&gt;</description>













<name>Scene 1</name>















<Style id=”default”/>

























  • Cannot see any available project templates?
  • Access to a particular project template has to be granted to a user by an ESP system administrator. Please contact one for more information. In some cases, customised templates can be made available to you.
  • Cannot upload/import an Envision zipfile?
  • Make sure that you have already extracted and are attempting to upload the precinct (lot boundary) zipfile from the combined zipfile.
  • Cannot save a typology?
  • Make sure that all required (*) fields have been completed.
  • Make sure at least a 2D building footprint has been uploaded in the case of a building typology.
  • Cannot upload a Footprint or Mesh file?
  • Make sure that the file extension is correct: *.zip for footprints and *.kmz for meshes. Note that the extensions are case sensitive.