This snapshot taken on 10/10/2009, shows web content selected for preservation by The National Archives. External links, forms and search boxes may not work in archived websites.

Technical Appendix 4 - Accessibility Planning Software Tool Functionality

Accessibility planning software tool functionality work specification

Key Requirements for the Software tool:

  1. In the following appendix, details will be outlined of the functionality that was required from the software tool.
  2. It is envisaged that the software tool will be utilised by transport planners and others with varying levels of expertise in accessibility modelling and transport planning. Consequently the software tool must cater for these varying levels of skills and abilities.
  3. (M) 1 The nomenclature associated with the software tool must be simple, with clear explanations of any potentially confusing terms incorporated within the user/guide manual.
  4. (D) It is preferable if toolbar icons display textual information on the functionality on screen as the mouse cursor is placed over the icon. In the case of menu items it is desirable if additional textual information is provided in the status bar located at the bottom of the window.
  5. (M) All public transport information related to scheduled public transport services must be stored within a relational database management system. This requirement arises out of a need to maximise the range of sources of public transport data, which can be utilised with the software tool. In utilising scheduled timetable data supplied in ATCO CIF and TransXChange format, bidders are reminded that users will be required to import a complete week (seven contiguous days, commencing with a Monday) snapshot of data. In order to achieve this, users must be provided with the functionality to identify and specify an appropriate seven day period, which is consistent with the underlying public transport data (avoiding significant service changes or other exceptional circumstances so far as is possible).
  6. (M) The software tool must allow public transport data (and accessibility results) to be stored within an MS Access 97/2000/XP database or an alternative commonly available integrated database.
  7. (M) The software tool must possess the functionality to support the importation of public transport data into the underlying relational database from local or regional databases employing the following data formats:
  • i. National Public Transport Access Nodes Database (NaPTAN) http://www.traveline.org.uk/naptan ;
  • ii. TransXChange http://www.transxchange.dft.gov.uk . Bidders are reminded that the TransXChange specification is subject to periodic change and that not all TransXChange data is relevant to the process of accessibility planning;
  • iii. ATCO Common Interchange File (ATCO CIF version 5.0) http://www.users.global net.c o.uk/~jplanner/atco/cif/ATCO510.DOC. Bidders are reminded that there are several flavours of ATCO CIF version 5 in use by public transport data suppliers around the country; These include:
    • standard (aforementioned link)
    • with proprietary "AIM" extensions
    • with local modifications

Modes of Travel:

  1. (M) The software tool must enable multi-modal accessibility assessments to be undertaken by any combination of the following modes of transport:
  • i. cycle
  • ii. all forms of public transport (bus, train, metro, tram) (in addition to the use of scheduled public transport services, the accessibility planning software tool must be capable of being applied to demand responsive and flexible routed and timed services, school and social service transport and other forms of service-specific transport)
  • iii. walk
  • iv. car
  1. (M) The bidder must disclose the name of the routing algorithm(s) to be incorporated within the software tool. The bidder is advised that the selected routing algorithm must facilitate multi-modal journeys by a selection of any combination/permutation of the four transport modes highlighted above. The routing algorithm must allow for the use of both a segmented and a full public transport timetable. In particular the routing algorithm must be capable of facilitating multi-criteria based shortest path routing incorporating turning restrictions and penalties. In addition the algorithm must be capable of identifying time dependent shortest paths using a continuous clock time used in conjunction with a full public transport timetable. The algorithm must be efficient in terms of memory usage and processing time and must be capable of identifying the shortest path through a public transport network with 60,000 access points and a OS ITN walk, cycle, highway networks encompassing the full extent of a large PTE/county and at least the relevant parts of its adjoining local authorities. The ability to efficiently process an origin/destination grid containing 240,000 points must be incorporated within the software tool.
  2. (M) In the case of walk access/egress to/from the public transport network the user must be provided with the functionality to undertake journey time, distance or cost assessments using estimates based on the factoring of straight line distances as opposed to the use of vector data such as OS ITN where ITN or equivalent cycle, walk and highway vector data is not readily available.

