| Re: [railML3] Time Dimension requirements from TT view [message #1501 is a reply to message #1500] |
Fri, 17 February 2017 13:07   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Gerben,
thank your for your reply.
I understand that you opt for only a small amount of shared time-related
structures between <infra> and <timetable> sub-schemes of railML.
This may be the easiest way but I am currently not convinced of it being
the best way.
As you wrote, there is a "grey zone" which is not exactly defined.
(There may be different opinions about where the responsibility of an
infrastructure department ends and where a "timetable" begins.) Also,
from my experience, the grey zone becomes larger each year with more and
more infrastructure work influencing the timetables (less "stable"
infrastructure).
So, I think there should be a common solution. Since <timetable> has
naturally more time-related elements than infrastructure, it could be
advisable to adopt <timetable> structures for <infrastructure>.
Unfortunately, the appointment of 21th of February (of the year 2017, I
presume) comes a little bit too quick for me to join. However, if I can
help anyway with experience or structures please don't hesitate to
contact me.
With best regards,
Dirk Bräuer.
---
Am 15.02.2017 um 14:46 schrieb Schut, GD (Gerben):
> Dear RailML TT community,
>
> First I'd like to introduce myself: I'm Gerben Schut, part of the Infra
> Structure WG for RailML for about 2 years, Information Architect @
> ProRail (NL), and have almost 10 years experience with the Dutch
> Infrastructure software (Infra Atlas), where the time dimension on
> infrastructure is managed now for about 15 years.
>
> I would like to thank you for the answers from Dirk Bräuer. They are
> really helpful in understanding the needs of the TT community regarding
> the time dimension and what it means for the infrastructure information.
>
> As you mentioned it is important to understand the different time
> dimension dynamics: Time Tabling always requires a stable
> Infrastructure, and changes in Infrastructure will almost always lead to
> a changed timetable. So a specific time table will be based on one
> stable infrastructure situation.
>
> Time dimension in Time tabling is not the same as Time dimension in
> Infrastructure.
>
> These different situations require a different model, although off
> course some base elements could and should be shared (like xml:time).
> Therefore it is good to get to know each other needs and use cases, so
> we can be clear about the different parts and about the shared parts.
>
> It will be very interesting to discover the grey zone: There where the
> Infrastructure is less stable (IE bridge closing times, opening hours of
> tracks/stations), the Time Table will depend on those variations. At
> least there where the changing times on the Infrastructure are stable
> (bridge is always open from 7:00 - 7:15 pm) the interfacing between
> infrastructure and time table should be defined and information
> exchangeable, so these should be clearly formatted in the RTM to get
> them properly into RailML.
>
> We have planned to meet with the Infrastructure time dimension subgroup
> on 21th of February in Frankfurt. We will try to understand both worlds,
> and post any remaining questions in this forum topic. Thanks for your
> kind understanding and support!
>
> Kind Regards,
> Gerben Schut
>
>
|
|
|
|
Members
Search
Help
Login
Home
