Technical Questions

The second half of the consultation focused on more technical questions, largely centred around standard formats for data exchange. As such, we anticipated that passengers, passenger representatives and other non-technical respondents would likely opt to move past these questions without answering. Both the CitizenSpace platform, and the ‘paper’ Word document question bank, made clear that all respondents were welcome to respond to any question they would like to answer but were not obliged to answer every question should they choose to move past certain topics.

Seventy-six responses were made to the overall consultation, however prior to the following question on routes and timetables, we gave participants that were not interested in answering ‘technical’ questions the option to move past this block of questions without answering. As a result, twenty-three respondents opted not to respond, including nine individuals, eight bodies representing passengers, and two organisations within the broad group of public body respondents. For this bank of questions (the ‘skippable section’) any percentage figure will largely mean out of fifty-six rather than seventy-six.

Technical Questions on Routes

Do you agree that we should set TransXChange as the standard for timetable information timetables, stopping places and about route information?

Bus route and timetable data in Scotland is published via the Traveline National Data Set, which is populated based on the requirements set by the Traffic Commissioner for Scotland around route registration and often lacks the detail needed for journey planning. We have proposed requiring operators to submit digital timetables with stop-level detail and route data as point lists through a standard data format, and on a standard timescale.

While most route and timetable data is currently submitted to Traveline Scotland in TransXChange 2.1 format, various formats—including outdated ones—are still used, requiring additional processing and limiting data quality, particularly where older formats have a limited number of data fields available to convey new requirements. On the basis that TransXChange is the format used in England, where BOD is already mandatory, and it is the most common format used voluntarily in Scotland, we have proposed specifying TransXchange as the standard format for Scotland.

We also asked the following additional questions on routes.

What barriers, if any, do you foresee in organisations being able to provide this information?

From the point of view of a body using, what standard(s) should data be provided in from the data hub for data consumers?

One individual opted to skip this question, but then clicked back and provided a detailed response in the free text area supporting the use of TransXchange. This has therefore been analysed as a supporting response and has increased the total number of responses for the routes section alone to fifty-seven from fifty-six.

Table 6 - Views on using TransXchange for route etc information

TransXchange for Routes?	Number	Percentage
Agree	39	68
Neither agree nor disagree	0	0
Disagree	9	16
Don't mind	0	0
Don't know	0	0
Not Answered	9	16

As a result, 63% of those who chose to respond to the technical questions agreed that TransXchange is the correct format to specify for Scotland regarding uniform provision of route and timetable data. 16% opted not to answer, indicating no strong preference in the ‘routes’ category. A final 16% did not agree with the proposal. Of the 16% who did not agree with the general approach, many caveated their response as meaning ‘largely agree’ with either specific omissions or general caveats, such as:

“…Not entirely" would be a better response above for me…. Care is needed in designing this - just asking for thought to be given for various types of service and not one size fits all.” - The Moray Council

“We agree with the approach, with the important caveat that we do not believe that registered services not available to the general public should be within scope” - FirstBus

Two further ‘no’ responses advised that some demand responsive transport services may have no timetable information to provide, and another called for care in how the information is displayed back to the customer.

Where a service does not run to any timetable, there is no requirement to provide information, and where a service is largely demand driven, but does have a scheduled departure/arrival time at a set stopping place, timetable information would be required for the scheduled part of the route only.

“Whilst we agree with the approach as outlined, this should be the minimum collected. We believe you should also include similar information for the other non-rail modes of public transport in Scotland such as ferries, tram, subway, and local air services.” - NSTAB

Open Data published under the open government licence will by its nature be accessible for use by any person, however we do not propose that the general public be informed by downloading Open Data directly and using it for day to day journey planning. Any member of the public would not be prevented from doing so, however we plan to have the information displayed in a useable and accessible format via the Traveline Scotland app and website.

We also encourage and web developers outside of government to develop new products using the information, and for those products to be used by members of the public. The information can also be used by bus operators, RTPs or other bodies to improve on their existing apps and websites, and we also encourage this use of the information.

When asked about perceived barriers, thirty-three respondents advised that they could see no or minimal barriers to providing this information or gave no response at all. Twenty-Nine respondents gave detailed views on perceived barriers from a number of perspectives. Of the twenty-four responses which provided a view on this topic, eleven noted that smaller (in some cases, small and medium) sized operators will likely have to invest in new technology or develop new skills to be able to provide the information in the correct format.