Type of Accessibility:

  1. (M) The software tool must enable users to choose between accessibility assessments undertaken using each of the following:
  • i. local accessibility (access to/from the public transport network defined in terms of journey time/distance to/from an access point with user defined service frequencies for different user defined time periods and days of the week, e.g. Mon-Fri, Sat, Sun) including for example but not limited to a number of potential indicators outlined in Annex A of the SEU final report on transport and social exclusion (main report). In addition the PTALs Plus index should be incorporated within the software tool.
  • ii.. network accessibility (access through the transport network to a particular service in terms of journey time, distance, cost or generalised cost, for different time periods and days of the week)
  • iii. composite accessibility (combining destination attractiveness such as the number of jobs, retail floor space and journey disutility e.g. gravity/Hansen measures)
  • iv. simple time constrained accessibility analysis. Functionality must be provided for users to be able to assess whether travellers, in particular public transport users, and users of service-specific transport, can get to a hospital or GP appointment or get to school or work by a specified time. In addition functionality must be provided for the users to undertake simple assessments of trip tours i.e. given a certain departure time and a given stay duration at an activity location, how long will it take for the traveller to travel back to the start point of the tour (e.g. home-hospital-home).

Opening Data Files:

  1. (M) The software tool must allow users to open a range of spatially based point, line and region datasets (referenced to the OS grid) created by the major GIS software tools in use within the UK. The range of datasets that may be used within the software tool may include transport networks, crime levels/rates, locations of street lighting and the type of lighting, pedestrian/pelican crossings, wheelchair accessible locations, locations of personal injury accidents, deprivation indicators, census output areas and related statistics etc.
  2. (M) The software tool must allow the facility for non-spatially referenced point datasets with a seven digit OS grid reference to be geocoded and thus spatially visible within the map window. If this point data only contains a postcode then it is not expected that the software tool be capable of geo-referencing such data. However if the user has spatially based point or region data associated with the postcodes in use within their region then it is expected that the software tool must facilitate the use of this data in undertaking the geo-coding process (e.g. geo-code data x using spatially referenced data y).
  3. (M) The software tool must provide the user with the ability to open, create, close, save and change the name of a transport network. It should be noted that this functionality is distinct from that associated with being able to open a range of spatially referenced point, line and region datasets outlined in paragraph 12.
  4. (M) The software tool must allow the user the ability to define the name of the results and contour files as outlined in paragraph 44.
  5. (M) The functionality must exist for the user to open, create, close, save and change the names of origins, destinations, results and workspace files.
  6. (M) The software tool must ensure consistency of location of transport networks, databases, origins, destinations, results, contour, meta data and workspace/project files are located in a fixed location, which can be defined by the user at the point of installing the software tool. This information is to be located within the software tool initialisation file and associated accessibility meta data file.

