PTIM – Public Transportation (PT) Information Manager: Development Complexity, Dual Architecture and Optimistic Strategy.

Problem Statement: Public transportation systems in many cities are still largely supply-driven, planned around fixed routes, historical assumptions, and operator constraints rather than continuously evolving citizen demand. Families and individuals often experience gaps between real mobility needs and available service—manifested in long wait times, poor first/last-mile connectivity, overcrowding on some routes and underutilization on others, and limited alignment with school, work, and care schedules. From the citizen’s perspective, information about reliability, comfort, accessibility, crowding, and multimodal options is often incomplete or scattered across multiple apps and agencies. Meanwhile, transport authorities lack fine-grained, household-level demand intelligence that could support dynamic planning and optimization. Without a demand-aware public transport intelligence layer, cities struggle to improve service efficiency, increase ridership satisfaction, reduce private car dependency, and progress meaningfully toward congestion and carbon reduction goals.

INTEGRA PTIM is a unified data module for public transport information management. It captures every organizational, operational, geographic, and commercial fact needed to describe a multimodal transport network — from the agencies that operate services, through routes, schedules and vehicles, down to individual stops, fares, and live citizen-reported conditions.

The main objective should be to make PTIM not merely a public-transport timetable database, but a complete citizen-centric Public Transport Information Model covering the physical network, scheduled service, actual service, vehicles, passengers, accessibility, disruptions, fares, transfers, and citizen demand.

1. PTIM Logical Order: Why PTIM might be the Most Challenging INTEGRA Modules? PTIM is potentially the most complex module within the INTEGRA ecosystem. The reason is not primarily the number of screens or database records. The fundamental difficulty is that PTIM has to deal simultaneously with two distinct transportation paradigms.

The first is the existing public transportation system: a highly developed, operational, regulated and interconnected system involving operators, routes, lines, stops, stations, timetables, vehicles, journeys, fares, passenger flows, service areas, performance measurements, incidents and many other operational parameters.

Two entity families run through the existing PT model: (a) static/reference data - agencies, routes, schedules, stops, fares - which changes infrequently and forms the backbone of any journey planner; and (b) live, citizen-generated data — waiting-passenger alerts, bus occupancy, and service alerts - which turns the platform from a static timetable publisher into a real-time, participatory civic service.

The second is a fundamentally different concept: Demand-Related Transport (DRT) - designing and adapting public transportation according to the actual, emerging and potentially unmet transportation requirements of citizens. PTIM cannot simply be another database of existing transportation services. It must ultimately become a bridge between:

WHAT THE CITY CURRENTLY PROVIDES and WHAT THE CITIZENS ACTUALLY NEED.

INTEGRA PTIM has ten logical domains:

A. PROVIDERS AND MODES: Transport Authorities/Agencies, Transport Operators, Transport Types.

B. NETWORK: Routes, Lines, Directions, Branches, Stops, Stations, Platforms, Road Sections, Lanes.

C. SERVICE PLANNING: Service Schemes, Service Calendars, Exceptions, Special Service Periods.

D. TIMETABLE AND OPERATIONS: Itineraries, Planned Trips, Actual Trips, Stop-Times, Frequencies, Trip Stop Details

E. VEHICLES AND CREWS: Vehicles, Vehicle Types, Drivers/Crew, Vehicle Assignments.

F. PASSENGER FACILITIES: Stops, Stations, Platforms, Shelters, Seating, Passenger Information, Accessibility, Passenger Amenities, Safety Facilities.

G. FARES AND TICKETING: Fare Groups, Fare Products, Fare Prices, Fare Rules, Fare Zones, Transfers,
Ticketing, Payment Methods, Fare History.

H. REAL-TIME OPERATIONS: Delays, Cancellations, Diversions, Platform Changes, Occupancy,
Availability, Service Alerts, Operational Disruptions.

I. INTERMODAL MOBILITY: Transfers, Walking Connections, Bike Connections, Taxi Connections,
Carpool, Park-and-Ride, Kiss-and-Ride, Micromobility.

J. CITIZEN DEMAND AND FEEDBACK: Citizen Transport Demand, Citizen Mobility Requirements, Citizen Requests, Citizen Complaints, Crowding Reports, Suggested Stops, Suggested Routes,
Suggested Timetable Changes, Citizen Feedback, Authority Responses.

2. The Existing Public Transportation Information System: PTIM development stream documents and manages the existing transportation supply. From Transport Operators and Routes to Citizens, Journeys and Real-Time Mobility. This environment contains information concerning:

Transportation operators.
Public transportation authorities.
Lines.
Routes.
Stops.
Stations.
Timetables.
Scheduled journeys.
Vehicles.
Vehicle capacities.
Service frequencies.
Operating periods.
Fare structures.
Transfers.
Passenger volumes.
Service performance.
Delays.
Cancellations.
Incidents.
Accessibility.
Geographic coverage.
Operational constraints.
Historical performance.

The system also interacts with information originating in external operational databases and transportation-management systems. This makes the Existing Supply component of PTIM substantially more complicated than a conventional INTEGRA data-entry module. The first PTIM version does not need to replace the operational systems of transportation operators. It should primarily provide an INTEGRA information and intelligence layer capable of receiving, organizing, mapping, querying, comparing and displaying relevant transportation information. The principle should therefore be: Integrate first. Replace later - if ever necessary.

PTIM at a Glance: INTEGRA PTIM is structured as a relational, identity-driven public transport information model. The core design moves from organizations and transport types to routes, service patterns, itineraries, trips and stops, then adds citizen-facing operational signals and fare information.

Layer	Entities / Repositories	Primary role
Governance & classification	2851 Agencies; 28515 Transit Types	Identify operators and standardize modes.
Network	2852 Routes/Lines; 28520 History	Define the stable public network and its evolution.
Service planning	2853 Service Schemes; 2854 Exceptions	Express recurring service and date-specific deviations.
Movement	2855 Itineraries; 2856 Trips; 28651 Trip Details	Describe planned and real-world vehicle movement.
Passenger interface	2857 Stops; 28575 Waiting Alerts; 28577 Occupancy; 28579 Availability Alerts	Connect the network to people waiting and travelling.
Timing	28581 Stop-Times; 28582 Trip Frequencies	Represent detailed timing and frequency.
Commercial	28590 Fare Groups; 28591 Price List; 28592 Prices; 28595 History	Represent eligibility, prices, zones, transfers and fare evolution.

INTEGRA PTIM represents the EXISTING complete operational reality of public transportation:

Who provides the service?
What transport services exist?
Which routes and lines are operated?
When do they operate?
Which vehicles/trips run on those routes?
Which stops and stations do they serve?
What is the exact sequence and timing?
What does the passenger pay?
What facilities and accessibility provisions exist?
What happens when the planned service changes?
What is happening right now?
And, ultimately: what does each citizen need and what public transport solution can serve that need?

The INTEGRA PTIM therefore treats public transportation as a dynamic, interconnected information ecosystem.

3. The PTIM EXISTING Public Transport Hierarchy:

LEVEL 1 — TRANSPORT AUTHORITY / OPERATOR

Who provides or manages transportation?

↓

LEVEL 2 — TRANSPORT TYPE

What kind of transportation is it?

↓

LEVEL 3 — ROUTE / LINE

What organized service is offered?

↓

LEVEL 4 — SERVICE SCHEME

On which recurring days/seasons does the route operate?

↓

LEVEL 5 — ITINERARY

What physical path does the service follow?

↓

LEVEL 6 — TRIP

Which particular scheduled journey operates on that itinerary?

↓

LEVEL 7 — STOPS / STATIONS

Where can passengers board or leave the vehicle?

↓

LEVEL 8 — STOP-TIMES / FREQUENCIES

Exactly when does the trip serve each stop?

↓

LEVEL 9 — FARES

How much does the passenger pay under particular conditions?

↓

LEVEL 10 — REAL-TIME / CITIZEN INFORMATION

What is actually happening now?

This produces the central operational chain:

AGENCY / OPERATOR → ROUTE / LINE → SERVICE SCHEME → ITINERARY → TRIP → STOP

Transport Type classifies the mode used by an agency/route.
Route History records changes to the public network.
Exceptions modify a normal Service Scheme on specific dates.
Trip Details record what happened at each stop during a particular trip.
Waiting Passenger Alerts, Occupancy and Availability Alerts inject citizen/operational observations.
Stop-Times and Frequencies provide detailed temporal behavior.
Fare Groups, Price Lists and Prices connect passengers and journeys to commercial rules.

4. PTIM Design Principles:

Stable identifiers first: Agency/Operator ID, Route ID, Stop ID, Service Scheme ID, Itinerary ID and Trip ID provide durable references between entities.
Separation of concepts: a route is not a trip; a recurring service scheme is not an exception; a stop is not necessarily a station; a fare definition is not the same as a fare application.
Operational + citizen data: the model combines authoritative transport data with real-time passenger observations and alerts.
Temporal modeling: service dates, exceptions, historical changes, planned times and real-time times are represented explicitly.
Interoperability: Public Transit Types include GTFS route-type mapping, while the INTEGRA identifiers retain the richer civic data model.
Citizen-centric publication: the same structured data can feed mobile displays, stop information, journey planning, alerts, accessibility information and civic analytics.

Segment	Entity	Primary Key
2850	Transport Agencies	Agency ID
2851	Transport Operators	Operator ID
28510	Agencies-Operators Relationships	Relationship ID
2852	Routes/Lines	Region + City + Agency/Operator ID + Route ID
28520	Routes/Lines History	Region + City + Agency/Operator ID + Route ID + Date
2853	Service Schemes	Service Scheme ID
2854	Exceptions to Service Schemes	Exception ID
2855	Itineraries	Itinerary ID + Sequence Number
2856	Trips-Header/Title	Trip ID
28651	Trips-Details	Trip ID (implied — should be added explicitly) + Stop ID + Sequence Number
2857	Stops	Stop ID
28575	Waiting Passengers Alerts	Citizen ID + Stop ID + Start Waiting Time
28577	Intercity Bus Occupancy	Citizen ID + Trip ID + Time
28579	Available/Unavailable Intercity Bus Alerts	Citizen ID + Temporary/Ad-Hoc Trip ID + Time
28581	Stop-Times	Trip ID + Stop Sequence
28582	Trips Frequencies	Trip ID + From Time
28590	Fare Groups	Group ID
28591	Public Transit Prices List	Fare ID
28592	Public Transit Prices	Fare ID + Route ID + From Stop ID + To Stop ID
28595	Public Transit Prices History	Fare ID + Date

5. The Institutional Layer — Segment 2850 - Transport Agencies:

Each agency is identified by: Region, City, Transport Type, Agency/Operator ID, Agency/Operator Name, Logo, Official URL, Time Zone, Optional Language, Descriptive Text

Why this segment matters? A city may contain:municipal transport operators; regional bus companies; railway operators; metro operators; ferry companies; taxi operators; private concessionaires; specialized transportation providers.

Each agency/operator receives a permanent Agency/Operator ID. The ID becomes a primary reference for: routes; trips; stops; fares; service schemes; operational events; historical records; citizen information.

Attributes:

Field	Description / Format
Region	Administrative region code (ISO 3166-2 or national equivalent).
City	City / municipality name or code.
Transport Type	One or more values from the Types of Public Transit lookup (Table 28515).
Agency/Operator ID	Primary key. Unique operator identifier.
Agency/Operator Name	Legal / public-facing operator name.
Agency/Operator Logo	URL or binary reference to the operator's logo asset.
Agency/Operator URL	Official website of the operator.
Agency/Operator Time Zone	IANA/Olson time zone (see List of time zones by country).
Agency/Operator Language (optional)	IANA language subtag (see IANA Language Subtag Registry).
Text	Free-text notes / description.

6. In most of the countries the institutional layer of public transport systems – is more complex:

PT Authority/Agency and an PT Operator are different organizations.For example:

Transport Authority → plans, regulates, finances, or coordinates the network.

Transport Operator → actually operates buses, trains, trams, ferries, etc.

Infrastructure Manager → owns or manages stations, tracks, roads, platforms, etc.

Ticketing/Fare Authority → may administer fares and ticketing.

With These Public Transport ecosystems INTEGRA provides 3 segments:

Public Transport Authorities/Agencies – Segment 2850:

Field
Region
City
Authority/Agency ID
Authority/Agency Name
Authority/Agency Type: National, Regional, Metropolitan, Municipal, Licensing, Regulatory, Funding, Traffic Mgt.
Authority/Agency Functions Text
Authority/Agency ID Logo
Authority/Agency ID Website / URL
Authority/Agency Contact / Address
Authority/Agency Time Zone
Authority/Agency ID Language (optional)
Authority/Agency Remarks Text

Public Transport Operators – Segment 2851:

Field
Region
City
Operator ID.
Operator Name
Operator Type
Operator Transport/Transit Types Text
Operator Contact/Address
Operator Service contact Text (Where to ask a question)
Complaint channel Text (Where to report a problem)
Accessibility contact Text (Where to request assistance)
Authority/Agency Remarks Text
Lost & found Text (Where to report something lost)
Service feedback Text (How to evaluate the service)
Operator Functions Text
Operator Website (URL)
Operator Logo
Operator Time Zone
Operator Language
Operating Area Text

Public Transport Agencies/Authorities - Operators Relationships– Segment 28510:

Field	Description / Format
Relationship ID	Unique identifier of the particular Agency–Operator relationship. Example: REL-SHA-0001
Agency ID	Identifier of the transport agency participating in the relationship. Example: SHA-TA-001 (Agency Name: Shanghai Municipal Transport Commission).
Operator ID	Identifier of the transport operator participating in the relationship. Example: SHA-OP-002 (Operator Name: Shanghai Bus No. 2 Public Transportation Co., Ltd. (Jiushi Transit).
Relationship Type	Defines the nature of the relationship between the Agency and Operator. Examples: Regulatory Authority → Operator; Licensing Authority → Operator; Contracting Authority → Operator; Franchise Authority → Operator; Concession Grantor → Operator; Subsidizing Authority → Operator; Planning Authority → Operator; Coordinating Authority → Operator; Data-Regulating Authority → Operator; Data-Sharing Authority → Operator; Infrastructure Owner → Operator; Joint Authority / Operator Partnership; Other.
Relationship Status	Defines the current status of the relationship. Examples: Proposed; Pending Approval; Active; Suspended; Expired; Terminated; Cancelled.
Legal / Contractual Basis	Identifies the legal, regulatory or contractual basis for the relationship. Example: Public Transport Operating Contract.
Contract / Concession ID	Identifier of the contract, concession, franchise, license or permit. Example: PTC-SHA-2026-049.
Contract / Concession Type	Defines the type of legal or contractual arrangement. Examples: Operating Contract; Franchise; Concession; License; Permit; Public Service Agreement; Management Contract; Partnership; Other.
Relationship Start Date	Date on which the relationship becomes effective. Example: 01 JAN 2026.
Relationship End Date	Date on which the relationship expires or terminates. Example: 31 DEC 2030. This field can be empty or “Indefinite.”
Renewal Option	Indicates whether the relationship can be renewed. Example: Yes.
Renewal Terms	Description of the renewal provisions. Example: Two optional two-year extensions.
Transport Type / Mode	Identifies the transport mode covered by the relationship. Examples: Bus; Electric Bus; Tram; Metro; Light Rail; Regional Rail; Ferry; Cable Car; Demand Responsive.
Transport Service Category	Defines the category of transport service. Example: Urban Public Transport.
Operating Area	Defines the geographic area covered by the relationship. Example: Xuhui District and Huangpu District, Shanghai.
Routes / Services Covered	Identifies the routes or services governed by the relationship. Example: Route 49.
Agency Regulatory Role	Describes what the Agency is responsible for. Example: Regulation, licensing, safety requirements and service standards.
Agency Contract Management Role	Indicates whether the Agency manages the operating contract. Example: Yes.
Operator Operational Responsibility	Describes the Operator’s operational responsibilities. Example: Daily operation of Route 49 and provision of scheduled passenger services.
Operator Maintenance Responsibility	Indicates responsibility for vehicle and equipment maintenance. Example: Yes.
Infrastructure Responsibility	Defines who is responsible for infrastructure such as stops, terminals, depots and passenger facilities. Example: Shared.
Fare Authority	Identifies who establishes, regulates or approves fares. Example: Transport Agency.
Timetable Authority	Identifies who establishes or approves timetables. Example: Transport Agency approval.
Route Planning Authority	Identifies who determines, proposes or approves routes. Example: Transport Agency.
Performance Monitoring	Indicates whether the Operator is subject to formal performance monitoring. Example: Yes.
Service Level Agreement	Identifies the applicable service-level agreement. Example: Shanghai Urban Bus SLA – Level A.
Reporting Frequency	Defines how frequently the Operator must report to the Agency. Example: Monthly.
Passenger Data Reporting	Indicates whether passenger and operational data must be reported. Example: Yes.
Real-Time Data Sharing	Indicates whether real-time operational data is exchanged with the Agency. Example: Yes.
Data Interface / API	Identifies the technical mechanism used for data exchange. Example: GTFS-RT / Operator API.
Funding Arrangement	Describes how the transport service is financed. Examples: Fare Revenue; Public Subsidy; Mixed; Gross-Cost Contract; Net-Cost Contract; Fixed Payment; Performance-Based Payment; Other. Example: Fare revenue + public subsidy.
Public Subsidy	Indicates whether the Operator receives public financial support. Example: Yes.
Subsidy / Funding Scheme ID	Foreign key to an optional funding/subsidy dataset. Example: SUB-SHA-BUS-2026.
Revenue Responsibility	Identifies who collects and manages passenger fare revenue. Example: Operator on behalf of Agency.
Vehicle Ownership	Identifies who owns the vehicles used for the service. Example: Operator.
Depot / Facility Responsibility	Defines responsibility for depots and operational facilities. Example: Operator.
Customer Service Responsibility	Identifies who handles passenger enquiries, complaints and customer service. Example: Operator.
Accessibility Responsibility	Defines responsibility for accessibility compliance. Example: Shared.
Safety / Security Responsibility	Defines responsibility for passenger and operational safety. Example: Shared.
Environmental Requirements	Defines environmental obligations imposed on the Operator. Example: Use of low-floor electric buses on Route 49.
Insurance Requirement	Defines required insurance coverage. Example: Commercial vehicle insurance + passenger liability insurance.
Audit Authority	Indicates whether the Agency has the right to audit the Operator. Example: Yes.
Penalty / Incentive Scheme	Indicates whether the relationship contains performance penalties or incentives. Example: Yes.
Relationship Contact	Identifies the organizational unit or person responsible for managing the relationship. Example: Public Transport Contract Management Office.
Contact Email / Phone	Contact information for the relationship. Example: Illustrative contact information.
Document / Contract URL	Link to the relevant contract, concession, license or other documentation.
Language	Primary language(s) used for the relationship. Example: Chinese / English.
Time Zone	Operational time zone applicable to the relationship. Example: Asia/Shanghai.
Record Status	Status of the INTEGRA data record itself. Example: Active.
Last Updated	Date/time when the INTEGRA record was last modified. Example: 20 SEP 2026 14:30.
Remarks	Additional information that does not belong in another structured field. Example: Electric-bus transition requirements apply to Route 49.
Pictures / Documents	Optional supporting photograph, scanned document, contract cover, logo or other visual document.

7. Public Transport Types: Segment 28515.

The system maintains a controlled vocabulary of transportation modes. Examples include:

Bus · Tram · Metro · Train · Commuter Train · Intercity Rail · High-Speed Rail · Ferry · Boat · Water Taxi · Cable Car · Funicular · Monorail · Trolleybus · Taxi · Shared Taxi · Regional Taxi · Coach · Intercity Bus · Bike · Walk · Carpool · Airport-Rail Link

Each type should have: Type ID, Type Name, Standard Symbol, Optional description, optional mode classification.

Why the symbol is important: The transport type is not merely a database value. It becomes a visual language of the City Civic OS. For example: 🚌 Bus, 🚋 Tram, 🚇 Metro, 🚆 Rail, ⛴ Ferry, 🚕 Taxi, 🚲 Bike, 🚶 Walk. The same symbol can appear consistently in: citizen journey planning; maps; route lists;

Emergency plans & alerts; dashboards; reports; mobile applications.

Data-structure:

Field	Description / Format
Type Code	Primary key / enumeration code (system-generated).
Type Name	Display name, e.g. Bus, Metro (Underground), Ferry Boat.
Symbol / Pictogram	Icon reference (SVG asset name) used in maps, apps and physical signage.
GTFS route type mapping	Cross-reference to the standard GTFS extended route-type code for interoperability.

INTEGRA limited list of Types of Transit:

Airline , Airport-Rail Link , Bike , Boat , Bus , Cable Car/Airlift , Carpool , Commuter Train , Coach , Chairlift, Ferry Boat , Funicular , High-Speed Rail/Maglev , Intercity Bus/Long-Distance Bus , Intercity Rail , Light Train , Metro (Underground) , Monorail , Pipeline, Regional Taxi , Shared Taxi , Ship , Subway , Taxi , Train , Tram , Trolleybus , Truck , Walk , Water Taxi .

INTEGRA more formal, extended list of Public Transport Types with monochromatic symbols:

Transport Type	Symbol	Typical Use Case
Airline	✈	Air travel connections feeding the transit network.
Airport-Rail Link	🚈	Dedicated rail service to/from an airport.
Bike	🚲	Bike-share / cycling infrastructure.
Boat	🚤	General waterborne passenger service.
B us	🚌	Standard urban bus service.
Cable Car / Airlift	🚡	Aerial cable transport over terrain.
Carpool	🚗	Shared private-vehicle ride matching.
Commuter Train	🚆	Suburban/regional passenger rail.
Coach	🚍	Long-distance, single-deck touring bus.
Chairlift	🚠	Aerial chairlift, typically leisure/mountain access.
Ferry Boat	⛴	Scheduled cross-water ferry service.
Funicular	🚞	Cable-hauled inclined railway.
High-Speed Rail / Maglev	🚄	High-speed intercity rail corridors.
Intercity Bus / Long-Distance Bus	🚌	Long-haul bus between cities.
Intercity Rail	🚆	Conventional-speed intercity rail.
Light Train	🚈	Light-rail vehicle service.
Metro (Underground)	🚇	Urban rapid-transit rail, underground.
Monorail	🚝	Single-rail elevated transit.
Pipeline	🛢	Non-passenger freight mode (goods movement).
Regional Taxi	🚕	Taxi service scoped to a region.
Shared Taxi	🚕	Shared/pooled taxi (e.g. dolmus/marshrutka-style).
Ship	🚢	Larger maritime passenger vessel.
Subway	🚇	Urban rapid-transit rail, general term.
Taxi	🚕	On-demand private hire vehicle.
Train	🚂	General passenger rail service.
Tram	🚋	Street-level light rail.
Trolleybus	🚎	Electric bus powered via overhead wires.
Truck	🚚	Non-passenger freight mode (goods movement).
Walk	🚶	Pedestrian legs within multimodal itineraries.
Water Taxi	🚤	On-demand small-boat passenger service.

Computerization Notes:

Changes should go through a governance/change-request process since the symbols appear on public signage.
Ship the icon set as a shared SVG sprite so every downstream app (web, mobile, digital signage, printed maps) renders an identical, accessible symbol.
See the Appendix for the full 29-value list with suggested pictograms.

8. Routes and Lines – Segment 2852.The Route/Line is the principal public-facing service entity. A route contains: Region, City, Agency/Operator, Route ID (should be unique within:

Region + City + Agency/Operator), Transport Type, Route Name (should be understandable to passengers. A useful convention is: Origin → Destination), Long Description, URL, Display colors, Sequence order.

Field	Description
Region	Administrative region.
City	City of operation.
Agency/Operator ID	Foreign Key → 2851 Transport Agencies.
Route ID	Unique within Region + City + Operator (Primary Key component).
Transport Type	Foreign Key → 28515 PT Types.
Route Name	Short public name of the route.
Route Name (extended)	Minimum of start and end stop names.
Route Long Description	Days/times of operation, connecting services, transfer points, affiliated lines, facilities.
Public-Facing Route Number/Name
Effective From
Effective To
Origin
Destination
Via
Times of operation
Connection services
Transfer Locations
Affiliated Lines
Facilities Text
Parent Route ID
Route Status
Accessibility Level
Peak/Off-Peak Classification
Typical Journey Du
Route Geometry/Map
Circular (Y/N)
Route/Line URL	Route-specific web page.
Background Colour	Six-character hex colour for line branding.
Text/Font Colour	Six-character hex colour for legible contrast.
Sequence Order	Lower value = higher priority in lists/reports.
Allowed Number of Passengers (ANOP)	Maximum legal/operational capacity.
Wheelchair Access	Unknown / Yes / No.
Pets Access	Unknown / Yes / No.
Smoking	Unknown / Allowed / Prohibited.
Luggage	Unknown / Allowed / Prohibited.
Bikes	Unknown / Allowed / Prohibited.
Firearms	Unknown / Allowed / Prohibited.
Air-Conditioning	Unknown / Yes / No.
Separate Luggage Compartment	Unknown / Yes / No.
Cash Payment to Driver/Conductor	Unknown / Yes / No.
WC Cabin	Unknown / Yes / No.
Remarks	Free text.

Routes and Lines Directions and Branches – Segment 28525.More high-resolution segment with information on Route/Line versions. Added fields: Direction details, Branch Details.

Route/Line Direction

Branch ID

Branch Name

Routes and Lines inc. Directions and Branches History of Changes – Segment 285250. A segment that serves as a basis for forth-coming elaborations and reforms. Not just a log of history.

Field	Description / Format
Region / City	Location scope.
Agency/Operator ID	Foreign key to Transport Agencies (2851).
Route ID	Foreign key to Routes/Lines (2852).
Route/Line Direction	.
Branch ID
Modification Type	Open, Cancelation, Change.
Date,	Date of the change.
Timestamp	Timestamp of the change.
Change Description Text
Effective From
Effective To
Previous Value of Route ID
New Value of Route ID
Changed Field
Change Reason
Authority Approving Change
Source of Change
Changed By Text
Remarks

9. Service Schemes – Segment 2853: A Route describes what service exists. A Service Scheme describes when the service normally operates. Route = WHAT, Service Scheme = WHEN. For example:

Monday–Friday: YES
Saturday: YES
Sunday: NO
Holiday: NO
Season: 1 September – 30 June

A Service Scheme can therefore be associated with one or several routes/trips. This separation prevents the route data-set from becoming an enormous collection of repetitive timetable records. Segment 2853 details continuous / cohesive scheme of service / Service Calendars used for one or several routes/lines. This allows INTEGRA PTIM to represent: Christmas, Easter, Ramadan/Eid, National Holidays, School Holidays, Strikes, Sporting Events, Concerts, Festivals, Weather Emergencies, Other Exceptional Circumstances.

Attributes

Field	Description / Format
Region / City	Location scope.
Agency/Operator ID	Foreign key to Transport Agencies (2851).
Route ID	Foreign key to Routes/Lines (2852).
Service Scheme ID	Primary key, unique.
Service Scheme Name
Monday…Sunday	Y/N flag for each day of the week.
Public Holidays	Y/N — whether the scheme also applies on public holidays.
School Days (Y/N)
School Holidays (Y/N)
Summer Schedule (Y/N)
Winter Schedule (Y/N)
Peak Schedule (Y/N)
Night Schedule (Y/N)
Special Event Schedule (Y/N)
Full Start Date + Timestamp	Date +Time the scheme becomes effective.
Full End Date + Timestamp	Date +Time the schemeTerminates
Remarks

Exceptions to Service Schemes - Segment 2854: Real public transportation contains exceptions:

public holidays; school holidays; special events; strikes; temporary closures; seasonal changes; emergency operations; additional services.

INTEGRA therefore separates: Normal Rule - Service Scheme from Scheme Exception: Specific Date + ADD / EXCLUDE. This is an extremely important principle for Public Transport computerization:

For example: Route 24 normally operates Monday–Friday. But: 25 December — EXCLUDED. 1 January - ADDITIONAL service.

This is an extremely important principle for computerization: Store the normal rule once; store deviations separately.

Attributes

Field	Description / Format
Region / City	Location scope.
Agency/Operator ID	Foreign key to Transport Agencies (2851).
Route ID	Foreign key to Routes/Lines (2852).
Service Scheme ID	Foreign key to Service Schemes (2853).
Exception ID
Exception Name
Full Start Date + Timestamp	The specific calendar date affected.
End Date and Timestamp
Exception Type	1 = Additional service (added to the scheme); 2 = Excluded service (removed from the scheme).
Exception Type Text
Reason for Exception
Replacement Service Text
Citizen Alert Notes
Remarks

10. Public Transport Stops & Stations – the "Heart of every Public Transport system.": From Waiting Places to Citizen-Centric Civic Hubs. A New Vision for the Public Transport Stops/stations.

A public transport stop or station is one of the most frequently encountered physical interfaces between a citizen and the city. Traditionally, its purpose has been simple: a vehicle arrives, passengers board or leave, and the vehicle continues its journey. That definition is no longer sufficient. In a modern, citizen-centric public transport system, the stop or station should become much more than a boarding point. It should be a safe, accessible, informative, connected, useful and socially valuable micro-hub - a place that serves the traveller before, during and after the journey.

With INTEGRA we deal with TWO questions: "Where should we put a bus stop?" and "What does this location need in order to serve the mobility, social and practical needs of the citizens who live, work, study, shop and spend time around it?"

This is a fundamental change in the philosophy of public transportation.

10.1. The Stop Is the Physical "Front Door" of Public Transport: For many citizens, the stop - not the bus, train or transport operator - is their first and last physical contact with the public transport system. A good stop should provide these wishes or attributes. Do not miss even one parameter…

Clear identification and signage, Real-time arrival information, Protection from rain, wind, snow and excessive heat, Comfortable seating, Adequate lighting, Universal accessibility, Safe pedestrian access, Safe boarding and alighting, Information about connecting services, Simple ticketing/payment facilities (not necessary….), Bicycle and micromobility integration, Emergency communication, Accessibility information, Cleanliness and maintenance, Reliable digital connectivity (!!!), A sense of security, Information about the surrounding neighbourhood

The stop should communicate: "You are in the right place, you know what is happening, and the city is taking care of you."

10.2. The Stop Should Be Designed Around the Citizen: The correct location of a stop should not be determined exclusively by engineering rules, road geometry or existing bus routes. It should also reflect actual and anticipated citizen mobility demand. See below the DRT/TDM section of PT planning. A citizen-centric system should continuously collect and analyse: Where citizens live, Where they work, Where children attend school, Where students study, Where people shop, Where people receive healthcare, Where elderly citizens need to go, Where people participate in sports and leisure, Where families spend time, Where employment centres are located, Where major public services are located, When people travel, How frequently they travel, Which destinations are repeatedly requested (recurring or one-time), Where transfers are difficult, Where walking distances are excessive, Where accessibility is inadequate, Where demand exists at unusual hours, Where demand is seasonal, Where one-time or exceptional demand occurs. All these questions are covered by INTEGRA DRT/TDM segments 2873,2874.

10.3 The Stop as a Multimodal Hub: The modern stop should not be designed exclusively around one transport mode. Depending on its location and demand, it can integrate: Bus, Tram, Metro, Train, Light rail, Ferry, Taxi, Shared taxi, Bicycle, Bike sharing, E-bike, E-scooter, Walking, Carpooling, Park-and-ride, Accessible transport, one-time Demand-responsive transport.

The objective is not simply to provide different vehicles. The objective is to provide seamless mobility between modes.

A citizen should be able to think: Home → Walk → Stop → Bus → Station → Train → Bicycle → Destination as one journey, rather than six unrelated transportation events.

10.4. The Stop as a Digital Information Point: The modern stop can also become a local digital information centre.A smart stop can provide: Real-time transport information, Next vehicle, Following vehicle, Delays, Cancellations, Platform/bay information, Service disruptions, Alternative routes.

For every Journey information: Where the service goes, Connections available, Walking distance to connecting services, Estimated arrival time, Accessibility information.

Local information (read when you wait): Nearby schools, Healthcare, Shops, Restaurants, Parks, Libraries, Community facilities, Public buildings, Tourist attractions, Public toilets, Bicycle facilities.The stop therefore becomes a gateway to the neighbourhood.

10.5. Modern and Innovative Add-Ons: Depending on location, passenger volumes and available technology, a modern stop can incorporate many additional functions. Passenger comfort: Heated or cooled waiting areas, Weather-protected shelters, Ergonomic seating, Leaning rails for short waits, Drinking-water facilities, Public Wi-Fi, USB/USB-C protected charging, Mobile-phone protected charging, Digital information screens/monitors. Safety: High-quality lighting, Emergency communication button, CCTV where appropriate and legally justified, Emergency location identification, Safe pedestrian crossings, Accessible emergency information. Accessibility: Step-free access, Audible announcements, High-contrast information, Large-print information, Hearing-assistance technology, Wheelchair space, Accessible boarding arrangements, Clear information about vehicle accessibility. Environmental features: Solar-powered equipment, Solar shelters, Energy-efficient lighting, Green roofs, Vegetation, Rainwater management, Recycled construction materials, Bicycle parking, E-bike charging, Integration with local environmental monitoring (especially, pollution monitoring).

10.6. The Stop as a Family/Social Hub: This is perhaps the most underestimated opportunity. A public transport stop is naturally a place where people meet. Instead of treating passengers simply as people who are "waiting", the city, or the community, can make the waiting experience useful and socially meaningful. Depending on the location, the stop could incorporate: Safe waiting space for children, Small community information boards, Local events information, Neighbourhood announcements, Community notice areas, Public art (!), Local history, Cultural displays, Small exhibitions, Book-sharing facilities (!), Community gardening, Seating areas designed for social interaction, Public Wi-Fi, Local digital services, Baby-changing facilities at major stations, Drinking water, Safe stroller access and parking, Nearby playground site,

A major station could become a genuine community hub. A smaller neighbourhood stop could become a micro-hub.

A family might use the same transport hub to: take children to school → go to work → collect groceries → attend an appointment → collect children → participate in leisure activities → return home.

The transport stop can therefore become part of the community’s or family's daily-life infrastructure.

10.7. The Stop as a Practical Everyday Hub: A strategically located station can also support practical activities that citizens already need to perform. For example: Parcels collection, Lockers, Package delivery, Bicycle repair, Bicycle storage, Small convenience retail, Pharmacy access, ATM/payment services (!), Recycling facilities, Water refill, Public toilets (!!!), Local commerce. All these can also strengthen local businesses and reduce unnecessary additional journeys.

The principle is simple: If citizens are already going there, useful services can come to them.

10.8. From "Bus Stop" to "Civic Mobility Node": A traditional bus stop is designed around a vehicle. A modern civic mobility node is designed around the citizen, family and community: Transport + Information + Commerce + Community + Family + Leisure + Digital Services + Safety + Accessibility. The larger the passenger volume, the more functions can be economically justified.

This creates a natural hierarchy:

Level 1 — Basic Stop

Essential boarding and alighting infrastructure.

Level 2 — Enhanced Stop

Shelter, seating, lighting, real-time information, accessibility and connectivity.

Level 3 — Mobility Hub

Multiple transport modes, bicycle facilities, transfers, digital services and local information.

Level 4 — Civic Mobility Hub

Transport plus commerce, community services, family facilities, leisure, public services and extensive digital infrastructure.

10.9. The Station Should Become Part of the Neighbourhood: The best station is not an isolated object placed beside a road. It should be integrated into its surroundings. A well-designed station should connect naturally with:

Homes ↔ Streets ↔ Shops ↔ Schools ↔ Workplaces ↔ Parks ↔ Public Services ↔ Transport

The station can therefore help create a more walkable and connected neighbourhood. Transport planning and urban planning should no longer be separate disciplines. They should be designed together.

11. INTEGRA: Connecting the Citizen's Need to the Optimal Stop: INTEGRA can conceptually connect three layers:

Citizen / Family Mobility Demand: "What do people need?"
Existing Transport Network: "How can the city satisfy those needs?"
Optimal / Physical Stops and Stations: "Where should the citizen enter, leave or change the network?"

This creates a continuous feedback loop:

Citizen requests → Aggregation → Demand patterns → Network analysis → Stop/station planning → Service implementation → Actual usage → Measurement → Citizen feedback → Continuous optimisation. The transport stop is therefore not the end of the planning process.

It is a sensor, interface and service point within a continuously learning civic system.

The Strategic Opportunity: Cities spend enormous amounts of money on roads, vehicles, stations and transport infrastructure. The next generation of public transport should ask: How can each physical transport location produce more value for the citizen?

A station that serves only as a boarding point provides transportation. A station that also provides information, safety, accessibility, connectivity, commerce, community functions, family services and leisure opportunities becomes part of the city's civic infrastructure. And when its location and functions are continuously informed by citizens' real mobility requirements, it becomes something even more important: A physical expression of the city's understanding of its citizens.

That is the opportunity. Public transport should not merely move citizens through the city. It should help citizens live better in the city.

12. Itineraries – Segment 2855:

An Itinerary defines the ordered movement pattern of a Route under a Service Scheme or Exception. It binds Stop IDs to sequence numbers and adds elapsed time and distance measures.

Itinerary ID identifies the ordered path.
Stop ID + Sequence Number define the stop order.
Time Lapse from Departure point gives cumulative elapsed time.
Time Lapse from Previous point gives segment-level elapsed time.
Distance from starting point and e from previous point support journey and segment calculations.
Service Scheme ID and Exception ID connect the itinerary to the temporal service context.

The ordered physical path of stops (with timing and distance offsets) that a Route follows for a given Service Scheme or Exception.

Field	Description
Region	Administrative region.
City	City of operation.
Agency/Operator ID	Foreign Key → 2851.
Route ID	Foreign Key → 2852.
Service Scheme ID	Foreign Key → 2853, or empty.
Exception ID	Foreign Key → 2854, or empty.
Direction
Branch ID
Itinerary ID	Unique identifier (Primary Key).
Stop ID	Foreign Key → 2857 Stops.
Sequence Number	Order of this stop within the itinerary.
Platform ID	Not empty – only if different from the Platform field of the Stop/Station Segment
Time Lapse from Departure	Elapsed time since the itinerary's first stop.
Time Lapse from Previous Point	Elapsed time since the prior stop.
Distance from Starting Point	Cumulative distance travelled.
Distance from Previous Point	Incremental distance since the prior stop.
Expected Wait/Dwell Time	Expected Wait/Dwell Time
Boarding Policy Text
Alighting Policy Text
Accessible Boarding (Y/N)
Wheelchair Boarding Method
Remarks	Free text.

13. Public Transport Stops / Stations – Segment 2857: INTEGRA treats a PT Stop as a PHYSICAL CIVIC PLACE rather than merely a timetable point. Master registry of every physical stop, platform, station and station-entrance in the network. A STOP SHOULD BE MODELED AS A MICRO CIVIC HUB.

INTEGRA – Stop/Station Data Repository:

Field Name	Description
Region	Broad geographic region containing the stop.
City	City in which the stop is located.
Agency/Operator ID	Owning transport operator identifier.
Stop ID (Station or Stop Unique ID)	Unique identifier (Primary Key).
Stop Short Name	Compact name for apps/monitor schedules/signage, easily identified by passengers and drivers.
Stop Full Name	Locally and touristically clear name.
Stop Full Name/Description	Extended description of the stop.
Stop Name in English	Standardised English rendering.
Platform ID	Identifier of the specific platform or bay.
Stop Latitude Coordinate (GPS Locator)	GPS latitude of the stop.
Stop Longitude Coordinate (GPS Locator)	GPS longitude of the stop.
Road Number	Road on which the stop is situated.
House Number	Nearest building/house number for locating the stop.
Road Section ID	Identifier of the road segment containing the stop.
Lane ID	Identifier of the traffic lane serving the stop.
Number of Loading Places	Number of vehicles that can stop simultaneously.
Public Transport Lane (Y/N)	Whether a dedicated public transport lane exists.
Parking Bulb (Pavement, Sidewalk, Extension, Unknown)	Type of kerb/bulb construction at the stop.
Parking Bulb Length	Physical length of the parking bulb.
Shelter (Unknown, Y, N)	Whether a shelter is present.
Seating (Unknown, Y, N)	Whether seating is present.
Static/Schedule Passenger Information (Unknown, Y, N)	Availability of pre-trip journey-planning information.
Real-Time Passenger Information (Unknown, Y, N)	Availability of live arrival, platform-change, or delay information.
Stop URL	Web page relevant to major stops/stations.
Stop Type	0 – Stop, 1 – Station (Container Stop), 2 – Entry/Exit of Station.
Parent-Station ID	Linked parent station, if applicable (blank or valid Stop ID).
Platform/Row Number	Platform or row designation.
Urban/Regional Zone Number	Fare/zoning classification of the stop's area.
Stop Time Zone	Blank, or full time zone if different from the Agency's.
Type of Service	Scheduled Stop, Request Stop, Pickup Only, Discharge/Set Down Only, or Hail and Ride.
Weekdays Stop	All Days, Weekend/Holidays Only, or Weekdays Only.
STOP PHYSICAL ATTRIBUTES
Stop Entrance Text	Description of the stop's entrance(s).
Boarding Area Text	Description of the passenger boarding area.
Platform Text	Description of the platform layout/condition.
Pavement Condition Text	Condition of the surrounding pavement.
Curb Height	Height of the boarding kerb.
Road Crossing Text	Description of nearby road crossings.
Pedestrian Crossing Text	Description of nearby pedestrian crossings.
Lighting Text	Description of stop lighting.
Drainage Text	Description of drainage provisions.
Weather Protection Text	Description of weather-protection features.
Surface Type Text	Type of ground surface at the stop.
Maintenance Conditions Text	General upkeep/maintenance state of the stop.
STOP ACCESSIBILITY ATTRIBUTES
Step-Free Access Text	Description of step-free access provisions.
Wheelchair Access Text	Description of wheelchair access provisions.
Tactile Paving Text	Description of tactile paving for visually impaired users.
Tactile Information Text	Description of tactile information provisions.
Audio Announcements Text	Description of audio announcement facilities.
Visual Announcements Text	Description of visual (screen/display) announcement facilities.
Hearing Loop Text	Description of hearing-loop provisions.
Accessible Boarding Text	Description of accessible boarding arrangements.
Accessible Toilet Text	Description of accessible toilet facilities.
Accessible Toilet Picture	Image of the accessible toilet.
Accessibility Rating	Overall accessibility rating/score of the stop.
Assistance Availability and Facilities Text	Description of staff/assistance availability.
STOP PASSENGER FACILITIES
Seating Capacity	Number of seats available.
Shelter Capacity	Number of people the shelter can accommodate.
Lighting Text	Description of passenger-area lighting.
Wi-Fi Text	Description of Wi-Fi availability.
USB Charging Text	Description of USB charging facilities.
USB Charging Picture	Image of the USB charging point.
Drinking Water Text	Description of drinking-water availability.
Drinking Water Picture	Image of the drinking-water facility.
Waste Bin Text	Description of waste-bin provisions.
Bicycle Parking Text	Description of bicycle parking facilities.
Bike-Share Text	Description of nearby bike-share facilities.
Taxi Connection Text	Description of taxi rank/connection facilities.
Kiss-and-Ride Text	Description of the short-stop drop-off/pick-up area.
Park-and-Ride Text	Description of park-and-ride facilities.
Retail and Commerce Text	Description of nearby retail/commercial facilities.
Food/Drink Text	Description of nearby food/drink outlets.
Public Toilet Text	Description of public toilet facilities.
Public Toilet Picture	Image of the public toilet.
STOP SAFETY FACILITIES
Emergency Phone Text	Description of emergency phone availability.
CCTV Text	Description of CCTV coverage.
Emergency Lighting Text	Description of emergency lighting provisions.
AED Text	Description of automated external defibrillator availability.
AED Picture	Image of the AED unit.
First Aid Text	Description of first-aid facilities.
Security Presence Text	Description of on-site security presence.
Emergency Information Text	Description of emergency information signage/procedures.
Fire Equipment Text	Description of fire-safety equipment.
Fire Equipment Picture	Image of the fire-safety equipment.
STOP SOCIAL AND CIVIC FUNCTIONS
Community Facilities Text	Description of nearby community facilities.
Public Notice Board	Description of public notice-board provisions.
Local Information Text	Description of local information displays.
Social/Meeting Area Text	Description of social or meeting areas.
Green Space Text	Description of nearby green space.
Green Space Picture	Image of the nearby green space.
Children's Facilities Text	Description of children's facilities.
Children's Facilities Picture	Image of the children's facilities.
Elderly-Friendly Facilities Text	Description of elderly-friendly facilities.
Nearby Services Text	Description of nearby general services.
Nearby Schools Text	Description of nearby schools.
Nearby Health Services Text	Description of nearby health services.
Nearby Shopping Text	Description of nearby shopping facilities.
Nearby Leisure Text	Description of nearby leisure facilities.
Nearby Employment Centres Text	Description of nearby employment centres.
Nearby Public Facilities Text	Description of other nearby public facilities.
Remarks	Free-text notes on the stop.
Picture	General photograph of the stop.

Rather than putting dozens of STOP / STATION attributes directly into the main Stop segment (2857) you may create, with INTEGRA, separate repositories under the Stop/Station segment: This allows an unlimited number of facilities to be associated with a stop or station without continually expanding the Stop/Station segment or table (2857).

INTEGRA – Stop/Station Connections – Segment 28571:

Field Name	Description
Region	Broad geographic region containing the stop.
City	City in which the stop is located.
Agency/Operator ID
, From Stop ID
To Stop ID
From Route ID
To Route ID
Transfer Type	Examples: Bus → Metro, Metro → Train, Train → Bus, Bus → Ferry, Bus → Bike-share, Train → Taxi. This is especially valuable for: Seniors, Wheelchair users, People with reduced mobility, Parents with children, People carrying luggage, People with visual or hearing impairments.
Walking Distance (in Metres),
Walking Time
Minimum Transfer Time
Accessible Transfer	(Y/N)
Accessible Route Text
Covered Transfer	(Y/N)
Same Platform	(Y/N)
Transfer Guarantee	(Y/N)
Stairs	(Y/N)
Direction
Elevators Text
Elevators Pictures
Escalators Text
Pedestrian Crossing Text
Surface Text
Lighting Text
Safety Text
Weather Protection Text
Remarks
Pictures

INTEGRA – Stop/Station Facilities – Segment 28572:

Region
City
Agency/Operator ID
Stop ID
Facility ID
Facility Name
Facility Type
Quantity
Availability Text
Condition Text
Accessibility Text
Opening Hours Text
Start Date
End Date
Remarks
Pictures

INTEGRA – Service Alerts / Disruptions relating (also) to Public Transport Stops/Stations - Segment 2858:

Field Name	Description
Alert ID	Unique identifier assigned to the alert record.
Alert Subject/Category	Subject area the alert pertains to. Values: Authority/Agency, Operator, Route/Line, Service Scheme, Exception to Service Scheme, Itinerary, Actual Trip, Stop / Station, Vehicle, Crew Member, Infrastructure, Fares.
Alert Type	Nature of the event triggering the alert. Values: Accident, Cancellation, Delay, Diversion, Emergency, Human Factor, Infrastructure Failure, Overcrowding, Platform Changed, Security Event, Station Closed, Stop Closed, Strike, Vehicle Breakdown, Weather.
Agency ID	Identifier of the authority/agency associated with the alert.
Operator ID	Identifier of the operator associated with the alert.
Route ID	Identifier of the route/line associated with the alert.
Service Scheme ID	Identifier of the service scheme associated with the alert.
Exception ID	Identifier of the exception to the service scheme associated with the alert.
Actual Trip ID	Identifier of the actual trip associated with the alert.
Stop ID	Identifier of the stop/station associated with the alert.
Vehicle ID	Identifier of the vehicle associated with the alert.
Responsible Person ID	Identifier of the crew member or responsible person associated with the alert.
Start Date/Time	Date and time at which the alert condition began.
End Date/Time	Date and time at which the alert condition ended.
Planned/Unplanned	Indicates whether the event was planned in advance or occurred unexpectedly.
Severity	Level of impact or seriousness associated with the alert.
Cause	Underlying cause of the event that triggered the alert.
Effect	Impact or consequence of the event on service.
Description Text	Free-text narrative describing the alert in detail.
Replacement Service Text	Free-text description of any replacement service arranged.
Alternative Route Text	Free-text description of any alternative route offered.
Citizen Notification Notes	Notes regarding communication of the alert to the public.
Status	Current state of the alert (e.g., open, in progress, closed).
Resolution Date/Time	Date and time at which the alert was resolved.
Remarks	Additional free-text remarks related to the alert.
Pictures	Images or photographic evidence associated with the alert.

INTEGRA – Service Feedback by Citizens - relating (also) to Public Transport Stops/Stations - Segment 2859:

Field Name	Description
Feedback Subject/Category	Subject area of the feedback pertains to. values: Authority/Agency, Operator, Route/Line, Service Scheme, Exception to Service Scheme, Itinerary, Actual Trip, Stop / Station, Vehicles, Crew Member, Infrastructure, Fares.
Citizen ID	Unique identifier of the citizen submitting the feedback.
Date/Time	Date and time at which the feedback was submitted.
Feedback ID	Unique identifier assigned to the feedback record.
Feedback Type	Nature of the feedback submitted. Values: Complaint, Recommendation, Request, Query, Suggestion, Warning.
Authority/Agency ID	Identifier of the authority/agency associated with the feedback.
Operator ID	Identifier of the operator associated with the feedback.
Route ID	Identifier of the route/line associated with the feedback.
Service Scheme ID	Identifier of the service scheme associated with the feedback.
Exception ID	Identifier of the exception to the service scheme associated with the feedback.
Actual Trip ID	Identifier of the actual trip associated with the feedback.
Stop ID	Identifier of the stop/station associated with the feedback.
Vehicle ID	Identifier of the vehicle associated with the feedback.
Responsible Person ID	Identifier of the crew member or responsible person associated with the feedback.
Case/Event Type	Specific issue or topic the feedback relates to. Values: Accessibility Problem, Cleanliness, Crowding, Delay, Driver Behaviour, Information Problem, Missing Service, Suggested New Route, Suggested New Stop, Suggested Timetable Change, Unsafe Stop.
Status	Current state of the feedback case (e.g., open, in progress, closed).
Feedback Description Text	Free-text narrative provided by the citizen describing the feedback in detail.
Pictures	Images or photographic evidence submitted by the citizen with the feedback.
Response Date	Date and time at which the transport authority responded to the feedback.
Authority Response Text	Free-text response provided by the transport authority to the citizen.
Response Pictures	Images or photographic evidence attached by the transport authority to its response.
Response Remarks	Additional free-text remarks related to the authority's response or case handling.

14. Planned and Actual Public Transport Trips: 28560/28561 segments describe what Trips were supposed to happen. 28567/28568 segments describe what actually happened. Together they provide a clean historical record for operational performance, citizen-facing real-time information, accessibility monitoring, service reliability and planned-vs-actual analysis.

28560 Planned Trip Header → 28561 Planned Trip Details → 28567 Actual Trip Header → 28568 Actual Trip Details

28565 Vehicles Table is referenced by both planned and actual trips. The Planned Trip ID provides the bridge between what was scheduled and what actually operated.

28560 — Planned Trips — Header:

#	Field Name	Data Type	Mand.	Example / Allowed Values
1	Region	Text	Y	Ticino
2	City	Text	Y	Lugano
3	Agency/Operator ID	ID	Y	LUG-OP-001
4	Date	Date	Y	2026-09-08
5	Route ID	ID	Y	LUG-RT-001
6	Itinerary ID	ID	Y	LUG-IT-001
7	Direction	Enum	Y	Outbound / Inbound
8	Branch ID	ID	N	LUG-BR-01
9	Service Scheme ID	ID	Y	LUG-SS-WD
10	Exception ID	ID	N	None
11	Planned Trip ID	Unique ID	Y	PT-LUG-20260908-00184
12	Vehicle ID	Foreign ID	Y	LUG-V-024
13	Driver ID	Foreign ID	N	LUG-DRV-081
14	Driving License ID	Foreign ID	N	LIC-CH-XXXX
15	Visa/Trip Permission ID	Foreign ID	N	PERMIT-001
16	Planned Arrival Time	Date/Time	Y	08:45
17	Planned Departure Time	Date/Time	Y	08:15
18	Expected Number of Passengers in Departure	Integer	N	42
19	Expected Number of Stops	Integer	Y	18
20	Allowed Number of Passengers (ANOP)	Integer	Y	85
21	Wheelchair Access	Enum	Y	Unknown / Yes / No
22	Pets Access	Enum	Y	Unknown / Yes / No
23	Smoking	Enum	Y	Unknown / Allowed / Prohibited
24	Luggage	Enum	Y	Unknown / Allowed / Prohibited
25	Bikes	Enum	Y	Unknown / Allowed / Prohibited
26	Firearms	Enum	Y	Unknown / Allowed / Prohibited
27	Air-Condition	Enum	Y	Unknown / Yes / No
28	Separate Luggage Compartment	Enum	Y	Unknown / Yes / No
29	Cash Payment to Driver or Conductor	Enum	Y	Unknown / Yes / No
30	WC Cabin	Enum	Y	Unknown / Yes / No
31	Medical Aid Text/Defibrillator	Text	N	AED available
32	Drinking Water Text	Text	N	Emergency supply
33	Fire-extinguishing Equipment Text	Text	N	2 extinguishers
34	Tire Repair Equipment Text	Text	N	Standard repair kit
35	Warning & Emergency Equipment Text	Text	N	Emergency kit
36	GPS Tracking Available	Boolean	Y	Y
37	Passenger Counting Available	Boolean	Y	Y
38	Real-time Remarks/Alerts Text	Text	N	Heavy traffic expected
39	Remarks	Text	N	—

28561 — Planned Trips — Details:

#	Field Name	Data Type	Mand.	Example / Allowed Values
1	Planned Trip ID	Foreign ID	Y	PT-LUG-20260908-00184
2	Date	Date	Y	2026-09-08
3	Stop ID	Foreign ID	Y	LUG-ST-014
4	Sequence Number	Integer	Y	7
5	Type of Service	Enum	Y	Scheduled Stop – always stops
6	Stopped	Boolean	Y	Y
7	Planned Arrival Time	Date/Time	Y	08:27
8	Planned Departure Time	Date/Time	Y	08:28
9	Planned Platform/Row Number	Text	N	Platform B
10	Planned Average Number of Waiting Passengers	Integer	N	8
11	Already Known Special Requests of Waiting Passengers	Text	N	Wheelchair boarding
12	Planned Distance from Previous Stop	Decimal	N	0.8 km
13	Planned Cumulative Distance	Decimal	N	4.6 km
14	Remarks	Text	N	—

28565 — Vehicles:

	#	Field Name		Data Type		Mand.		Example / Allowed Values
	1	Operator ID		ID		Y		LUG-OP-001
	2	Vehicle ID		ID		Y		LUG-V-024
	3	Fleet Number		Unique Text		Y		F-024
	4	Registration Number		Text		Y		TI-123456
	5	Vehicle Type		Reference		Y		Electric Bus
	6	Manufacturer		Text		Y		Solaris
	7	Model		Text		Y		Urbino 12 Electric
8			Capacity of Seats		Integer		Y		42
	9	Capacity of Passengers		Integer		Y		85
	10	Wheelchair Capacity		Integer		N		2
	11	Bicycle Capacity		Integer		N		4
	12	Fuel/Energy Type		Enum		Y		Electric
	13	Air Conditioning (Y/N)		Boolean		Y		Y
	14	Wi-Fi (Y/N)		Boolean		N		Y
	15	USB Charging (Y/N)		Boolean		N		Y
	16	CCTV (Y/N)		Boolean		Y		Y
	17	Audio Information (Y/N)		Boolean		Y		Y
	18	Visual Information / Monitors (Y/N)		Boolean		Y		Y
	19	Low-Floor (Y/N)		Boolean		Y		Y
	20	Accessibility Rating		Rating		N		Excellent
	21	Current Status		Enum		Y		In Service
	22	Vehicle Age		Decimal		N		3 years
	23	Maintenance Status		Enum		Y		Up to Date
	24	Last Maintenance Date		Date		N		2026-08-21
	25	Remarks		Text		N		—
	26	Pictures		Media		N		Vehicle images

28567 — Actual Trips — Header:

#	Field Name	Data Type	Mand.	Example / Allowed Values
1	Region	Text	Y	Ticino
2	City	Text	Y	Lugano
3	Agency/Operator ID	ID	Y	LUG-OP-001
4	Date	Date	Y	2026-09-08
5	Route ID	ID	Y	LUG-RT-001
6	Itinerary ID	ID	Y	LUG-IT-001
7	Direction	Enum	Y	Outbound
8	Branch ID	ID	N	LUG-BR-01
9	Service Scheme ID	ID	Y	LUG-SS-WD
10	Exception ID	ID	N	None
11	Planned Trip ID	Foreign ID	Y	PT-LUG-20260908-00184
12	Actual Trip ID	Unique ID	Y	AT-LUG-20260908-00184
13	Actual Vehicle ID	Foreign ID	Y	LUG-V-024
14	Actual Driver ID	Foreign ID	N	LUG-DRV-081
15	Driving License ID	Foreign ID	N	LIC-CH-XXXX
16	Visa/Trip Permission ID	Foreign ID	N	PERMIT-001
17	Planned vs. Actual Trip Summarized Status	Enum	Y	Completed – Late
18	Actual Departure Time	Date/Time	Y	08:17
19	Actual Arrival Time	Date/Time	Y	08:45
20	Actual Departure Time Delay (min.)	Integer	Y	+2
21	Actual Arrival Time Delay (min.)	Integer	Y	+3
22	Actual Number of Passengers at Departure	Integer	N	46
23	Actual Number of Stops Served	Integer	Y	18
24	Actual Medical Aid Text/Defibrillator	Text	N	AED available
25	Actual Drinking Water Text	Text	N	Available
26	Actual Fire-extinguishing Equipment Text	Text	N	2 extinguishers
27	Actual Tire Repair Equipment Text	Text	N	Available
28	Actual Warning & Emergency Equipment Text	Text	N	Available
29	Actual Remarks/Alerts/Accidents/Incidents Text	Text	N	Traffic delay
30	Actual Fuel Consumption	Decimal	N	42.6 kWh
31	Actual Total Distance	Decimal	N	10.1 km
32	Actual Total Payments/Income	Decimal	N	CHF 86.50
33	Total Expenditures	Decimal	N	CHF 21.00
34	Cancellation Reason Text	Text	N	Empty
35	Diversion Type and Reason Text	Text	N	Empty
36	Data Provider ID	Foreign ID	Y	AVL-LUG-01
37	Actual Remarks	Text	N	No safety incident
38	Actual Pictures	Media	N	Trip images

28568 — Actual Trips — Details:

#	Field Name	Data Type	Mand.	Example / Allowed Values
1	Actual Trip ID	Foreign ID	Y	AT-LUG-20260908-00184
2	Date	Date	Y	2026-09-08
3	Stop ID	Foreign ID	Y	LUG-ST-014
4	Sequence Number	Integer	Y	7
5	Type of Actual Service	Enum	Y	Stop – Always
6	Stopped	Boolean	Y	Y
7	Actual Arrival Time	Date/Time	Y	08:28
8	Actual Departure Time	Date/Time	Y	08:29
9	R/T Platform/Row Number	Text	N	Platform B
10	R/T Number of Waiting Passengers	Integer	N	11
11	R/T Number of Pick-up/Boarding Passengers	Integer	N	7
12	R/T Number of Discharge/Drop-off Passengers	Integer	N	4
13	R/T Number of Onboard Passengers	Integer	N	49
14	R/T Special Requests of Waiting Passengers at Following Stops	Text	N	Wheelchair boarding at next stop
15	R/T Income	Decimal	N	CHF 12.50
16	Arrival Delay (min.)	Integer	N	+1
17	Departure Delay (min.)	Integer	N	+1
18	Actual Dwell Time (min.)	Decimal	N	1.0
19	Stop Served Y/N	Boolean	Y	Y
20	Stop Skipped Reason	Text	N	Empty
21	GPS Latitude	Decimal	N	46.0000
22	GPS Longitude	Decimal	N	8.9500
23	Actual Distance from Previous Stop	Decimal	N	0.82 km
24	Actual Cumulative Distance	Decimal	N	4.68 km
25	Wheelchair Boarding Y/N	Boolean	N	Y
26	Bicycle Boarding Y/N	Boolean	N	N
27	Real-Time Passenger Information Published Y/N	Boolean	N	Y
28	Incident/Accident Y/N	Boolean	Y	N
29	Incident Description	Text	N	Empty
30	Data Provider ID	Foreign ID	Y	AVL-LUG-01
31	Remarks	Text	N	Normal stop operation

Trip Headers contain the essential information defining the trip - such as route, direction, branch, date, planned times, and trip identification - while Trip Details document the trip at the level of every individual stop or station, enabling the planned journey to be compared with what actually happened. A key distinction is the role of citizens in Planned and Actual Trips.

Citizens are not merely passengers receiving transport information. They become a distributed source of real-world information about the trip. Before and during a journey, they can provide feedback, complaints, suggestions, and reports - including information about waiting passengers at forthcoming stops, anticipated disruptions, incidents, delays, or other conditions that may affect the trip. This citizen-generated information can complement the information supplied by transport agencies and operators and contribute to a continuously updated picture of the Actual Trip.

At the same time, citizens have a passive information role: INTEGRA PTIM provides them with relevant trip information in advance and in real time, including planned services, upcoming stops, expected arrivals, changes, delays, disruptions, and other information relevant to their journey.

Thus, : INTEGRA PTIM creates a two-way citizen–trip information cycle:

PLANNED TRIP → CITIZEN INFORMATION & FEEDBACK → ACTUAL TRIP → UPDATED CITIZEN INFORMATION

The result is not another operational transport-management system. INTEGRA PTIM is a citizen-facing information and participation module that connects the planned and actual dimensions of public transport, giving citizens both a voice in the trip and timely information about the trip.

15. Actual passenger situation along an actual trip:

The following two segments (28575+28577), complementary, are citizen-generated information streams:

28575 - WAITING OUTSIDE THE VEHICLE: Citizen → “People are waiting here.”

28577 - PEOPLE INSIDE THE VEHICLE: Citizen → “This is how full the vehicle is now.”

Together they allow INTEGRA PTIM to construct something that conventional transport databases generally do not have:

A citizen-generated, continuously evolving picture of the actual passenger situation along an actual trip. The citizen is not merely the consumer of transport information. The citizen becomes a real-time participant in documenting what is actually happening.

28575 — Waiting Passengers Alerts:

This segment can distinguish and report, in real-time, how long people have already been waiting, the size of the queue, and whether the situation is still developing. Actual Trip ID + Stop ID + Reporting Time is the core key/linkage. This means that a series of citizen reports can build a time-dependent picture of the queue at a specific stop during a specific Actual Trip or Journey. Example: Actual Trip 4587 → Stop 1254 → 18:05: 7 passengers → 18:12: 14 passengers → 18:19: 23 passengers. This is considerably more powerful than simply storing “23 people are waiting.”

No.	Field Name	Definition / Values
1	Region	Region in which the reported stop is located.
2	City	City in which the reported stop is located.
3	Agency/Operator ID	Identifier of the relevant transport agency/operator.
4	Route ID	Identifier of the route/line of the Actual Trip.
5	Actual Trip ID	Unique identifier of the actual trip already in operation.
6	Stop ID	Unique identifier of the station or stop.
7	Citizen ID	Identifier of the citizen submitting the report.
8	Reporting Timestamp (Date + Time)	Date and time at which the citizen reports the situation.
9	Start Waiting Timestamp (Date + Time)	Estimated date and time when waiting passengers began waiting.
10	Accumulated Waiting Time	Waiting duration accumulated at the reporting timestamp.
11	Estimated Number of Waiting Passengers	Estimated number of passengers waiting, including the reporting passenger.
12	Estimated Additional Passengers Arriving (Optional)	Optional estimate of additional passengers joining the queue.
13	Expected Arrival Timestamp (Date + Time) (if known)	Expected arrival date and time of the relevant trip, if known.
14	Trip Status on Reporting	Active/Running; Delayed; Cancelled; Interrupted; Unknown.
15	Alert Status	Active; Resolved; Unknown.
16	Remarks	Additional citizen observations, comments, or relevant circumstances.

28577 — Public Transport (Intercity Buses) Occupancy:

This segment concerns a vehicle already in motion, the structure captures the observation point in the trip and distinguish occupancy from remaining capacity.

No.	Field Name	Definition / Values
1	Region	Region in which the reported stop is located.
2	City	City in which the reported stop is located.
3	Agency/Operator ID	Identifier of the relevant transport agency/operator.
4	Route ID	Identifier of the route/line of the Actual Trip.
5	Actual Trip ID	Unique identifier of the actual trip already in operation.
6	Stop ID	Unique identifier of the station or stop.
7	Citizen ID	Identifier of the citizen submitting the report.
8	Reporting Timestamp (Date + Time)	Date and time at which the citizen reports the situation.
9	Start Waiting Timestamp (Date + Time)	Estimated date and time when waiting passengers began waiting.
10	Accumulated Waiting Time	Waiting duration accumulated at the reporting timestamp.
11	Estimated Number of Waiting Passengers	Estimated number of passengers waiting, including the reporting passenger.
12	Estimated Additional Passengers Arriving (Optional)	Optional estimate of additional passengers joining the queue.
13	Expected Arrival Timestamp (Date + Time) (if known)	Expected arrival date and time of the relevant trip, if known.
14	Trip Status on Reporting	Active/Running; Delayed; Cancelled; Interrupted; Unknown.
15	Alert Status	Active; Resolved; Unknown.
16	Remarks	Additional citizen observations, comments, or relevant circumstances.

16. INTEGRA PTIM turns fare information into a civic service that answers three practical questions in one place: “Who am I as a passenger?”, “What exactly am I purchasing?”, and “How much will this journey cost—and under what conditions?” The model connects passenger groups, fare products, fare rules, concession policies and payment methods with the actual route, zones or stops and the applicable price. It, therefore, presents a citizen with a clear, journey-specific fare explanation, including concessions, transfers, validity, payment options and the period during which the price is valid. Transport authorities and operators remain the authoritative owners of fares; INTEGRA provides the civic, citizen-facing layer that makes those rules easier to understand, compare and use.

Segments included:

28590 - Fare Groups
28591 - Fare Products
28592 - Fare Rules
28593 - Fare Concessions Policies
28594 - Ticketing/Payment Methods
28595 – Public Transport Prices List.

The six complementary fare segments

These structures deliberately separate concepts that are often mixed together: who pays, what is purchased, under what rule, who receives a concession, how payment is made, and the final price applicable to a journey. This separation allows PTIM to construct a transparent fare answer without embedding commercial rules directly inside routes or trips.

28590. Fare Groups — Who pays?

Field / Attribute	Citizen / Data Purpose	Example Entry
Region	Geographic scope of the record.	Central Region
City	City in which the fare information applies.	Singapore
Agency ID	Transport agency responsible for the fare information.	SG-TA
Operator ID	Operator associated with the fare information.	TT-SMRT
Group ID	Stable identifier for the passenger group.	FG-SEN
Group Name	Citizen passenger category.	(Adult, Child, Handicapped, Military, Senior, Student, Pupil, Person with Disability, Veteran, Other)
Text	Citizen-facing explanation.	Eligible senior passenger category

28591. Fare Products — Which Journey/Journeys is/are Purchased? What is being purchased?

Field / Attribute	Citizen / Data Purpose	Example Entry
Region	Geographic scope of the record.	Central Region
City	City in which the fare information applies.	Singapore
Agency ID	Transport agency responsible for the fare information.	SG-TA
Operator ID	Operator associated with the fare information.	TT-SMRT
Product ID	Stable identifier for the fare product.	FP-MONTH
Product Name	What the passenger purchases.	Single Journey, Return Journey, Day Pass, Weekly Pass, Monthly Pass, Annual Pass, Tourist Pass, Special Event Pass
Text	Citizen-facing explanation.	Unlimited travel under the applicable monthly-pass conditions

28592. Fare Rules — Under what conditions is the fare implemented?

Field / Attribute	Citizen / Data Purpose	Example Entry
Region	Geographic scope of the record.	Central Region
City	City in which the fare information applies.	Singapore
Agency ID	Transport agency responsible for the fare information.	SG-TA
Operator ID	Operator associated with the fare information.	TT-SMRT
Rule ID	Stable identifier for the fare rule.	FR-ZONE
Rule Name	Condition governing fare application.	Zone, Distance, Time, Transfer, Transport Mode, Route, Origin/Destination
Text	Citizen-facing explanation.	Fare determined by origin and destination zones

28593. Fare Concession Policy — Who receives a discount or free travel?

Field / Attribute	Citizen / Data Purpose	Example Entry
Region	Geographic scope of the record.	Central Region
City	City in which the fare information applies.	Singapore
Agency ID	Transport agency responsible for the fare information.	SG-TA
Operator ID	Operator associated with the fare information.	TT-SMRT
Concession ID	Stable identifier for the concession policy.	FC-SEN
Concession Group (Person with Disability, Senior, Student, Pupil, Child, National Service)	Passenger category receiving concession.	Senior
Eligibility/Condition (Student Card, ID Card, Military Card)	Evidence/condition for concession entitlement.	Senior Citizen Concession Card
With/Without Photo?	Identifier or classification used to connect the fare records.	With Photo
Fare Basis	Journey or usage basis of concession.	Single Journey, Daily, < 5 km
Transit Type	Transport mode/service scope.	(Bus only, Bus + Rail, Bus + Metro + Tram, Metro + Rail
Text	Citizen-facing explanation.	Eligible senior concession

28594. Ticketing / Payment Methods — How can the citizen pay?

Field / Attribute	Citizen / Data Purpose	Example Entry
Region	Geographic scope of the record.	Central Region
City	City in which the fare information applies.	Singapore
Agency ID	Transport agency responsible for the fare information.	SG-TA
Operator ID	Operator associated with the fare information.	TT-SMRT
Transit Type (Table 28515) or empty	Transport mode/service scope.	Bus
Route ID or empty	Optional route-specific scope.
Payment Method ID	Stable identifier for the payment method.	PM-CONTACTLESS
Payment Method Name	Available way to pay.	Account-Based Ticketing, Cash, Bank Card, Contactless, Mobile, Operator, QR Code, Smart Card
Valid From Date	Temporal validity.	2026-01-01
Remarks	Citizen-facing explanation.	Available on applicable services

28595. Public Transit Prices List — What is the final applicable price?

Field / Attribute	Citizen / Data Purpose	Example Entry
Region	Geographic scope of the record.	Central Region
City	City in which the fare information applies.	Singapore
Price ID	Stable identifier for the applicable price record.	P-SEN-BUS
Price Name	Human-readable label.	Senior Single Journey
Price Description	Citizen-facing explanation.	Concession fare for senior passenger
Agency ID	Transport agency responsible for the fare information.	SG-TA
Operator ID	Operator associated with the fare information.	TT-SMRT
Payment Methods List Text	Payment options available for this price.	Contactless, Bank Card, Smart Card
Route ID or empty	Optional route-specific scope.	SMRT922
From Urban/Regional Zone Number or empty	Optional spatial fare boundary.	1
To Urban/Regional Zone Number or empty	Optional spatial fare boundary.	1
From Stop ID or empty	Optional stop-specific fare boundary.	JE01
To Stop ID or empty	Optional stop-specific fare boundary.	JE08
Group ID or empty	Identifier or classification used to connect the fare records.	FG-SEN
Product ID or empty	Identifier or classification used to connect the fare records.	FP-SINGLE
Rule ID or empty	Identifier or classification used to connect the fare records.	FR-ZONE
Concession ID or empty	Identifier or classification used to connect the fare records.	FC-SEN
Price	Monetary amount applicable.	1.00
Currency	Currency of the price.	SGD
Start Date + Time	Temporal validity.	2026-01-01 00:00
End Date + Time	Temporal validity.	2026-12-31 23:59
Remarks Text	Citizen-facing explanation.	Illustrative example – verify against authoritative tariff

Citizen question	INTEGRA PTIM response
Who pays?	28590 Fare Groups identifies the passenger category.
What am I buying?	28591 Fare Products identifies the journey/pass purchased.
Under what conditions?	28592 Fare Rules defines zone, distance, time, transfer, mode, route or origin/destination conditions.
Do I receive a concession?	28593 Fare Concession Policy identifies entitlement and eligibility conditions.
How can I pay?	28594 Ticketing / Payment Methods identifies the available payment channels.
How much will I pay?	28595 Public Transit Prices List combines the applicable references and publishes the price, currency and validity period.

How the six segments work together?

Important modelling principle: segment 28595 should be treated as the citizen-facing price outcome, while 28590-28594 provide the reusable building blocks that explain why that price applies. This keeps the fare model modular, traceable and suitable for journey-specific civic information.

17. The Second Challenge – Demand-Related Transport. The second PTIM development stream is fundamentally different. it starts with: "What transportation do citizens need?" This requires the creation of a new type of information resource: a structured database of transportation needs, preferences, habits and unmet demand. The system should be capable of documenting not only current public transportation usage, but also latent or suppressed demand.

For example:

A citizen may currently travel by private car because no suitable public transportation exists.

Another citizen may depend on relatives because the available service does not operate at the required time.

Another may be willing to use public transportation if walking distance, travel time, number of transfers, accessibility or departure flexibility were improved.

Such citizens represent transportation demand even though they may not appear in conventional public transportation passenger statistics.

Therefore:

Observed usage is not the same as actual demand.

This distinction is fundamental to DRT.

18. Four Stages of Computerized Demand-Responsive Transport Development:

The development of the PTIM module should proceed through four clearly defined and progressively more intelligent stages. The objective is not to design Demand-Responsive Transport (DRT) services immediately, but first to build a reliable understanding of how citizens travel, what transportation services already exist, where the deficiencies are, and finally what new or modified services could address those deficiencies.

This staged approach substantially reduces development risk while allowing INTEGRA to transform raw citizen information into actionable transportation intelligence.

18.1 Stage 1 – Research and Questionnaires: Understanding the Citizen:

18.1.1. PTIM (segments 2873 &2874), PIM (segment 1055) & FIM (segment 07018) begin by collecting structured information about citizens' transportation habits, preferences, requirements, constraints and unmet needs. This information should be obtained primarily through carefully designed questionnaires and through the complementary information already available in the PIM – Personal Information Manager and FIM – Family Information Manager.

PIM and FIM provide an important foundation because transportation requirements are rarely isolated from everyday life. Home location, workplace, educational institutions, family composition, regular activities, vehicle availability, accessibility requirements, hobbies and other recurring activities can all contribute to understanding mobility needs.

18.1.2 The PTIM questionnaires investigate, further, among other factors:

Origin and destination
Frequency of travel
Preferred days and times
Departure and arrival-time flexibility
Purpose of travel
Current transportation mode
Preferred transportation mode
Walking-distance tolerance
Maximum acceptable travel time
Number of acceptable transfers
Accessibility requirements
Companion requirements
Regular versus occasional journeys
Existing transportation problems
Willingness to use a proposed DRT service

The result is a growing Citizen Transportation Demand Database.

At this stage, INTEGRA is not yet attempting to determine the optimal transportation solution. Its purpose is to discover and document the demand.

Citizen → Family → Mobility Profile → Transportation Requirement.

18.1.3 The Living Mobility Profile - A New Way of Understanding Urban Transportation:

The INTEGRA PTIM – DRT mobility dataset is not a static database segment. It is a continuously updated, living record of the mobility and public-transportation needs of every citizen and family -maintained day by day and reflecting their actual, changing patterns of movement.

It captures both regular and recurring mobility needs (segment 2873) and one-time or exceptional journeys (segment 2874), creating an up-to-date picture of how, when, where, why, and under what conditions people need to travel.

This continuous reflection of mobility needs creates an enormous opportunity for economic savings and greater efficiency - for individuals, families, communities, and the city as a whole. By identifying recurring patterns, unused capacity, shared needs, and opportunities for better-matched transportation services, INTEGRA can help reduce unnecessary travel costs and improve the utilization of existing and future public-transport resources.

More importantly, it can lead to a fundamental change in the way a city understands and manages mobility: moving from transportation that is planned primarily around existing services and infrastructure, toward transportation that is increasingly planned around the real, continuously evolving needs of its citizens.

The result is more than a better transportation system. It is an opportunity for higher quality of life, greater economic efficiency, reduced waste, better accessibility, and a new way of thinking about urban mobility.

18.1.4. From Individual Requests to Collective Transport Intelligence: Imagine that a civic digital system continuously receives mobility requirements from citizens and families. For example:47 citizens → 52 mobility requests → 236 journeys per month. This may reveal a previously invisible transportation pattern between two locations. Individually, each request may appear too small to justify a new service. Collectively, however, the requests may reveal: A missing bus stop, A missing connection, A new route opportunity, A demand-responsive transport opportunity, A better transfer location, A need for a larger vehicle, A need for evening/night service, A seasonal service, A new station, A relocation of an existing stop

This is where a citizen-centric information system such as INTEGRA can add an entirely different dimension to public transport planning.

The route, itinerary, stop…and trip become the physical manifestation of aggregated citizen mobility demand.

18.1.5. Citizen Requests Should Become a Planning Input: Citizens should not merely complain when a stop is missing. They should be able, constantly, to submit structured mobility requirements such as: "I need to travel from A to B." with: Origin, Destination, Date/Dates, Time/Times, Frequency, Number of passengers, Family members, Accessibility requirements, Preferred transport mode, Regular/Recurring/one-time requirement. When thousands of such requests are aggregated, the city gains something enormously valuable: A continuously updated map of actual mobility needs. This information can be compared with the existing transport network. The gaps become visible.

18.2 Stage 2 – Aggregation: Building Public Transportation Demand Patterns

Once sufficient individual information has been collected, the second stage is aggregation and pattern recognition.

Individual questionnaire responses and relevant PIM/FIM information are transformed into meaningful transportation groups and trends.

The objective is to move from individual records to an understanding of collective demand.

For example, PTIM may discover groups of citizens who:

Travel from the same neighbourhood toward the same employment area.
Require transportation during similar time periods.
Regularly travel to the same hospital, university, shopping area or public facility.
Have similar accessibility requirements.
Currently use private vehicles because public transportation is inconvenient.
Would use public transportation if the walking distance were reduced.
Require transportation at times when conventional services are unavailable.
Make occasional trips that create significant but irregular demand.

The system therefore progressively constructs Public Transportation Demand Groups and Transportation Demand Trends. PTIM discovers much more valuable than “47 people live in Niederrad, Frankfurt.”. It discovers: “47 potential passengers repeatedly need to travel from this specific origin cluster to this specific destination cluster on Monday mornings for work, within a defined time window, with insufficient existing PT service and significant willingness to use a DRT service.” That is the point at which the aggregate becomes a transport-demand object rather than merely a statistical report.

And this dataset can then become the direct input to Stage 3 — Gap Analysis, followed by Stage 4 — DRT/TDM Solution Construction.

These aggregate groups should be dynamic rather than static. As additional information is collected, the groups and trends should evolve.

The fundamental transformation is:

Individual Demand → Aggregated Demand → Transportation Trends → Demand Groups

This stage converts the PTIM database from a collection of individual questionnaire responses into a meaningful city-wide transportation demand map. For example:

AGG-000184,Niederrad,Bruchfeldstraße 72,Frankfurt,Workplace,Frankfurt Airport,MONDAY,07:30-08:30,Job,Recurring,Public Transport,Very,Moderate,47 citizens,31 households,6.4 km,35 minutes,2 transfers,400 meters,DRT Priority 92.

Demand-Responsive Public Transport Patterns in Hamburg – by Travel Purposes:

Demand-Responsive Public Transport Patterns in Hamburg – by Type of Transit:

Demand-Responsive Public Transport Patterns in Antwerp – by Age Groups:

Demand-Responsive Public Transport Patterns in Hamburg – by Type of Transit:

18.3 Stage 3 – Gap Analysis: Comparing Demand with Existing Public Transportation

The third stage is Supply–Demand Gap Analysis.

The aggregated transportation demand identified in Stage 2 must now be compared with the existing public transportation system.

PTIM therefore integrates relevant information about existing transportation supply, including operators, lines, routes, stops, stations, timetables, journeys, frequencies, vehicle capacities, fares, accessibility, geographic coverage, delays, cancellations and other operational characteristics.

The system then compares:

WHAT THE CITY PROVIDES

with

WHAT CITIZENS NEED

The objective is to identify measurable gaps such as:

Areas with insufficient public transportation coverage.
Origin–destination pairs without satisfactory connections.
Time periods with inadequate service.
Excessive walking distances.
Excessive travel times.
Excessive numbers of transfers.
Accessibility deficiencies.
Regular demand that is not adequately served.
Latent demand currently hidden because citizens use cars or alternative arrangements.
Occasional or one-time demand for which no appropriate service exists.

This is the point at which PTIM begins to generate Transportation Opportunities.

The system does not necessarily replace existing transportation-management systems. Its initial role is to provide an intelligence layer that receives, organizes, maps, queries and compares existing supply with citizen demand. The principle remains:

Integrate First. Replace Later – If Ever Necessary.

18.4 Stage 4 – TDM/DRT Solution Design: From Identified Gaps to Transportation Services

The fourth stage is the transition from analysis to action.

Once PTIM has identified significant and recurring supply–demand gaps, it can begin constructing and evaluating Transportation Demand Management (TDM) and Demand-Responsive Transport (DRT) solutions.

The solutions should address two fundamentally different types of demand:

A. Periodic / Recurring Transportation

These are journeys that occur regularly according to identifiable patterns.

Examples include:

Daily commuting.
Regular school or university journeys.
Repeated healthcare journeys.
Regular journeys by senior citizens or people with accessibility requirements.
Recurring journeys between residential areas and employment centres.
Repeated journeys to community facilities.

For such demand, PTIM can investigate potential recurring DRT services, flexible routes, virtual stops, scheduled shared transportation, feeder services, or modifications to existing public transportation.

B. One-Time / Occasional Transportation

The second category consists of journeys that do not justify a permanent recurring service but nevertheless represent genuine transportation demand.

Examples include:

A one-time medical appointment.
A special community event.
A cultural or sporting event.
An emergency or exceptional requirement.
A temporary transportation disruption.
A concentrated demand generated by a particular event.

PTIM should be capable of identifying such temporary demand and evaluating whether a one-time or temporary DRT/TDM solution could be economically and operationally justified.

The objective is not simply to propose transportation services. Each proposed solution should be capable of being evaluated against the identified demand:

Demand → Proposed Solution → Simulation / Trial → Measurement → Evaluation → Improvement

This creates the final transformation:

Transportation Gap → TDM/DRT Proposal → Pilot → Measurement → Learning → Improved Service

The Complete PTIM Intelligence Cycle

The four stages therefore create a continuous learning cycle:

1. RESEARCH
Citizen questionnaires + PIM + FIM
↓
2. AGGREGATION
Demand groups + transportation trends
↓
3. GAP ANALYSIS
Existing supply ↔ citizen demand
↓
4. TDM / DRT SOLUTIONS
Periodic + one-time services
↓
Pilot → Measure → Learn → Improve

This four-stage architecture is particularly important to the INTEGRA concept because PTIM does not attempt to predict transportation requirements solely from historical passenger statistics. It creates a mechanism for discovering latent and emerging demand directly from citizens and households, comparing that demand with existing transportation supply, and progressively transforming the resulting knowledge into practical transportation solutions.

In this sense, PTIM evolves from a conventional Public Transportation Information Manager into a Civic Transportation Intelligence System – a system capable of helping a city understand not only how its transportation network operates, but how its citizens actually need it to operate.

19.. The DRT Information Foundation: The DRT component should initially be built around individual and household mobility requirements. INTEGRA is capable of recording, subject to privacy and authorization requirements:

Citizen ID or Number.
Household ID or City, Area, Quarter/District, Neighbourhood, Street, House Number, GIS Location (Geolocation Coordinates), Floor Number, Apartment Number.
From Date.
To Date.
Destination address and GIS location.
Day of week.
Frequency.
Preferred departure time.
Departure-time flexibility.
Preferred arrival time.
Arrival-time flexibility.
Travel purpose.
Current transportation mode.
Desired transportation mode.
Maximum acceptable walking distance.
Maximum acceptable travel time.
Maximum number of transfers.
Accessibility requirements.
Companion requirements.
Estimated monthly journeys.
Current transportation problem.
Willingness to use a proposed DRT service.
Remarks.

The long-term objective is therefore to transform PTIM from a questionnaire system into a living transportation-demand information system.

20.. The Strategic Architecture – Two Streams, One PTIM:

The recommended architecture is therefore:

STREAM A – EXISTING TRANSPORTATION SUPPLY

Operators → Lines → Routes → Stops → Timetables → Vehicles → Journeys → Performance

and simultaneously:

STREAM B – CITIZEN TRANSPORTATION DEMAND

Citizens → Households → Origins → Destinations → Time → Frequency → Purpose → Preferences → Constraints → Demand

These two streams should remain conceptually distinct.

They should not be prematurely merged into a single database structure.

Instead, they should eventually meet in a third layer:

STREAM C – SUPPLY / DEMAND INTELLIGENCE

Existing Supply + Citizen Demand → Gap Analysis → Opportunities → DRT Proposals → Evaluation

This is where the real strategic value of PTIM emerges.

21. The PTIM Development Strategy:

The PTIM strategy should therefore follow a staged approach.

21.1 Phase 1 – Map the Existing Supply:

The first task is to establish a reliable representation of the existing public transportation environment.

This should include:

Identify existing transportation information sources.
Identify relevant external databases.
Define the PTIM data dictionary.
Map existing data structures to PTIM structures.
Establish geographic references.
Import or connect relevant data.
Build basic retrieval screens.
Build multi-record displays.
Build flexible queries.
Build dashboards.

The initial objective is not to reproduce every operational function of every transportation operator.

It is to establish an integrated transportation information picture.

21.2 Phase 2 – Build the Citizen Demand Layer:

In parallel, PTIM should begin developing the DRT information structure.

The first version should be deliberately simple.

Citizens should be able to document:

Where do I need to go?

When do I need to go?

How frequently?

Why?

How flexible am I?

What transportation do I currently use?

What would I use if an appropriate public transportation service existed?

What prevents me from using the existing service?

The system should initially focus on collecting high-quality demand information rather than attempting to solve the complete transportation optimization problem.

21.3 Phase 3 – Create Demand Clusters:

Individual demand records become valuable when they can be aggregated.

PTIM should therefore identify recurring patterns such as:

Many citizens travelling from the same neighborhood.
Similar destinations.
Similar departure periods.
Similar arrival requirements.
Similar travel purposes.
Similar frequency.
Similar transportation constraints.

The system can then create a:

DRT Demand Cluster

For example:

Origin: Neighborhood A
Destination: Hospital B
Potential Users: 146
Days: Monday–Friday
Departure Window: 07:15–08:00
Primary Purpose: Employment / Health
Existing Service: Inadequate
DRT Opportunity: High

At this stage, PTIM begins transforming individual citizen information into actionable transportation intelligence.

21.4 Phase 4 – Supply / Demand Gap Analysis:

This is the critical convergence point. PTIM should compare:

Existing Supply

with

Identified Demand

and calculate or identify:

Unserved areas.
Underserved neighborhoods.
Unserved destinations.
Time-period gaps.
Excessive walking distances.
Excessive transfer requirements.
Excessive travel times.
Accessibility gaps.
High-frequency unmet demand.
Potential DRT corridors.

The result should not simply be a collection of statistics.

It should be a prioritized list of transportation opportunities.

21.5 Phase 5 – DRT Opportunity and Pilot Design:

Only after sufficient demand information has been collected should PTIM begin proposing potential DRT services. For each opportunity, the system could present:

Demand volume

Demand concentration

Origin / destination

Time window

Frequency

Travel purpose

Existing transportation alternative

Identified gap

Potential vehicle/service type

Potential number of passengers

Estimated operating requirements

Potential cost

Expected utilization

Priority

The final decision should remain with transportation authorities and operators.

AI and analytical tools can assist in identifying opportunities, but they should not automatically determine public policy.

21.6. The Most Important Tactical Principle:

PTIM should not attempt to solve transportation before it understands transportation demand.

The development sequence should therefore be:

Data first.

Patterns second.

Analysis third.

Optimization fourth.

This dramatically reduces development risk.

It also conforms to the general INTEGRA philosophy:

Build → Use → Learn → Collaborate → Expand.

21.7. The Role of PIM and PIM and FIM:

PIM and FIM can provide PTIM with an enormous strategic advantage.

The citizen should not have to repeatedly answer questions that INTEGRA already knows.

For example, PIM/FIM may contain:

Home location.
Family members.
Workplace.
Educational institution.
Regular activities.
Vehicle availability.
Driving license status.
Accessibility requirements.

PTIM can ask only for the missing transportation information.

The result is a much more complete mobility profile with significantly less effort from the citizen.

This creates a powerful bottom-up chain:

Citizen → Family → Mobility Profile → Transportation Demand → City Demand Map → PTIM Analysis

22. PTIM Dashboards: PTIM should ultimately provide several complementary dashboards.

Dashboard 1 – Existing Supply:

Operators
Lines
Routes
Stops
Timetables
Vehicles
Performance

Dashboard 2 – Citizen Demand:

Citizens
Origins
Destinations
Time
Frequency
Purpose

Dashboard 3 – Supply / Demand Gaps:

Underserved Areas
Time Gaps
Demand Corridors
Unserved Destinations

Dashboard 4 – DRT Opportunities:

Demand Clusters
Potential Users
Priority
Feasibility
Potential Service

Dashboard 5 – Pilot Performance:

Passengers
Utilization
Cost
Travel Time
Reliability
Citizen Satisfaction

This creates a continuous feedback loop:

Supply → Demand → Gap → DRT → Operation → Measurement → Learning.

23. The Long-Term Objective:

The ultimate objective of PTIM is not to eliminate conventional public transportation.

Nor is DRT necessarily intended to replace scheduled buses, trains, trams or metro systems.

Rather, INTEGRA seeks to create a hybrid transportation intelligence model in which scheduled mass transportation remains the backbone while demand-responsive services address gaps, specialized needs, low-density areas, unusual time periods, first/last-mile problems and emerging demand.

Thus:

Scheduled PT provides the backbone.

DRT provides flexibility.

INTEGRA provides the intelligence connecting the two.

24. Strategic Conclusion:

PTIM is difficult precisely because it attempts to bridge two worlds that have historically been managed separately.

The first world is transportation supply - what operators currently provide.

The second is transportation demand - what citizens require, prefer, cannot currently obtain, or would use if an appropriate service existed.

The strategic opportunity for INTEGRA is to bring these worlds together.

The first PTIM implementation should therefore remain deliberately modest in its ambition:

Do not replace the transportation industry.

Do not attempt to solve every routing problem.

Do not begin with complex AI optimization.

Instead:

Integrate the existing transportation information.

Create a structured citizen-demand database.

Identify demand patterns.

Compare supply with demand.

Expose gaps.

Identify DRT opportunities.

Test selected solutions.

Measure the results.

Learn and improve.

This approach allows PTIM to evolve from an information-management module into something much more significant:

A Civic Transportation Intelligence System capable of helping cities understand not only how their transportation system operates, but how their citizens actually need it to operate.

25. Accurately monitoring user-demand data also helps to efficiently allocate in scarce resources:

Considerations in PT STOPS/STATIONS.
Locating and equipping SHELTERS from potential risks: Sun, Rain /Hail / Flood. Emergency: Bombs/Rockets/Bullets.
Making PT stops/stations inspiring public properties/spaces by integration and synergy with:

Free Drinking Water facilities

Toilet/WC services.
Automatic vending machines for food and drinks.
Mobile phone chargers (!)
Usage of Solar Panels over PT stops/stations (sunny locations).
Green Stops/Stations: Trees or Plants, not only contribute to the attractiveness of the place, but also help to improve air quality. Vertical gardens can be created on the walls of a bus stop. Small trees are highly advised to provide shade for waiting passengers.
Seating and a Roof - vital in hot or rainy climates.
Rack of books geared for all ages.
Bicycles Parking space.
Screens/monitors that broadcast information on news, local events and weather and PT pertinent information to waiting passengers.
Lighting that dims or brightens in response to motion.
Trash bins.
Proximity to Parking Lots / other modes of PT (Train, Scooter, Tram, Bus).

26. Emergencies: In crises, when services are disrupted or diverted - giving real-time accurate information to passengers and PT operators is vital.

27. It’s, probably, one of the first and capital-cheap steps towards remodelling our urban environments as “15 minutes cities”: to provide all necessary services required for the health and wellbeing of its residents within 15 minutes’ walking distance.

28. INTEGRA DOES NOT deal with: PT Ticketing: Integrated Ticket for ALL kinds of PT for a LIMITED timeframe, Stored-value Cards, Contactless Payment Card, Mobile Ticketing, NFC Technology.

29. Bear in mind there is a growing variety of PT actors: Traditional public transport operators, taxis, automated vehicles, car and bike-sharing services, ride-sharing (car-pooling), drones, micro-mobility vehicles.

30. How to Engage Citizens in Planning and Decision-Making?

Community Surveys: INTEGRA enables conducting regular surveys to gather input from citizens on their transportation needs, preferences, and feedback on existing services. Use the computerized platform of the INTEGRA CIM module.

Public Forums and Workshops: INTEGRA lays the computerized, all-inclusive platform for organizing community meetings where residents can discuss their transportation challenges and propose solutions. Use the computerized platform of the INTEGRA CIM module.

Flexible Routing and Scheduling: Public (and private) transport actors use the data-driven insights to adjust routes and schedules based on real-time demand patterns and user preferences.

Customization Options: INTEGRA allows PT operators to easily customize certain aspects of their service, such as pick-up locations or preferred time windows.

31. Even more Community Engagement:

Co-Ownership Models: INTEGRA recommends on models where the community or cooperatives own and operate DRT services, fostering a sense of ownership and responsibility.
Volunteer Programs: Noh Ark encourages citizens to volunteer as part-time drivers or support staff, particularly in underserved areas.

Focus on Diverse Needs: INTEGRA engages with marginalized groups, such as people with disabilities, seniors, or low-income residents, to ensure DRT services are inclusive and accessible to all. Public Transport is heavily subsidized for several sectors in society. Youngsters, childless couples, seniors, essential workers, students enjoy, in many countries, enviable tariffs. In most of the cases they experience also high-standard service and their long-distance journeys are a pleasure.

32. Sample DRT Questionnaire:

Section 1: Current Public Transportation Usage

Citizen ID:

(the following personal are Optional, but help understand who is using the services)

Age:
- Under 18
- 18-24
- 25-34
- 35-44
- 45-54
- 55-64
- 65 and above
Gender:
- Male
- Female
- Non-binary/Other
- Prefer not to say
Household Income:
- Under $25,000
- $25,000 - $49,999
- $50,000 - $74,999
- $75,000 - $99,999
- $100,000 - $149,999
- $150,000 and above
- Prefer not to say
Residential Area:
- Urban
- Suburban
- Rural

Section 2: Current Public Transportation Usage

How often do you use public transportation?
- Daily
- 3-4 times per week
- 1-2 times per week
- 1-3 times per month
- Rarely/Never
Which types of public transportation do you use? (Select all that apply)
- Bus
- Train/Metro
- Tram/Streetcar
- Demand-Responsive Transport (DRT) services
- Ridesharing (e.g., Uber, Lyft)
- Bicycle-sharing programs
- Other (please specify): __________
What is the primary purpose of your public transportation use? (Select all that apply)
- Commuting to work or school
- Running errands (e.g., shopping, appointments)
- Leisure and social activities
- Accessing healthcare services
- Other (please specify): __________
How satisfied are you with the current public transportation services?
- Very Satisfied
- Satisfied
- Neutral
- Dissatisfied
- Very Dissatisfied

Section 3: Public Transportation Preferences and Needs

What factors are most important to you when using public transportation? (Rank in order of importance: 1 = most important, 5 = least important)
- Reliability (on-time performance)
- Frequency of service
- Cost/Affordability
- Safety and security
- Comfort and cleanliness
What improvements would make you use public transportation more often? (Select all that apply)
- More frequent services
- Better routes and coverage
- Lower fares
- Improved safety and security
- Enhanced comfort and cleanliness
- More accurate real-time information
- Better accessibility for people with disabilities
- Other (please specify): __________
What barriers prevent you from using public transportation more often? (Select all that apply)
- Inconvenient schedules
- Lack of routes near my home/work
- Unreliable service
- High costs
- Safety concerns
- Poor condition of vehicles/stations
- Prefer to use a car or other personal transportation
- Other (please specify): __________
Would you be interested in using Demand-Responsive Transport (DRT) services if they were available?
(DRT services adjust routes based on passenger demand rather than following fixed routes and schedules.)
- Yes
- No
- Not sure
If you answered "Yes" to the previous question, what features would you like to see in DRT services? (Select all that apply)
- Flexible pick-up and drop-off locations
- Affordable pricing
- Real-time tracking and booking via mobile app
- Shorter wait times
- Safety and security features
- Accessibility for people with disabilities
- Other (please specify): __________

Section 4: Feedback on Existing Services

What do you like most about the current public transportation services?
(free text)
What do you dislike most about the current public transportation services?
free text)
Do you have any suggestions for improving public transportation in our community?
(free text)

Section 5: Additional Comments

Please share any additional comments or concerns regarding public transportation in your area.
(free text)
Attach photos.

(free pictures)