In most of these responses it was noted that larger operators or those already meeting that requirement for England will not face any particular barrier. Three responses noted that the NaPTAN database will require improvement to align bus stop names in order to have the timetable data make sense, and one response noted that there may be costs involved in off boarding legacy systems and adopting new standards for some operators.

“It may be costly initially to provide this data, especially for smaller operators, but I think the importance definitely trumps that concern”. – An individual on barriers to confirming to a single data standard for route and timetable information.

SPT and one ticket machine provider gave a detailed technical response to this question, which will be also be reviewed separately when looking at guidance.

On the question posed directly to potential users or ‘consumers’ of the data, twenty-five responses supported the use of TransXchange for this purpose. Eight supported the use of NeTEx, nineteen supported the use of GTFS, eleven opted for SIRI-PT with only two selecting ATCO CIF, one call for JESS and three for Hastus. There were a number of comments which explained the perceived differences between the standards, some in support of their use and others to advise that they should not be used due to being considered, for example, a legacy system or a proprietary system which is routinely converted to TransXchange.

Technical Questions on Fares and Tickets

We propose to require fare and ticket data to be submitted in the NeTEx standard. This would align with the DfT’s approach, providing cross-border consistency. We also propose that fares information be phased in over time, with simple ticket information brought in first, followed by complex ticket information, in order to give bus operators a reasonable period to put the necessary systems in place. We are aware from passengers that advising the ways a fare can be paid has strong support for inclusion, however there is variability across operators on how this information is currently displayed, for example as a standalone item or ‘FAQ’ within the operators own website or app. Third parties may assist with complying with this duty, but compliance will be the legal responsibility of operators (or Local Transport Authorities, such as in a franchise area). We asked the following question to seek views on this proposal

We propose to require the use of the NeTEx data standard for information about fares and tickets. Do you agree or disagree with this preferred standard?

We also asked

What barriers, if any, do you foresee if legislation requires Scottish bus operators to provide information in this format?

And

From the point of view of a data user, what standard(s) should data be provided in?

In response to this question, thirty respondents opted to skip past the question entirely, while eight respondents confirmed they did not mind/had no strong opinion on the use of this standard. Thirty responses agreed with the use of NeTEx for fares information, largely citing its use in the wider UK. Only one response advised against the use of NeTEx, citing the need for input from payment service providers to provide a comprehensive dataset, and potential issues with multi-operator schemes/concessionary schemes. This means that of those that opted to answer the question, 77% were in favour of using NeTEx,

NeTEx is the most obvious choice for a standard for fares as other formats would require significant bespoke development. – RTIG Inform

In terms of barriers, eighteen responses provided additional insight, largely citing the same barriers as for route information around resource, skillset and investing in new technologies or services. Four responses suggested having either a freely available conversion or creation tool, which can output NeTEx files from other data sources. One response also noted that while TransXchange format is ‘human readable’ NeTEx files are exclusively machine readable and that this may be off putting for some.

For the question posed directly to data users, nine responses opted for GTFS as the most useful format to use the data in, and fifteen responses opted for NeTEx. However, within the supporting free text field, three of the responses that chose NeTEx as their preferred standard for working with the data, explained that they would prefer to have fares data in both GTFS and NeTEx format. One response cautioned against converting data supplied one format into another format for use as open data, and another noted that GTFS was inferior to NeTEx in their view.

The purpose of asking which data format data users specifically would like to receive information in is to inform any future development of internal platforms, which will likely include the Bus Open Data, but may include many types of data. It may also help inform any future changes to the Bus Open Data Regulations, particularly if there is a significant interest in the transport data set that would warrant additional development within the existing platform.

Technical Questions on Real Time Information

This consultation looked at real time information with a specific focus on location information. Location information is currently being captured in Scotland on a voluntary basis by some operators and is commonly achieved through Electronic Ticketing Machines (ETMs) already in use for the collection of fares, including mobile or handheld solutions.

Conversely, facilities and accessibility information is not something that is currently commonly captured on a real time (in use) basis. We had determined prior to this consultation that it would reasonably require a deeper review of available systems to be able to provide this information in a meaningful way, and that there is no common standard at present in either Scotland or in other devolved nations.