Public Transport:

  1. (M) The user must be provided with the functionality to create, move, view (zoom in), delete suspend or unsuspend an access point. The functionality must be provided to allocate all access points a unique identifier, an OSGR easting and northing, a name, place, location, locality, a transport mode(s) a facility type classification, user defined which can be used as a selection criterion in undertaking assessments (e.g. wheel chair accessible, real time information, seating/shelter, lighting etc). Auditing functionality will need to be allocated to ensure that each newly defined access point identifier is unique and that the access point is not located on top or within a defined distance (1m) of another access point. This applies equally to access point information associated with public transport data imported into an accessibility network.
  2. (M) The functionality must be provided for the user to define the type of vehicle used for a particular scheduled bus journey and demand responsive bus journey and non-scheduled bus journey (e.g. bus conforming to the Disabled Discrimination Act (DDA), bus allowing wheel chair access, bus with kneeling suspension, etc). The functionality must be provided for the user to define, add to and select particular vehicle types for use in the accessibility assessment.
  3. (D) It is desirable for the user to be provided with information on the type of facilities available at the public transport access point for the mobility impaired. For bus stops it may include whether stops offer audible information on bus services for the blind or partially sighted, whether light rail, heavy rail or metro stations offer wheelchair access to platforms and if so to which platforms etc. The ability to provide user defined information on a range of other access point facilities is also desirable.
  4. (M) In undertaking a particular accessibility assessment the user must be presented with a list of transport modes, associated vehicle types and access point facilities (scheduled public transport, demand responsive, service-specific transport) which he/she wishes to use for the subsequent accessibility analysis. As an example for public transport wheel chair accessibility assessments the user may select a bus conforming to the DDA and/or a bus allowing wheel chair access and/or railway access points offering full wheel chair access to/from the railway station.
  5. (M) The software tool must provide the functionality for new and existing scheduled public transport services and associated journeys to be allocated a unique operator code, route identifier, route direction and route variant number. Public transport data imported from existing local or regional traveline sources, should already contain such information, however checks must be incorporated within the software tool to ensure that this is in fact the case and that the route identifiers supplied are unique. For demand responsive, flexible routed and service-specific transport the ability to define the operational start point or depot/garage for the service and defined service criteria must be provided. In addition the user is expected to be able to specify a transport mode, vehicle type, route description, route subsidy flag (true/false), day of operation, day of week type (optional), time period (consistent with user defined intervals), departure time or hourly service frequency for the defined time segment. The user is expected to be provided with the functionality to define the public transport service frequency in the principal time segments under consideration (e.g. am, inter, pm and off peak). In addition the user must be able to define the actual start time/departure time of the public transport service from the first access point located on the route as well as the associated day of week and day of week type.
  6. (M) The software tool must provide the functionality for the user to segment a public transport timetable into AM, PM, inter-peak and off-peak periods by different days of the week. In this instance the user must be able to define the extent and coverage of the various time segments associated with the public transport network, after which the software tool proceeds to perform a series of queries to determine the hourly frequency of each public transport service.
  7. (M) The software tool must allow users to create new public transport service routings interactively within the map window for new/improved scheduled services as well as for non-scheduled services not present within existing databases of scheduled services. The software tool must provide the user with the ability to import new routing information directly into the relational database underpinning the system. In defining the routing of the public transport service it is expected that users will be able to click on bus stops, railway stations, metro stations etc in sequence, thereby defining the order of stopping of the public transport service in question. It is expected that the order of access points within a route can be altered by the user entering within the sequence number column a real number/float. For instance 2.1 or 2.5 would change the existing downstream access point sequence number from its existing value of 3 to 4 with the new access point being allocated the sequence number 2 (in effect placing the new access point between the existing access points two and three in the service routing).
  8. (M) The software tool must provide the user with both a map window and table window (suitably tiled to cover the computer window), in which the access point information and the public transport service routing information are visible. Within the map window it will be expected that any of the layers selected by the user will be displayed, with access points comprising the public transport route displayed in a distinct colour with the access point sequence number and the bus stop identifier optionally displayed within the map window.
  9. (M) Within the table browser window the user must be presented with the access point sequence number, access point identifier, access point name, location, locality, cumulative journey time in minutes from the start of the route, cumulative distance from the start of the route and cumulative cost of travel from the start of the route for six user defined user groups must be clearly displayed.
  10. (M) The user must be presented with the functionality to define the journey time, distance or cost(s) at specified points along the route (e.g. times at timing points or fare stages). The user is expected to have the functionality to undertake interpolation on the basis of journey times, distances or costs for non-defined access points. In such cases interpolation will be undertaken on the basis of distance from the last timing point or fare stage (rather than on the basis of the number of intervening access points) and the location of the next defined journey time, cost or distance.
  11. (M) An audit process must be incorporated within the route creation process as well as the public transport data importation process. Here it is expected that checks will be undertaken to ensure that journey times, distances and costs for defined access points sequentially increase as the access point sequence number increases. The access point located at the end of a route must have a defined distance, time and cost(s). The software tool must ensure that the operator code, route identifier, route direction and route variant combinations are unique.
  12. (M) The functionality must be provided for the user to save all route edits as well as copying and allocating new route identifier information to an existing route variant. In addition the user is expected to be able to view, edit, delete, suspend or unsuspend existing scheduled service routings by defining the operator code, route identifier, route direction and route variant of the route in question. In selecting the view, edit, delete or suspend routings options the user is expected to be able to view both the route variant within a tiled map window and the table window.
  13. (M) The functionality must be provided for the user to suspend and unsuspend a range of route variants with the same operator code and service identifier and the direction of travel.
  14. (M) The user must be able to view in a table window with appropriate horizontal and vertical scroll bars the details of all origin points, destination points, access points, public transport route variants, service route, demand responsive, flexibly routed services, service-specific transport, summary information etc.
  15. (M) The software tool must allow the user to select from a range of available accessibility types/measures or routing options when undertaking accessibility assessments:
  • i. origin or destination based assessments;
  • ii. minimum time, distance, cost or generalised cost and appropriate weights for the generalised cost assessment;
  • iii. local accessibility, network accessibility, composite accessibility, simple time constrained analysis;
  • iv. day of week and day of week type;
  • v. time period or time of day (departure time); and
  • vi. transport mode(s) and vehicle types and associated facilities.
  1. (M) The software tool must allow the user to define or change:
  • i. the access/egress criteria e.g. 10 minutes or 800m walk to/from a bus stop;
  • ii. the default access speed on foot, by wheel chair, bike or car;
  • iii. whether a detailed walk, cycle and highway networks are to be used for access, egress or interchange within the public transport network. In order to cater for local authorities that may not have detailed link based walk, cycle and highway networks the possibility of using crows flight distances and times together with a suitable user defined curvature factor e.g. 1.2 must be incorporated;
  • iv. the maximum number of public transport journey service/mode interchanges.

