Home » railML newsgroups » railml.timetable » Fahrgastzahlen in railML
Re: Fahrgastzahlen in railML [message #940 is a reply to message #934] Thu, 14 March 2013 12:06 Go to previous message
Christoph.Jobmann is currently offline  Christoph.Jobmann
Messages: 12
Registered: October 2010
Junior Member
Dear all,

Dirk Bräuer wrote:
>
> Dear all
>
> and @dear Christoph: Which kind of "Fahrgastzahlen" do you mean? Actually
> counted numbers of passengers of the past? Or expected numbers of
> passengers in the meaning of "minimum seating places to be available"?
> [...]
> Concerning numbers of passengers in the second meaning (expected), they
> are clearly a matter of <timetable> in the pre-planned meaning so I could
> imagine some elements and attributes for them in the current scheme. But I
> would name them "minimum necessary places" or so - not "passenger numbers"
> to clarify the difference.
>

Personally I am not involved directly in this topic but the colleague that
approached me was thinking about expected passenger numbers.
It might be used as a measure to point out the required capacity as Dirk
pointed out, but also to give a measure for the expected revenues from
ticket sales - which would be an argument against using the term "minimum
neccessary places" (even though I do realize that passengers without a
seat are less happy in general).

However I do not see such a big difference between actually using a given
passenger number as an "expected number" versus a "counted number": It
might even be distinguished via an appropriate scope attribute
("expected", "actual", "average", "requested", etc. or similar).

> It would fit to the typical "Musterfahrplan" (pattern timetable) of
> advertisements / competitions where normally all trains have minimum
> places to be provided by the competitor. Often they are distinguished by
> operating days (Mon-Fri, Sat, Sun). So either we allow a kind of
> operatingPeriodRef with this information or we expect to place different
> trains/trainParts for each operatingPeriodRef. The latter would be ok from
> my side.

I would prefer to see several occurences with distinct operatingPeriodRef
within one trainPart but it would also be okay to repeat the trainPart
themselves.

Best regards
Christoph



--
----== posted via PHP Headliner ==----
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: problems with <train>s: uniqueness constraints, scope
Next Topic: train uniqueness constraint II
Goto Forum:
  


Current Time: Thu May 16 16:48:45 CEST 2024