As a result, we have been minded to phase in the requirement to provide facilities and accessibility information over time. We intend to work with the bus sector to align on capture methods, to be affirmed in guidance, and to require information about onboard facilities and accessibility information in a common format moving towards potential future Regulations. There is clearly a strong call for this information from groups representing passengers, and particularly those with disabilities, (also confirmed by the responses to this consultation in the published responses) however it would be difficult, in terms of setting statute, to specify a duty without also prescribing the framework in which it will operate.

It should be noted that facilities and accessibility information will remain a priority for Transport Scotland, and that we will continue to move towards putting this information into the public domain, likely with future legislation.

Location Information

• Live vehicle location
• Live Bus stop arrival and departure times
• Live timetables
• Live disruption updates

We asked the following question about the provision of real time (location) information:

We believe that real time data should be provided in the SIRI data standard to collect more raw data and to align with English and Welsh standards. Do you agree or disagree with this approach?

We also asked

What barriers, if any, do you foresee if legislation requires Scottish bus operators to provide information in this format?

And

From the point of view of a data user, what standard(s) should data be provided in?

As with the other ‘technical’ questions, twenty-three respondents opted to skip this question. Of the remaining fifty-six, one respondent had no strong view on the proposal to use SIRI for real time information. Forty-Four responses agreed with the proposal, largely citing the need to align with England and Wales for cross border operators and noting that this standard is commonly used for this kind of information. One response agreed but noted that GTFS-RT was an equally valid option. Only two responses disagreed with this approach, both bus operators. One recommended GTFS-RT as being proven in its ability to also handle fares information, and one which supported the move to SIRI in general, but were unable to provide more detail without being sure of the SIRI variant being proposed.

On the barriers to moving toward this standard, the feedback was similar to that given for routes and timetables and fares and tickets. Seventeen respondents provided comments, noting again that moving to a new standard may require staff or training not available within smaller operators, however there were no comments citing difficulty with the standard itself, compared to any other.

“Lack of technical knowledge might be an issue” - BusUsers UK

Our understanding is that providing real time location information can be achieved through automation, and that this is something many commercially available Electronic Ticket Machines (ETMs) can offer, often as a paid for service. One response also asked for the possibility of Transport Scotland being able to convert information provided in a different standard in order to comply. For the question put to data users specifically, forty-six respondents either did not know, had no strong opinion or skipped the question. Three noted they would prefer to work with GTFS-RT and twenty-four opted for SIRI. Within this group, five respondents noted that both GTFS-RT and SIRI would be required to extract meaningful data.

As real-time information is a near continuous update, rather than a monthly, weekly or yearly update, it is important to know how often the information must be ‘refreshed’ while the public service vehicle is in operation. As such we asked one additional technical question on how this should be achieved.

Respondents were asked the following question:

We propose that real time information needs to be as close to ‘real time’ as possible. We would therefore like to hear your views on an acceptable feed time for location services

And asked to choose from the options below

• Data provided within one minute while the service is in operation
• Data provided within the average time between stops on the route (For example, if the average travel time between two stops is 3 minutes, an update would be required within three minutes)
• Data provided within a timescale set by geographic location, detailed separately in guidance (For example, within one minute in a city region, but within 5 minutes in a rural area)
• Data provided within one minute, but with the possibility of exemptions set in guidance (For example, guidance could set a process to agree and identify geographic areas with low connectivity where the timescale could be longer, or could simply list agreed areas which would be automatically exempt)
• Another timescale (please provide)

Twenty-nine respondents skipped this question. Of the remaining forty-seven, seven supported a geographic model, nineteen opted for up to one minute while the bus is in operation, seven opted for another timescale (largely for provision of less than 60 seconds, such as 1s, 10s, and 30s) and four preferred a system of averaging between stops. One response was keen to ensure that operators are not penalised for dropped connectivity in ‘dead spots’,

Rural connectivity improves over time. So the rules should be adaptive. If we require rural busses to try to report every 30s they will make use of whatever connectivity is available - An Individual

Having taken advice on how best to reflect this in statute, we are aware that there is a need for legislation to have a reasonably ‘future proofed’ target, however, in terms of enforcement there is room for a wider margin where the information is still valuable, and would account for intermittent gaps in coverage in more rural areas. We believe it is reasonable to encourage the provision of data but to delay any enforcement action until the point at which it is functionally no longer useful, which from the consultation appears to be at the 60s mark. We have also moved away from the approach taken for England where there is also a mandated maximum ‘refresh rate’ which was between 10 and 30 seconds. We therefore propose to set a target in legislation which is currently being achieved in other areas, likely around 30s, but with information in guidance framed around a minimum 60s period, which would allow for an average that accounted for ‘dead spots’ in connectivity.