Walk Cycle & Car:

  1. (M) The software tool must allow users to open, create, modify and save a cycle, walk or car network. These networks are expected to comprise a node/link structure in which the link segments associated with the various networks have associated unique link identifiers, link distances, travel speeds, travel times, travel costs, classification, access facilities (e.g. for the walk network whether it provides access for wheel chairs, the blind or partially sighted accessible, for cycle links whether they are advised on-road routes, non-advised etc). In the case of highway networks, the user must be able to specify day of week and time period information.
  2. (M) The user must be provided with the functionality to modify, suspend, unsuspend, or delete parts of the walk, cycle or car networks as well as saving the resulting network modifications. The functionality to be able to save a network under a different name must also be provided. It is expected that OSCAR in the short-term (due to phased out by 2005) and OS ITN data in the long-term (currently available but will be more widely available by 2005) will provide the main source of link based data from which a walk, cycle and car networks can be created by making suitable network modifications. Functionality must thus be provided to enable users to import, audit (ensure connectivity of adjacent OS ITN / OSCAR links, check validity of roundabouts and other junctions etc) and clean OS ITN / OSCAR data. The user must be provided with the functionality to allocate a link classification to each cycle, walk and highway link from a user defined list of classes with associated default link transit speeds or costs per unit length of the link. In addition the user must be provided with the functionality to alternatively specify a unique link speed for a link and time penalties for specific turning movements.
  3. (D) It is preferable if the user can import alternative local forms of link based walk, cycle and car networks in addition to OS ITN / OSCAR data.
  4. (M) The software tool must provide functionality for users to be able to modify link characteristics, create new links, delete, suspend or unsuspend links etc.

Cordoning Accessibility Networks:

  1. (M) The software tool must provide the functionality for users to cordon down or clip an accessibility network down from a PTE/county level to a municipality, a district/borough level or to a user defined region. In this instance the user is to be provided with the functionality to define the top left hand corner and the bottom right hand corner of the clipped accessibility network. Alternatively the user may choose to utilise a local authority/municipality boundary (or any user defined boundary) as the basis upon which cordoning of the accessibility network is undertaken.

User Guide & Manual:

  1. (M) The software tool must provide the user with a menu option in which the user can view, print and search a detailed software tool user guide and manual. Information is also expected to be provided about the software tool version number and release data. The user guide/manual and teaching guide, expected to be produced as part of the project must consist of simple clear textual and graphical instructions to the user. These instructions are expected to be presented in the form perform x, then perform y and then perform z with clear graphics/screenshots of what the user will be presented with before and after the step in question. The user guide and teaching instructions are expected to make use of pre-defined series of accessibility networks, workspaces, contour settings, software tool initialisation files, SQL queries and reports that are expected to enable new/novice users to produce realistic and accurate accessibility output quite quickly. The user guide/manual is expected to be a step by step illustrated guide on how to perform each stage associated with the use of the software tool menu option(s).

