Croatia

Overview in the National Level

The national NeTEx profile of Croatia was created within the project of Implementation of NAP for multimodal traffic information and development of a local journey planner which took place in 2022 from March to November.

The following documents were used to implement the Croatian national profile for NeTEx (also available via Croatian Institute for Standards).

• CEN/TS 16614-1:2020 Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format.
  • “white paper” NeTEx-Network-WhitePaper_1.08 which describes NeTEx network concept in a non-expert way.
• CEN/TS 16614-2:2020 Public transport - Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange.
  • “white paper” 09.NeTEx-Timetable-WhitePaper_1.05 which describes NeTEx timetable in a non-expert way.
• CEN/TS 16614-4:2020 Public transport - Network and Timetable Exchange (NeTEx) - Part 4: Passenger Information European Profile.

Use cases

Description

Within the project of Implementation of NAP for multimodal traffic information and development of a local journey planner, an internal tool was created to convert GTFS files to NeTEx due to the lack of PTA/PTO providers that have a machine-readable format.

Some of the PTA/PTO providers are on the national and some on regional level, and due to various completeness of data provided we had issues with compliance.

Besides city centres, Croatia can be divided in three areas, central, maritime, and mountainous regions. From the perspective of data quality and available applications, central and maritime areas, are more covered with quality data, than mountainous region since they are driven by greater touristic demand.

Level of digitalization of PTA/PTO data is rather low. Where exist, different standards are used, with GTFS prevailing as the most used data format. Further activities must be made in order to raise the level of data digitalisation within stakeholders, to hold the stakeholders to recognize benefits of data sharing and to ensure provision in EU support and recommended formats. Croatia has already started several projects in order to fulfil goals, with results already being visible with inclusion of more data sources in standardized format in Croatian NAP.

Architecture

The basic concepts for EPIP are described in the data dictionary in CEN/TS 16614-4: 2020 Public transport - Network and Timetable Data Exchange (NeTEx) - Part 4: Passenger Information European Profile.

The main terminology used to describe the topology of the public transport network are:

• ROUTE: an ordered list of discrete locations as a route point that geographically defines a single route passing through a road (or rail) network.  ROUTE can pass through the same point of the route multiple times. ROUTE LINK can be used to connect ROUTE POINT points along the way.
• JOURNEY PATTERN: defined as an organized SCHEDULED STOP POINT (e.g. teyes where passengers enter and exit) and TIMING POINTS (i.e.  information on the time required for the preparation of timetables) on each ROUTE describing the pattern of operation of public transport vehicles. Journey Pattern can go through the same point multiple times.
• TIMING PATTERN: redo sequence TIMING POINTS for each JOURNEY PATTERN determined by TIMING PATTERN.  The sequence scheduled stop points (from journey pattern) is determined by the SERVICE PATTERN.  Service Pattern (= variant ROUTE) is a subset of a JOURNEY PATTERN consisting of a stop point sequence.

A line (LINE) is usually defined as the sum of multiple ROUTEs with a public label (name, number).  From a topological point of view ROUTS are usually very similar because the versions are basic ROUTE with some deviations. Two routes that share the same infrastructure path (or parallel path), but with the opposite orientation usually belong to the same LINE.

An XML document is a physical record of public passenger transport data used for the exchange between sender and recipient of EPIP-compliant data.

It is recommended that the XML document name be written as follows:

• The name of the document (prefix) is NETEX_PI
• The main version of EPIP; currently 01
• ISO 3166-2 Country Code
• Sender name (use NAP if data comes from National access point)
• Document type (LINE, NETWORK , or STOP)
  • LINE: The document contains a description of one line: line number or name if no number is available (short name, fewer than 15 characters, made only of letters (uppercase and lowercase), numbers and "-")
  • NETWORK: Document contains a description of two or more lines
  • STOP: Document contains a description of all stops

• Date Created (YYMMDD)

• All fields are separated by a "_" character.

Use cases

During the project of Implementation of NAP for multimodal traffic information and development of a local journey planner, we transposed mainly GTFS files into NeTEx files. Presently at NAP we have several PTA/PTO providers (GPP Osijek, ZET, Pulapromet – bus, HŽ – train and Jadrolinija – ferry) with the data available in the NeTEx standard. Also, during the project, LJP was created with all the available PTA/PTO data. You can find more information here.

• Smart City Rijeka, City of Rijeka - CEKOM Project- application of NeTEx and Datex Standard for traffic management and passenger information
• OLGA Green and Holistic Airport, City of Zagreb- application of NeTEx and Datex Standard for traffic management and public transport optimisations
• Traffic Management System - City of Split - application of NeTEx and Datex Standard for traffic management and passenger information

Outcome

Most NAP users have shown interest in the access to the PTA/PTO data, so we find necessary for all data presently available on NAP to be updated in a timely manner. For the moment that is not always the case.

The results of implementation have enabled an easier data exchange within the various stakeholders, the harmonization of standards have enabled development of uniform applications reducing the requirements for 3PP non-standard data integration resulting in reducing the cost of application development and increasing the rate of application reusability.