Home » railML newsgroups » railml.timetable » Proposal for new timetable schema version 2.0(?)
Proposal for new timetable schema version 2.0(?) [message #663] Tue, 19 September 2006 18:14 Go to next message
Tai Truong is currently offline  Tai Truong
Messages: 1
Registered: September 2006
Junior Member
Hello railway friends :-)!

We have a product RailOpt 2T that is a system for Intelligent Resource
Management (IRM). It is a planning- and production-system for the railway
industry. With the experience with the customers SJ (Sweden), CFL
(Luxemburg), BLS and SOB (both Switherland) we would like to use the
timetable schema as the STANDARD for integrating (and exporting) timetables
from (and to) external systems (like SYFA, Roman, BITS etc.).

Please check the attached draft for the revised extensions and suggestions
for a new major release 2.0 for the timetable schema. Here is a quick
summary of the revision for version 2.0:

NEW top elements: netNodes and sections:
This helps to reduce the timetable entries. The network nodes ("posID"),
sections and distance being used in the timetable entries are replaced by
ONE sectionID referring to the section in the top element.

MOVING top element: operatingPeriods below a timetablePeriod:
Operating periods should always refer to a specific timetable period. An
operating period like "11" (containing all Mondays - e.g. in Bit Mask
format) may exist in several different timetable periods but have different
Bit Masks!

NEW element: project below timetable period; MOVING element: train below a
project:
A timetable period should have several projects. The train elements are
moved below a project. This allows systems like RailOpt to create different
sets of trains in different projects within one timetable period. Trains
could be merged and copied between projects.

The new XML structure for the timetable interface would look like this:

railML

timetable

networkNodes

sections

timetableperiods

operatingPeriods

projects

trains

I have signed up for the 10th railML conference and our company Qnamic has a
stand at the InnoTrans exhibition in Berlin this week. I am looking forward
to discuss the timetable specification with somebody! Our office is in
Switzerland and everybody is happily invited!

Cheers,

__________________________________________

Tai Truong

Manager Research & Development

Qnamic AG

Fabrikstrasse 10

CH-4614 Hägendorf

Switzerland

Phone: +41 62 209 70 52

Mobile: +41 78 861 40 02

Fax: +41 62 209 70 44

taitruong(at)qnamiccom

www.qnamic.com

--> Qnamic is at InnoTrans in Berlin

--> 19.-22. September 2006

--> Hall 4.1, Booth 138

__________________________________________


Re: operatingPeriods [message #664 is a reply to message #663] Tue, 26 September 2006 20:14 Go to previous messageGo to next message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 33
Registered: September 2004
Member
Hello,

I don't think we should regard operatingPeriods as a subelement of
timetablePeriods.

The operatingPeriod "11" in Switzerland means "on every days, treated as
mondays" (i.e. all mondays and days after a holiday). It is therefore
depending on a special timetablePeriod (wich is referenced by
"timetablePeriodID") and has its own bitMask. Anyway, you need different
serviceIDs (like "2005_11", "2006_11") to distinguish between the
operatingPeriod "11" in separate timetablePeriods.

But the german "TGL" or the swiss "17" (meaning "daily") or the real "on
every monday" are operatingDays with a short 7-day bitmask and clearly
independent of any timetablePeriod. They could be defined in any train and
keep valid, even if you transfere the timetable from one timetablePeriod
to the next.

Cheers,

Joachim
Re: projects [message #665 is a reply to message #663] Tue, 26 September 2006 20:52 Go to previous messageGo to next message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 33
Registered: September 2004
Member
Hi,

every timetable could be seen as part of a certain project in the sense of
"planned timetable for new City-Tunnel Berlin". But the same is true for
every infrastructure. I think the relation to such a project is additional
(meta-)information and not part of the timetable itself. I would therefore
prefer to create a new optional element "projects" somewhere, which could
be referenced by a train or a timetable via projectID.

If you like to use projects for separating "simulated" form "productive"
trains, why don't you create different timetables for each type? The
"planned" and the "actual" train are two different types (views) of the
very same train and it will be confusing to have them in the same
timetable.

Best wishes,

Joachim
Re: netwokNodes, sections [message #666 is a reply to message #663] Tue, 26 September 2006 21:14 Go to previous message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 33
Registered: September 2004
Member
Hi,

your "networkNode" and your "sections" are part of a high-level
infrastructure, which is referenced by most timetables. Most planned
trains are driving from "station A" to "station B". The "networkNodes"
could be found as "operationControlPoints" in the infrastructure, but the
"sections" between these points are still missing. This is a known lack.
The reason is, that it is easier to agree on a common description of the
tracks and switches than on the network, because "sections" are defined
differently in every railway.

Nevertheless, "networkNodes" and "sections" should be part of the
infrastructure not the timetable. A timetable could reference them via
"posID" and "sectionID" in the way you described.

Cheers,

Joachim
Previous Topic: Correct use of arrivalDay/departureDay
Next Topic: stopDescription
Goto Forum:
  


Current Time: Fri Mar 29 08:45:52 CET 2024