Electronic Mapping:

  1. (M) Since the majority of English local authorities have a service level agreement with Ordnance Survey (OS) the software tool must enable users from such local authorities to take advantage of this agreement by allowing them to import or open a range of OS geo-referenced vector and raster-based mapping. In particular the software tool must provide a mechanism by which users can open and view the range of OS products including 1:10,000, 1:25,000, 1:50,000 scale raster data, Land-Line, MasterMap (including ITN), Meridian, OSCAR Asset Manager, Boundary-Line as well as other geo-referenced raster and vector datasets produced by other organisations.
  2. As an example the Neighbourhood Statistics web site (www.neighbourhood.statistics.gov.uk ) is expected to allow users to download 1998 electoral ward boundaries in vector format, as either ESRI shape files or MapInfo mif/mid files. The boundaries for the 2001 output areas are expected to be dispatched as ESRI shape files and MapInfo mif/mid files by Census Customer Services on CD or DVD on request to local authorities.

Presentation

Contours:

  1. (M) The software tool must incorporate the functionality to produce contours for each of the accessibility assessments outlined above, in addition to other point based datasets. In particular the contouring mechanism must form an integral part of the software tool and must not involve the DfT or the end user of the software tool purchasing a separate licence for undertaking the contouring process. The contouring process must encompass an interpolation phase undertaken on the basis of triangulation. Bidders must outline the particular triangulation and contouring process that is to be incorporated within the software tool. The user must also be able to select/define any of the following options:
  • i. Define the interpolation parameters;
  • ii. Define a number of contour bands/intervals;
  • iii. Define a set size of contour interval/band;
  • iv. Define the size of each contour band/interval.
  1. (M) The contouring process must allow the user to change the colour, shading, boundary line type, colour and thickness in accordance with standard GIS functionality. In addition the user must be able to assign a name and location to the contour file. The contours generated by the contouring process must be vector regions objects, which can be queried and used by leading GIS software tools.
  2. (M) The software tool must allow the user to save the contour options e.g. individual size of intervals, colour, shading, line type/thickness/colour for later use, with the settings being stored in a separate text file with the user being able to assign a name and location to the file, as well as the settings being added to a list of contour themes/settings listed within the software tool itself.

Thematic Maps:

  1. (D) It is preferable if in addition to facilitating the use of contours, the software tool allows the user to generate a range of point, line or region based thematic maps from appropriate point, line and region data. In particular, users may be offered the opportunity to change the point size, type, colour, the line type, thickness and colour and the region shading, colour and boundary line type, colour and size of their data as well as being able to save or store these settings for later use.

Legends & Keys:

  1. (M) The software tool must allow users to generate and modify/edit legends and keys, which can be embedded within a user-defined location (floating legend) within the map window and/or inserted in a user-defined location within the plot window. The legends must allow the incorporation of a title and a subtitle. The software tool must allow the settings utilised within contours or thematic maps to be automatically inserted within an appropriately scaled legend. In addition the user must be provided with the functionality to change any of the legend parameters (text font size/type/colour, line type/width/colour, region type/shading colour). The user must have the ability to add and remove specific point, line, region or text based information to/from the legend.

Error Log File:

  1. (M) The software tool must allow a detailed error log file to be generated, which will readily facilitate software tool support and software tool debugging and testing.

Meta Data File:

  1. (M) The software tool must allow the user to create an accessibility meta data or information file containing a comprehensive listing of the software tool version, production date, project name, network name, database name, names and locations of destinations file, origins file, results file, contour files, workspace files, error log file, initialisation file, contour settings, selected accessibility options, chosen accessibility parameters, date and time of run, individual who undertook the analysis etc. The intention here is that the accessibility meta data file will facilitate training, support and testing and ensure some quality control in accessibility assessments etc. For example, it is envisaged that users could be provided with an accessibility meta data file which when opened will automatically assign choices to options, values to parameters and (if appropriate data is supplied) names to files and thus provide the option of opening a specific accessibility transport/land use network, database, origins file, destinations file, results file, contour file, error log file, workspace file etc.
  2. (M) In addition to the accessibility meta data file, the information stored within this file must be stored within appropriate fields within an accessibility meta data table present within the accessibility model database.

