{"id":28,"date":"2024-02-23T14:57:57","date_gmt":"2024-02-23T13:57:57","guid":{"rendered":"http:\/\/localhost\/?page_id=28"},"modified":"2024-10-07T14:36:57","modified_gmt":"2024-10-07T12:36:57","slug":"transmodel-at-a-glance","status":"publish","type":"page","link":"https:\/\/transmodel-cen.eu\/index.php\/transmodel-at-a-glance\/","title":{"rendered":"Transmodel at a glance"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Transmodel at a glance<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Transmodel is a conceptual data model describing in terms of data structures (entities and relationships between them) the domain of Public Transport.\u00a0<\/p>

It may be used for several purposes<\/a>, in particular to specify a data base or data exchange formats that enable the sharing and provision of accurate and interoperable public transport information across organisation- and system-boundaries.\u00a0<\/p>

When writing laws and regulations, procuring technical systems or integrating technical systems, it is a huge advantage to have access to a precise language.\u00a0<\/p>

Transmodel is a semantic model. This means that not only concepts\/data elements are provided (i.e. their naming and definition), but also the relationships between concepts (i.e. data structures). This means that not only language elements are fixed but also that it constitutes an unambiguous input to design implementations, e.g. data exchange formats.\u00a0<\/p>

In the same fashion that we have been able to agree on symbols on road signs that are the same or similar across many countries. We have in Transmodel a foundation for a common language for public transport.\u00a0<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Transmodel \u2013 making travel easy<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The traveller needs consistent, complete and correct real time information about his or her trip. This applies before, during and after they travel.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
Figure 1: Consistent travel information across different modes is essential<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

There are many organisations, companies and IT systems involved in the provision of public transport and related areas that must interact to make both the services themselves and information about them possible. In addition to the explicit passenger information, other information must be handled to monitor, manage and optimise the operation of public transport.<\/p>

<p “=””>But how can we ensure a robust and efficient exchange of information between the involved systems? A first requirement is that the involved parties understand each other.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

\"\"<\/p>

Figure 2: Many systems must interact and share information<\/i><\/span><\/p>

Historically different companies and organisations developed their own terminology which resulted in confusion and misunderstanding when trying to interact with other actors.<\/p>

One example to illustrate this, is the need to clearly separate the description of the movement of a person, from the movement of a vehicle in public transport. Transmodel has a definite standpoint on this as is described by the series of pictures below.<\/p>

\"\"<\/p>

Figure\u00a03: People and vehicles moving through a city<\/em><\/span><\/p>

\"\"<\/p>

Figure 4: A\u00a0service journey\u00a0with a bus going from B to F<\/em><\/span><\/p>

\"\"<\/span><\/p>

Figure 5: A\u00a0service journey\u00a0with a tram going from A to M<\/em><\/span><\/p>

\"\"<\/p>

Figure 6: A\u00a0PT trip\u00a0with a person going from C to F. The person rides the tram between C and D and the bus between D and F<\/span><\/em><\/p>

According to Transmodel, a\u00a0service journey<\/span>\u00a0is related to the movement of the vehicle, while a\u00a0PT<\/span>\u00a0trip\u00a0<\/span>is related the movement of the person. A typical misunderstanding occurs if persons talking to each other do not have a common understanding of what a certain word means.<\/p>

\"\"<\/p>

Figure 7: Trying to convey the concept of a person\u2019s movement<\/em><\/span><\/p>

\"\"<\/p>

Figure 8: Failing to convey the message if there are different interpretations of what the word\u00a0trip\u00a0means.<\/span><\/em><\/p>

On the other hand, if involved persons rely on Transmodel terminology, such misunderstandings can be avoided.<\/p>

\"\"\u00a0 \u00a0\u00a0\"\"<\/p>

Figure 9: Common understanding when using Transmodel terminology<\/span><\/em><\/p>

In addition to providing a long list of defined terms, Transmodel also describes a conceptual model of how these terms relate to each other.<\/p>

Transmodel \u2013 a nomenclature for public transport<\/h2>

Transmodel provides matching definitions, structures and semantics for PT data allowing the design of coherent, precise and efficient data exchange across domains.<\/p>

Transmodel – Bridging the gap between the conventional public transport and alternative modes<\/h2>

From version 6.1 on,\u00a0Transmodel, additional concepts have been added to simplify the bridging between conventional public transport<\/b> (e.g. which relies on a schedule, a predefined network) and alternative modes<\/b><\/a>. It is possible to describe trips and travel that also includes all kinds of modes, for example trips composed of trip legs by bus followed by trip legs by a shared car or by car pooling. It is also possible to describe the guidance of travellers about how to find the means of transport\u00a0(e.g. stop places or car pooling locations) when starting a trip or interchanging.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t
Figure 10: Definition of Public Transport and modes covered by Transmodel<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Transmodel \u2013 Building systems of systems and the principal of separation of concerns<\/strong><\/h2>

To succeed with combined mobility or MaaS it is crucial that the different technical systems involved can be seamlessly combined while retaining the respective systems’ level of detail in their respective areas.<\/p>

Transmodel is designed to allow for a separation of concerns so that different systems can work independently with different parts of the operation while at the same time allowing their information to be combined and presented unambiguously. Less advanced systems can coexist with more advanced systems.<\/p>

For example, one system might describe the accessibility for different parts of a station, while other systems might describe different journeys that stop at the station.<\/p>

Transmodel \u2013 Some basic concepts<\/h2>

Public Transport involves different transport modes using means\u00a0<\/b>such as bus, train, tram, metro, car, cycle, scooter, foot, skis, etc. Typically, buses are restricted to follow roads while trains, trams and metro follow tracks.<\/p>

Travellers will board or alight from these different types of\u00a0vehicles at\u00a0stop places of different kinds. A\u00a0stop place\u00a0can be described according to its\u00a0accessibility,\u00a0what services are available, etc.<\/p>

In public transport, you will normally board and alight at a bus stop, at the edge of a platform, through a gate or at a pier, but for a timetable the physical nature of the stop doesn\u2019t actually matter; it is just the place the service stops to collect passengers. These alighting and boarding points are generally represented as\u00a0scheduled stop points\u00a0in the planning software. (A scheduled stop point will of course be associated with a physical\u00a0stop place\u00a0or even a specific\u00a0quay\u00a0(platform) or boarding point within it).<\/p>

\"\"<\/p>

Figure 11: Scheduled stop point<\/span><\/em><\/p>

In the planning software it is possible to define a pattern of working for a public transport vehicle by listing a sequence of\u00a0scheduled stop points<\/strong>.\u00a0This is called a\u00a0journey pattern<\/strong>.<\/p>

\"\"<\/p>

Figure 12: Journey pattern<\/em><\/span><\/p>

There is a separate\u00a0journey pattern<\/strong>\u00a0for each direction. For example, one\u00a0journey pattern<\/strong>\u00a0when going from Solna to Sickla and another going from Sickla to Solna. A\u00a0vehicle\u00a0<\/strong>may operate by simply going back and forth between the two termini and thus alternate between these two\u00a0journey patterns<\/strong>. A\u00a0journey pattern<\/strong>\u00a0may thus be used many times each day. There could also be other\u00a0journey patterns<\/strong> representing different variations of the basic patterns.<\/p>

A\u00a0vehicle journey<\/strong>\u00a0describes one movement of a public transport\u00a0vehicle\u00a0<\/strong>from the start point to the end point of a\u00a0journey pattern<\/strong>\u00a0on an\u00a0operating day<\/strong>.\u00a0A\u00a0vehicle<\/strong> journey\u00a0<\/strong>starts at a certain time. A certain\u00a0vehicle journey\u00a0<\/strong>can be worked only once per day.<\/p>

A\u00a0vehicle journey<\/strong>\u00a0that is meant to carry passengers is called a\u00a0service journey<\/strong>.<\/p>

\"\"<\/p>

Figure 13: Vehicle Journey of type Service Journey<\/em><\/span><\/p>

A\u00a0dead run<\/span>\u00a0is on the other hand a\u00a0vehicle journey<\/span>\u00a0where passengers are not allowed on-board. One example is the movement from the depot to the first stop of the first\u00a0service journey<\/span>\u00a0in the morning.<\/p>

\"\"<\/p>

Figure 14: Vehicle Journey of type Dead Run<\/em><\/span><\/p>

The working of a\u00a0vehicle<\/span>\u00a0from when it leaves the depot to when it returns can be described by a\u00a0block<\/span>.<\/p>

A\u00a0block<\/span>\u00a0typically starts with a\u00a0dead run<\/span>\u00a0from the depot followed by a number of\u00a0service journey<\/span>s and finally a\u00a0dead run<\/span>\u00a0back to the depot. A\u00a0block<\/span>\u00a0describes the work for a\u00a0vehicle\u00a0<\/span>on a day\u00a0<\/span>or part of a day.<\/p>

\"\"<\/p>

Figure 15: Block<\/em><\/span><\/p>

Similarly, a\u00a0duty<\/span>\u00a0describes the work for a\u00a0driver<\/span>\u00a0on a day.<\/p>

The above descriptions are simplified to convey the basic message, the documentation of the standard provides more details. To exemplify this, a somewhat deeper description of\u00a0duty\u00a0<\/span>follows below.<\/p>

A\u00a0duty\u00a0<\/span>consists of periods when the\u00a0driver\u00a0<\/span>is working without a\u00a0break,\u00a0<\/span>such a period is called a\u00a0stretch.<\/span><\/p>

During a stretch<\/b> the driver could be driving different vehicles<\/b> or doing some other type of activity. Each such activity is called a spell<\/b>.<\/span><\/span>\u00a0<\/b><\/span><\/span>The\u00a0<\/span>driver\u00a0<\/span>can also<\/span>\u00a0<\/span>have<\/span>\u00a0<\/span>shorter<\/span>\u00a0pause<\/span>s in between journeys or be resting during a\u00a0<\/span>break.<\/span><\/p>

Sometimes a\u00a0duty\u00a0<\/span>is split into two separate\u00a0duty parts\u00a0<\/span>with a several hours long period in between. The\u00a0driver\u00a0<\/span>is not under the\u00a0operator<\/span>\u2019s responsibility during that period.<\/p>

\"\"<\/p>

Figure 16: Duty<\/em><\/span><\/p>

Typically, the\u00a0driver<\/span>\u00a0works different\u00a0dut<\/span>ies<\/strong> on different dates. The process of deciding what a\u00a0driver<\/span>\u00a0shall do on different dates is called rostering.<\/p>

\"\"<\/p>

Figure 17: Example of rostering<\/em><\/span><\/p>

Transmodel \u2013 Production perspective vs passenger perspective<\/h2>

There are many aspects to public transport. From one point of view, the production perspective, it is very important to emphasize optimal usage of vehicles and drivers. From another point of view, the travellers\u2019 perspective, it is the travel opportunities that are in focus.<\/p>

When building systems catering for different users it is an advantage that Transmodel is organized in such a way that is easy to separate these aspects.<\/p>

Some examples of production centric aspects are managing\u00a0block<\/span>s, duti<\/span>es, vehicle<\/span>s\u00a0and driver<\/span>s.<\/span>\u00a0Examples of traveller-centric aspects are\u00a0trip<\/span>s, ride<\/span>s\u00a0and interchange<\/span>s.<\/p>

Additionally, there are of course a large number of aspects that are shared.<\/p>

Transmodel \u2013 Layered solutions and separating maintenance<\/h2>

Transmodel promotes the notion of the separation of concerns as mentioned previously. Different systems and organisations can be allocated responsibility for different types and scopes of information and maintain their respective information independently. The resulting information coming from different sources can then be combined into a unified view. As the information is structured according to Transmodel, it is readily integrated and can be used for many different purposes by different systems.<\/p>

Systems relating to certain external information use references pointing to information maintained in the relevant system instead of repeating the same information. Different types of information can be maintained with different update cycles.<\/p>

One example of how this concept can be applied is the\u00a0route<\/span>.<\/p>

\"\"<\/p>

Figure 18: Infrastructure \u2013 road network<\/span><\/em><\/p>

A\u00a0route\u00a0<\/span>describes a path to be used by regular public transport services.<\/p>

\"\"<\/p>

Figure 19: Route represented by blue line, and deduced physical path on road network represented as dotted red line<\/em><\/span><\/p>

In relation to a road network a\u00a0route<\/span>\u00a0is defined by a start point and an end point and possible one or more intermediate route points. From this the physical path through the road network can be deduced by a technique called projection. It may be necessary to add a few intermediate\u00a0via<\/i>\u00a0route points to clarify the intended physical path.<\/p>

\"\"<\/p>

Figure 20: Adding an intermediate Route Point alters deduced physical path<\/em><\/span><\/p>

The next step is to define the points where it is possible to board and alight at a bus stop, a platform a gate or a pier. This point is generally represented as a\u00a0scheduled stop point\u00a0<\/span>in the planning software.<\/p>

There may be some other software that describes the physical aspects of this point. This can include information of exact location, available\u00a0equipment<\/span>\u00a0and\u00a0accessibility<\/span>\u00a0aspects.<\/p>

In the planning software it is possible to define a pattern of working for a vehicle moving from one end point to the other end point by listing a sequence of\u00a0scheduled stop points.\u00a0<\/span>This is called a\u00a0journey pattern<\/span>.<\/p>

Transmodel \u2013 Separating out temporal concerns<\/h2>

When does a service run? At what times is a particular fare available? Another good example of the separation of concerns in Transmodel is the handling of the days of operation and the availability of time dependent services.<\/p>

A\u00a0day type<\/span>\u00a0describes a logical type of day independent of any specific calendar date. For example,\u00a0working day<\/i>,\u00a0weekend<\/i>,\u00a0national holiday<\/i>\u00a0etc. It can be precisely characterised in terms of specific days of the week or other criteria such as\u00a0school day<\/i>\u00a0or\u00a0market day<\/i>. The\u00a0day type<\/span>\u00a0can be used to specify when a\u00a0service journey, fare product<\/span>\u00a0or other time dependent concept is available in a manner that is easy to understand and also independent of any actual calendar. Timetables and fare products thus become reusable concepts that can be applied within any given time period simply by resolving the day types against a calendar that describes to which dates different\u00a0day typ<\/span>e<\/span>s<\/b> apply. Thus, for example, if January 5, 2019 is marked as a\u00a0working day<\/i>\u00a0in that calendar, services with a\u00a0day type<\/span>\u00a0of\u00a0working day<\/i>\u00a0apply.<\/p>

When it comes to implementing systems, the separating of concerns has two particular advantages. Firstly, it increases reusability, as components are highly modular and may be used to provide the same function in different contexts uniformly and without additional overhead (as say,\u00a0day types<\/span>\u00a0above can be used both for timetables and fares). Secondly it makes it easier to evolve systems because specific function is concentrated in specific components and modules and can be changed without unwanted side effects.<\/p>

Transmodel \u2013 Fares: Using new abstractions to achieve general solutions<\/h2>

Quite often, a proper separation of concerns requires the invention of novel abstractions that serve to simplify or to generalise the solution. The introduction of new software abstractions can be extremely powerful and make hitherto difficult problems tractable. A classic example from the history of personal computers was how the usability of computers was revolutionised by the invention of the virtual concepts that make up a graphic user interface \u2013 windows, icons, menus, cursor focus, mouse pointer events, etc. New components can enable new, more understandable solutions.<\/p>

Within Transmodel, the Tariff and Fare models provide a case in point where such an approach has been critical for achieving a general solution. Transmodel formulates a general-purpose Fare Management model that is capable of describing a very wide variety of tariff structures and fare conditions and fare products for any mode of transport, including complex price structures and complex usage conditions.<\/p>

The tariff components make use of the same existing network concepts that are used in timetables, such as\u00a0scheduled stop points, service journeys,<\/span>\u00a0etc… while also adding additional concepts. For example, for a point-to-point fare, the allowed transition between an origin and destination point is defined as a\u00a0destination matrix element.\u00a0<\/span>If the tariff depends on distance or stages consumed, a set of unit intervals may be defined as\u00a0geographical unit intervals.\u00a0<\/span>Fare products can be associated with a\u00a0type of travel document<\/span>\u00a0(i.e. ticket media such as paper or smartcard) in a\u00a0sales offer package<\/span>\u00a0that can be purchased by the user.<\/p>

A further separation of concern is that Transmodel completely segregates the notion of price from that which is being priced.<\/p>

Transmodel \u2013 Version management<\/h2>

When exchanging data sets repeatedly between systems, it is important to be able to determine the validity and relevance of successive versions of the data as they evolve over time.<\/p>

Transmodel provides concepts for advanced versioning mechanisms that allow data to be changed over time while retaining identifiers that are stable over time for the involved objects.<\/p>

Objects can also be grouped into coherent bundles \u2013\u00a0version frames<\/span>\u00a0\u2013 which simplifies the process of applying multiple changes as one transaction.<\/p>

For example, a\u00a0version frame<\/span>\u00a0may relate to all\u00a0service journey<\/span>s on a specific\u00a0line\u00a0<\/span>or all\u00a0scheduled stop points<\/span>\u00a0in a specific municipality.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

Transmodel at a glance Transmodel is a conceptual data model describing in terms of data structures (entities and relationships between them) the domain of Public Transport.\u00a0 It may be used for several purposes, in particular to specify a data base or data exchange formats that enable the sharing and provision of accurate and interoperable public […]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-28","page","type-page","status-publish","hentry","entry"],"_links":{"self":[{"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/pages\/28","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/comments?post=28"}],"version-history":[{"count":73,"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/pages\/28\/revisions"}],"predecessor-version":[{"id":3241,"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/pages\/28\/revisions\/3241"}],"wp:attachment":[{"href":"https:\/\/transmodel-cen.eu\/index.php\/wp-json\/wp\/v2\/media?parent=28"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}