We can also frame guidance around identifying these areas so they can be taken into account where necessary..

Technical Questions on Stopping Places

The primary legislation on bus open data applies to local transport authorities, rather than bus operators. These are Scotland’s thirty-two local transport authorities which are part of the thirty-two unitary council authorities. The primary legislation talks about ‘stopping places’ rather than ‘bus stops’ which is the more common colloquial term. In this consultation and in the resulting secondary legislation, a stopping place means any place where a bus may stop to allow passengers to access or depart from a service, irrespective of whether there is physical infrastructure (such as a pole or shelter) present.

Local authorities UK wide currently use the NaPTAN (National Public Transport Access Nodes) data standard to submit information to the (UK) National Public Transport Access Nodes dataset, in Scotland this is currently done on a voluntary basis. The NaPTAN dataset describes the precise location of stops, stations and ports for all public transport modes, UK wide.

The legal duty to provide stopping place information will remain with the local authority, however, the information can be submitted via another body acting on their behalf, such as a Regional Transport Partnership or Transport Scotland.

Our proposal is to adopt this standard and practice and include it in statute to make it a mandatory function. This should have the effect of improving the quality of information in the dataset as the quality of information from Scotland improves, and also of having a forward benefit to other transport data sets that use NaPTAN information to include information about bus stops (or ‘stopping places’) in other systems. NaPTAN is the foundation of most scheduling and journey planning systems using stops/port/station information, and works alongside a second dataset, the National Public Transport Gazetteer (NPTG). The NPTG is a topographic database of all cities, towns and settlements in the UK, providing a frame of reference for the NaPTAN dataset

Do you agree with our proposal to use the NaPTAN data standard for this information?

We have proposed adopting the NaPTAN data standard for submission to the NaPTAN dataset. We also asked respondents if they had views on the timescales this information should be provided in, and what barriers may prevent authorities from making these updates

What factors, if any, could be a barrier for local transport authorities in maintaining bus stop information this way?

How often should this information be updated? After every change, as often as possible but no less than every three months, as often as possible but no less than every twelve months, or ‘other’?

Of the fifty-six responses that opted not to skip past the ‘technical’ question bank, only sixteen (29%) answered this question while the remaining forty (71%) respondents opted to manually skip the question. However, of those which responded, all were in favour of using the NaPTAN standard and dataset for this function. Several responses noted the inefficiency in creating a separate ‘Scotland’ NaPTAN, and that it is common practice, albeit voluntary in Scotland already.

One data set is better than many. But it must be quick and easy to add stops. – An Individual on maintaining stopping place data

Some responses noted improvements which would benefit the dataset overall, including work required to include accessibility information alongside other data fields, the need for locations to be refreshed to replace historic location descriptions and overall simplification of the naming conventions. This evidence will be shared with DfT colleagues for the purpose of informing improvements.

Eighteen responses shared information about perceived barriers to adopting this standard. Nine of these directly referenced potential issues with resource, both in general headcount and in having the skillset required to make the return. Two responses named specific geographical areas that would likely struggle to become complaint without specific assistance for unspecified reasons, and three responses noted the need to invest in an editing tool.

One response noted that each authority would likely have to audit their current practices and resourcing, while another noted that Gaelic names are likely to fall within ‘local knowledge’ with the implication that it would take time to transfer this information in practice.

Forty-four respondents answered the question on timescales for change, with the majority (thirty-three responses) requiring changes be made every time the authority is aware of a change having been made to a stopping place. Three responses selected the option for an alternative timescale, however of these only one provided an alternate timescale, of no less than one month from the last update. Of the other two, one described and update being required ‘after any change’ and has been included with ‘every time an authority is made aware of a change having been made’ and the other requested after any change but not less than every twelve months, and so has been included alongside ‘as often as possible but not less than every twelve months’. Five responses supported changes to be notified as often as possible but not less than every twelve months, and a further five supported updating the dataset as often as possible but no less than every three months.

There is a clear preference for the existing NaPTAN data standard to be used for stopping place information, albeit with some concern about Local Transport Authorities resource levels and in house skills to undertake this duty on a mandatory basis. There is strong support for updating the NaPTAN dataset after any change is made to stopping places, including physical attributes (changes to infrastructure) and non-physical attributes such as the name or descriptor of the location.