Map Window:

  1. (M) The software tool must allow users to view appropriately selected spatially referenced point, line and region datasets within a map window.
  2. (M) The software tool must allow users to create multiple map windows as well as the ability to change the size and location of any of these map windows as viewed on the computer screen and to view a series of selected map windows and/or text tables on the same computer screen.
  3. (M) The functionality available within the map window must enable the user to zoom in/out, pan around, go to a particular grid reference and zoom to a particular map window scale. The user must be able to select individual or a group of point, line or region objects using a mouse, find out and display information about these types of spatial objects. A layer control facility must be present to allow the user to prioritise, hide, move up or down spatially mapped data visible within the map window as well as possessing zoom layering facilities. The functionality must also exist for the user to measure distances within the map window.
  4. (M) The user must have the ability to change the manner in which point, line and region objects are displayed (e.g. symbol types/size, line types/thickness, region hatching type, colour and text font type, size and colour). The ability to enable and disable the visibility, editability and selectability of point, line and region layers must exist. In addition zoom layering functionality must be available for the user with raster, vector and point datasets in which vector, raster or point layers only become visible within the map window when the map window has zoomed to a specific scale.
  5. (M) The software tool, in addition to providing users with a map window, must enable users to view exact details of the map as it will appear when printed or plotted. In particular the user must have the ability to move and resize the framed map data (contours, mapping etc) anywhere within the limits of the plot window as well as moving and resizing the framed legend/key window. The plot window must allow the user to enter a title, figure or page number, footer or header anywhere in the print area. In particular the user must have the option of changing the font type, size or colour of the selected item of text. The software tool must provide the user with the option of producing one or more such plot windows.
  6. (D) It is preferable for the user to see the name of the currently open accessibility network at all times at the head of the window. In addition it would be preferable within the map window if the current window scale, editing and selection status are displayed at the foot of the map window below the horizontal scroll bar.

Table Window:

  1. (M) The software tool, as well as providing users with a map window, plot window and possibly legend window, must also provide users with a table window allowing textual based information associated with spatially mapped and non-spatial data to be viewed and edited in a tabular format. The user must have the functionality to change the size and location of these table windows as well as the functionality to produce multiple such windows. The user must also have the functionality to modify and print the tabular data present within such windows.

Plot Window:

  1. (M) The software tool must allow the user to export the entire contents of the plot window to an external file including jpeg, bitmap, encapsulated postscript files etc for insertion in an external word document or PowerPoint presentation, or for use with desktop publishing software tools etc.
  2. (M) The software tool must give the user the functionality to tile, cascade and manually position/resize any of the open map, tables or plot windows. The ability of the user to close down any of the aforementioned windows must also exist as well as an accessibility network file. In each of these instances a warning message confirming a desire to close down the window or accessibility network in question must be provided. If the user attempts to end a session of the accessibility modelling/mapping software tool without saving all of the modified data (e.g. modified transport/land use data, modified spatial/non-spatial data, modified workspace/project settings etc) then an appropriate warning must be provided together with an option for the user to save such edits.
  3. (D) In the case of modified spatial and non-spatial data it is preferable if the user is provided with an icon on the status bar at the head of the window denoting that the contents of a file have been modified (e.g. an enable floppy diskette).

Workspace/Project File:

  1. (M) The software tool must allow the user to store, save and facilitate the re-opening of system in the same state it was in when last closed down. To allow this, it should store the current settings of all open map windows, plot windows, tables and text windows within a text based file. The user must be able to define the name and location of this workspace file, which can be considered to be analogous to a MapInfo workspace or an Arcview project.

Printing:

  1. (M) The software tool must allow users to print the map window, plot window or text table to a colour printer or plotter using industry standard approaches. The ability to produce binary print files (define their names and locations), as well as selecting an appropriate printer/plotter, paper size, orientation, copies etc must be incorporated within the software tool.

