Siri update results of the meeting in paris 03 22 and 03 23 2012
1 / 11

SIRI Update Results of the Meeting in Paris 03-22 and 03-23-2012 - PowerPoint PPT Presentation

  • Uploaded on

SIRI Update Results of the Meeting in Paris 03-22 and 03-23-2012. CEN TC278/WG3 SG7 Winfried Bruns VDV

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' SIRI Update Results of the Meeting in Paris 03-22 and 03-23-2012' - camilla-todd

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Siri update results of the meeting in paris 03 22 and 03 23 2012

SIRI UpdateResults of the Meeting in Paris 03-22 and 03-23-2012


Winfried Bruns


Participants: Nick Knowles, Werner Kohl, Christophe Blendinger, Christophe Duquesne, Gustav Thiesing, Daniel Rubli, Gerald Dury, Ulf Bjersing, Etinee Michel, David Lellouche, Andrej Tibaut, Mike Frumin (phone), Jeff Maki (phone)


  • French Input: Results see attached document

  • Inputs from MTA / Mike Frumin 22.3. 3 p.m.

  • Inputs from Ulf Bjersing (Sweden)

  • SIRI-changes (Germany, Werner Kohl, Winfried Bruns,…)

  • SIRI-enhancements (Werner Kohl)

Decisions 24 november 2011
Decisions 24 November 2011

Changes have to be strictly backwards compatible with the existing version. Even turning an optional element into a mandatory one is not allowed (Except it can be guaranteed, that no one ever used it other than mandatory)

Changes in the document should be restricted to the requested changes. A general revision (graphs or structure) is not planned.

A lite version of SIRI will be developed. The Input from Michael Frumin is welcome. It will have to be decided if a communication layer is sufficient or if additional simple data elements (ex for dates) have to be provided.

SIRI Lite should become a annex to SIRI part 2 instead of merging it into the existing parts 1-3.

Inputs from mta mike frumin
Inputs from MTA / Mike Frumin

  • StopDistanceGroup

    • CallDistanceAlongTrip: the distance of the particular stop along the geographic route of the trip the vehicle is serving (i.e. from the beginning of the route)

    • DistanceFromCall: the distance from the vehicle to the stop along the geographic route of the trip the vehicle is serving

    • StopsFromCall: the number of stops between the vehicle and the particular stop. When the immediate next stop is the stop in question, the value is 0.

    • PresentableDistance: the human-readable string that UI’s can use to display the distance to users (e.g. in MTA’s application, changes from “X stops away” to “Y miles away” when the bus is more than 3 stops out, and changes to “approaching” when the bus is less than 150m away). This exists to allow various user interfaces to be consistent without copying logic between them.

    • Decision: This seems to be a local solution

  • Inclusion of MaximumNumberOfCalls into VehicleMonitoringRequestPolicyGroup

    Decision: Accepted

  • SIRI for Simple Web Services

    Decision: All paragraphs are accepted. Thank you for the work. Examples are welcome. In 3.7 there might be the need for some sentences on a key to identify the customer.

Inputs from ulf bjersing sweden mail 09 03 2012
Inputs from Ulf Bjersing (Sweden), Mail 09/03/2012

  • Update/correct/restructure SIRI WSDL-file.Solved by other changrequest

  • Clarify meaning of <VehicleMonitoringDelivery> <VehicleActivity><ProgressBetweenStops><Percentage>Annotation in document

  • The EndTime of the following structures must be redefined or better annotated so that it is clear when the time rangeends:

    • StructuClosedTimesRangeStructure

    • ClosedTimestampRangeStructure

    • HalfOpenTimesRangeStructure

    • HalfOpenTimestampRangere

      Decision: Only Backward compatible solution is possible. Add attribute to time structures? State that end value is exclusive? Alternatively have additional structure? Changing semantics will be the preferred solution, but has to be analyzed up to the next meeting.

  • Better support for describing real time track changes at stations in Stop Monitoring Delivery.

    Decision: Transfer StopPlace Model from IFOPT to SIRI? Alternative proposal from Nick for the next meeting?

  • Add Protected Connection element in Stop Monitoring Delivery

    Decision: Will be merged with Werner proposal

  • Other: Some minor typos were found in xsd.

Not in document in xsd
Not in Document; in XSD


Accepted : SuggestedWaitDecisionDuration

Accepted: prediction with and without wait time makes sense. Add new time element ProvisionalAimedDepartureTime

Not in document in xsd1
Not in Document; in XSD


Accepted: ProvisionalPredictedDepartureTime

Accepted: DeliveryVariant

Siri changes germany rubli
SIRI-changes (Germany, Rubli)

  • CheckStatusResponse.DataReady is missing

    Decision:additional flag for CheckStatusResponse’

  • ErrorCondition.ErrorNumber is missing

    Decision: accepted

  • CheckStatusResponse.ServiceStartedTime has to be mandatory

  • DataReadyNotification.ProducerRef should be mandatory

  • DataSupplyRequest.ConsumerRef should be mandatory

    Decision: Making elemtents mandatory would be not compatible with last version. The elements are important only when using subscription. That should be put as a hint in the document.

New inputs from the german mirror group 2011
New inputs from the German mirror group 2011

  • ViaPriorityNew element in theViaStructuretoindicate/ decidewhichinformationshallbeshowed, ifplace on a displayisrestrictedDecision: Accepted

  • New Elements PlannedStoppingPositionofthefetcherattheconnectionarea in MonitoredFeederArrival, MonitoredStopVisit,VehicleActivity and DistributorInfoGroupAccepted, See swedish comment

    • Velocity, optional element, format„Definition hastobeagreed on locally: actualspeedoraverage“ in VehicleMonitoringServiceVehicleActivityDecision: Accepted

  • Element WaitUntilDecision: AcceptedaddelementWaitingInfo in EstimatedTimetableandStopMonitoring

  • Additional optional Elements QualityofPrognosis in DepartureandArrivalAccepted; Proposalfrom Werner Kohl

  • German input werner kohl
    German input (Werner Kohl)

    • Real time data platform demands for additional information:

      • Add element for recipient address/reference to each SIRI message.

        • Recipients address in the message, not only in the hostname (accepted)

        • Additional errorcodes in SIRI error condtions (Table3) (accepted, aslo input from France)

  • RecordedArrivalTime

    Add to estimated timetable service

  • RecordedDepartureTime

    Add to estimated timetable service

  • Production Timetable Service: Include information on vehicle journeys (feeder-fetcher) that have a connection protection process in place.

  • Estimated Timetable Service: Include information on actual and current connection status (Waiting, Broken connection)

    Decision: Proposal will be formulated and sent by Werner Kohl

  • Action points
    Action Points

    Send WI Proposal to CEN (Pälen): WB

    check with CEN if SIRI part 4+5 are really adopted, change xsd in any case, may be document 4 m+5 later; Change request document from France. It is of 2011 and has not yet been dicussed

    The current version of the document is attached to the mail. Editors might change the things decide directly in the document with change track function and send it back to cc

    New version of the document and the schema will be disseminated beginning of May

    Next meeting: Neuhausen, Trapeze, Switzerland June 18 2007 9:30