Local Accessibility

  1. (M) The software tool must allow users to define public transport mode, walk mode time/distance threshold, public transport service frequency level, time of day and day of week which will be used to undertake the accessibility assessment. As an example:
  • i. Public transport mode: Bus
  • ii. Walk time: 10 minutes
  • iii. Public transport service frequency level: 4 per hour
  • iv. Day of week: Monday-Friday
  • v. Time of day: AM peak
  1. (M) Access points satisfying the above criteria (i,ii,iii,iv,v) are then identified and these are then treated as destinations for the subsequent walk routing process. Journey time/distance/cost contours are subsequently produced (preceded by an interpolation stage). Accessibility reports and queries are subsequently expected to be used to determine the population groupings present within the defined journey time/distance threshold.

Network Accessibility

  1. (M) The software tool must allow for ease of reach (origin based) and ease of being reached (destination based) accessibility assessments to be undertaken by the following modes of transport: scheduled public transport, demand responsive, flexible routed services, service-specific transport, cycle, walk and car. Bidders are reminded that the origin and destination based accessibility requirements will have implications for the choice of routing algorithm, in particular for full public transport schedules.
  2. (M) The software tool must enable users to select a routing process based upon minimisation of journey time, distance, cost or generalised cost. In the case of the latter the user must be given the opportunity of defining appropriate parameters/weights for the various components of the journey.

Composite Accessibility

  1. (M) The software tool must enable users to define the deterrence parameter value(s) for and the form of the impedance function associated with travel from an origin point to a destination with a defined attractiveness.

Destinations:

  1. (M) The software tool must allow all destinations types to have the same basic database properties. All destinations are to be defined as points with associated OSGR eastings and northings. The software tool must provide the functionality for the user to add, delete or move the location of a specific destination. The addition, deletion and relocation of destinations must be possible interactively within the map window as well as by specifying appropriate information within the underlying relational database table and table window associated with the destinations. Functionality for the user to allocate a unique National Land & Property Gazetteer to each destination point must be provided.
  2. (M) The functionality must also exist for the user to specify and modify the opening and closing time of the destination under consideration. This type of functionality is required for simple time constrained accessibility analysis.
  3. (M) The functionality must exist for the user to define and modify the attractiveness of the destination in question. The attractiveness of the destination may be reflected by the total retail floor space of a retail outlet, the total number of shops in a shopping centre, the total number of jobs at a place of employment, the total number of out patient or in patient appointments at a hospital, the total number of pupils at a school, the school's annual intake etc. This type of functionality is required for composite accessibility assessments.
  4. (M) The functionality must be provided for users to define a uniform spacing of the destination points by defining interactively within the map window, the top left-hand corner and the bottom right-hand corner of the destination grid as well as the grid point spacing in metres.

Origins:

  1. (M) The software tool must allow all origin types to have the same basic database properties. All origins are to be defined as points with associated OSGR eastings and northings. The software tool must provide the functionality for the user to add, delete or move the location of a specific origin point. The addition, deletion and relocation of origin points must be possible interactively within the map window as well as by specifying appropriate information within the underlying relational database table associated with the origin. The ability must exist for users to define a uniform spacing of the origin points by defining interactively within the map window, the top left-hand corner and the bottom right-hand corner of the origin grid as well as the grid point spacing in metres. Functionality for the user to allocate a unique National Land & Property Gazetteer to each origin point must be provided.

Queries:

  1. (M) The range of queries and analysis that users of the software tool are likely to undertake are expected to vary according to the issues highlighted by local communities and agencies. The functionality must be provided for users to perform a wide range of queries using point, line or region based spatial objects as well as defining the name and location of the associated SQL query statement in an ASCII text file. The querying process must be sufficiently robust for users to use a wide range of spatially based querying functions. The functionality must also be provided for users to be able to open up an existing SQL query text file. It should be noted that a number of the sample queries are expected to be generated as part of the process of developing reports associated with accessibility measures.

Flow diagram

1 The symbol (M) denotes mandatory functionality and processes that must be incorporated and followed during the development of the accessibility planning software tool. All functionality outlined within a paragraph prefixed with the mandatory symbol is mandatory. The symbol (D) denotes functionality that is desirable but not mandatory.