SIRI and ATIS standards
vinod
I am studying Transportation standards for building a Public
Transportation solution. have come across couple of standards for
traveler information exchange - NTCIP Advanced Traveler Information
System (ATIS) and SIRI. I m not an expert on these standards - at a
high level ATIS seems to be more exhaustive but SIRI is being used by
quite a few transit agencies. I am trying to understand the
differences and the reason behind major transit agencies selecting
SIRI. can anyone help with that information?
thanks
vinod
Frumin, Michael
Care to provide some links to the NTCIP ATIS standards you mention?
Part of why MTA chose to use SIRI for its real-time bus customer information pilot was that information, documentation, XSD files, and examples for SIRI were very easily accessible. Also:
- SIRI appears to have real and growing adoption in europe
- SIRI appears specifically tailored to this particular business area -- real-time transit customer information
- Other, more subjective factors -- looking at the model for the different web service calls and responses, it just felt right given our experience with transit operations... Where it didn't fit, it was extensible in all the right places.
Thanks,
Mike
Michael Frumin
Senior Strategic Analyst
MTA Bus Customer Information Systems
2 Broadway, 27th Floor
mfr...@mtahq.org
o: 646-252-1117
m: 646-370-0388
________________________________________
From: siri-de...@googlegroups.com [siri-de...@googlegroups.com] on behalf of vinod [vinodb...@gmail.com]
Sent: Saturday, March 26, 2011 10:17 PM
To: SIRI Developers
Subject: [SIRI-DEV] SIRI and ATIS standards
vinod
NTCIP ATIS standards reference -
http://serv1.itsware.net/ITSSCHEMAS/ATIS%20GUIDE/ATIS-ROUTES/ATISRoutingGuide/
for the user guide and examples - http://serv1.itsware.net/ITSSCHEMAS/ATIS%20GUIDE/ATIS-ROUTES/
I am new to these standards but from whatever online sources i have
come across - SIRI has better adoption rate..like you have mentioned
in your reply too
Thanks
vinod
On Mar 27, 10:42 pm, "Frumin, Michael" <mfru...@mtahq.org> wrote:
> Vinod,
>
> Care to provide some links to the NTCIP ATIS standards you mention?
>
> Part of why MTA chose to use SIRI for its real-time bus customer information pilot was that information, documentation, XSD files, and examples for SIRI were very easily accessible. Also:
> - SIRI appears to have real and growing adoption in europe
> - SIRI appears specifically tailored to this particular business area -- real-time transit customer information
> - Other, more subjective factors -- looking at the model for the different web service calls and responses, it just felt right given our experience with transit operations... Where it didn't fit, it was extensible in all the right places.
>
> Thanks,
> Mike
>
> Michael Frumin
> Senior Strategic Analyst
> MTA Bus Customer Information Systems
> 2 Broadway, 27th Floor
> From: siri-de...@googlegroups.com [siri-de...@googlegroups.com] on behalf of vinod [vinodbijl...@gmail.com]
vinod
is there a list of transit agencies supporting SIRI?
thanks again
vinod
Ofer Porat
The Israel MOT is implementing SIRI SM in a bus stops signage project.
In the project, the client is a bus stop signs server that requesting Stop
Monitoring data from the main server.
The signs server is servicing a known group of bus stops.
When requesting the "next bus" server about those stations, the client wants
to request one request for a group by using a group agreed code at the
"MonitoringRef" field in order to save the need to request multiple requests
for the same bus stops again and again.
The server will respond as if a multiple request was sent since the bus
stops codes for the requested group is known at the server.
Do you know if that approach is compliant with the SIRI standard and if
there are any known implementations that uses such mechanism ?
Thanks,
Ofer Porat
MOT SIRI consultant
Vinod,
Thanks,
Mike
Guys,
thanks
vinod
=
Gerry Akkerman
Along with several other transit agencies, we are going with SIRI.
It is an open standard and it is offered and supported by our CAD/AVL
vendor. As well, our developers have been working with it and have
found no reason not proceed. Our task at hand is designing an open
real time transit interface that is highly scalable and reliable. Our
current stance is that SIRI will be the standard for this.
What kinds of solutions are you developing?
Thanks,
Gerry
Robin V.
I don't know much about ATIS standard and didn't heard much about it,
but the link you gave seems like a good starting point.
About SIRI references, you can find some there on vdv web site:
http://www.vdv.de/en/wir_ueber_uns/vdv_projekte/siri.html
Robin
Robin V.
On Mon, Mar 28, 2011 at 3:10 PM, Ofer Porat <oferp...@gmail.com> wrote:
> Hello all,
>
> The Israel MOT is implementing SIRI SM in a bus stops signage project.
>
> In the project, the client is a bus stop signs server that requesting Stop
> Monitoring data from the main server.
>
> The signs server is servicing a known group of bus stops.
>
> When requesting the "next bus" server about those stations, the client wants
> to request one request for a group by using a group agreed code at the
> "MonitoringRef" field in order to save the need to request multiple requests
> for the same bus stops again and again.
>
> The server will respond as if a multiple request was sent since the bus
> stops codes for the requested group is known at the server.
>
> Do you know if that approach is compliant with the SIRI standard and if
> there are any known implementations that uses such mechanism ?
There's more than one way to do it. AFAICT, the way you describe is
SIRI compliant as the TS doesn't make assumptions about what a
"monitoringRef" is. It can be either a stop point identifier or a
display identifier (though it is said that a monitoring point
typically corresponds to a stop point). Nothing limits what
corresponds to a given display id.
I don't know how much MonitoredStopVisit is contained in your returned
payload but if the reply is heavy, it could be better not to proceed
the way you describe. Grouping requests is a good idea when you have a
very large protocol overhead vs data ratio (like sending a whole
tcp/ip packet for sending a single telnet character).
In SIRI, you're likely to transmit a rather heavy payload, overhead
ratio isn't a very big concern. At the opposite, sending large payload
can be *very* memory demanding. I personally would think twice before
grouping too much information in a given reply. This is even truer if
your SOAP stack rely on DOM parsing (a SAX parser will be less
concerned by memory consumption but it will still be affected by
bandwidth and transfer time concern).
If you're concerned about performance, subscribe paradigm is the best
choice (along with some binary xml serialization to push performance
even further)
Finally, If you're interested, I thought of an extension for dynamic
allocation of a monitoringRef with multiple stop point: on the first
call, consumer uses it's own unique monitoringRef along with an
extension listing the stop points related to this monitoringRef. Of
course, this is fully non standard today.
Regards,
Robin
Ofer Porat
Hi Robin
Thanks for your quick response. It is very helpful.
In Israel we decided to use the Request/Response option so subscription paradigm in out of scope right now.
By "MonitoringRef" we mean bus stops codes.
As a consultant to the government I pointed some of the disadvantages of grouping as you mentioned.
In order to be compliant with the standard as defined in the 3 SIRI parts (we believe that this is the exact definition) we decided to use our own WSDL -
<message name="StopMonitoringServiceRequest">
<part name="Request" type="siri:ServiceRequestStructure"/>
</message>
<message name="StopMonitoringServiceDelivery">
<part name="Answer" type="siri:ServiceDeliveryStructure"/>
</message>
<portType name="SOAP-Port">
<operation name="GetStopMonitoringService">
<input message="siriWS:StopMonitoringServiceRequest"/>
<output message="siriWS:StopMonitoringServiceDelivery"/>
</operation>
</portType>
<binding name="SiriSOAPBinding" type="siriWS:SOAP-Port">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- ====general services ===== -->
<!-- ====SIRI services ===== -->
<operation name="GetStopMonitoringService">
<soap:operation soapAction="GetStopMonitoringService"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="SiriServices">
<port name="SiriWSPort" binding="siriWS:SiriSOAPBinding">
<soap:address location="http://www.siri-service-location.com"/>
</port>
</service>
This way we have no limitation for how many StopMonitoring request we can send in one message.
I understand that you are not familiar with any other StopMonitoring service implementation using grouping?
Best Regards
Ofer
Sean Barbeau
SOAP.
It seems like this conversation is mainly oriented towards the
communication of transit information internally within an agencies
information system (e.g., from vehicles to dispatch). Another item
for thought is how real-time transit information will be exposed so
that 3rd party transit application developers can access the
information.
Very often, 3rd party transit software is now in the form of mobile
"apps" for cell phones. For cell phones, the use of anything like
SOAP that is very XML heavy should be avoided when possible. SOAP
drastically increases the amount of data being transferred over the
cell network as well as the processing requirements on the handset.
We document some of this overhead, including the impact on mobile
device battery life, in one of our project reports on a real-time
transit navigation app we've developed: http://pubsindex.trb.org/view.aspx?id=923659
Some of the people from OpenPlans and OneBusAway helped MTA put
together a 3rd party transit information API that is based on SIRI,
but uses a RESTful HTTP Get request format in place of SOAP. While I
can't say that I've personally used this API yet, from an app
developer's viewpoint it seems like a very good compromise to leverage
SIRI but in a format feasible for access by mobile phone apps.
More info on the MTA project:
http://groups.google.com/group/transit-developers/browse_frm/thread/fc18e4aa9a3392a7/d1c7f13994e963ec?lnk=gst&q=mta#d1c7f13994e963ec
And design of SIRI-based 3rd party API using RESTful HTTP GET
requests:
http://bustime.mta.info/wiki/Developers/SIRIIntro
So, in summary, pure SIRI may be more appropriate for internal transit
information communication, but I would suggest looking at lighter
representations of SIRI for exposing this data to 3rd party app
developers.
Mike from MTA might have more to add to this as well.
Sean
Sean Barbeau
Center for Urban Transportation Research
University of South Florida
Ofer Porat
Your points are very interesting but right now we are focused only on server
to server comm. (SIRI was designed originally for servers to servers).
In that case, we see in SOAP more advantages than disadvantages.
When we will move toward direct SIRI to cell phones we will get deep into
the issues you've mentionaed.
Thanks again
Ofer
-----Original Message-----
From: siri-de...@googlegroups.com
[mailto:siri-de...@googlegroups.com] On Behalf Of Sean Barbeau
Sent: Tuesday, March 29, 2011 4:38 PM
To: SIRI Developers
Frumin, Michael
SIRI was clearly a great candidate, but obviously the SOAP calls are way too burdensome for people looking to make a quick app. Thus the RESTful version you linked to, taking the parameter names from the XML elements that would be in the SOAP request.
There still exists the concern of the verbosity of SIRI as a response format that would need to go over the air to smartphones. It doesn't appear to have prevented app development around our 1-route pilot so far.
Nevertheless, I'm interested in the community's thoughts on non-XML interchange of SIRI data. That is, the same data elements and data model, but interchanged via JSON or, for example, Google Protocol Buffers.
Thanks,
Mike
----- Original Message -----
From: Sean Barbeau [mailto:bar...@cutr.usf.edu]
Sent: Tuesday, March 29, 2011 10:38 AM
To: SIRI Developers <siri-de...@googlegroups.com>
Subject: [SIRI-DEV] Re: SIRI and ATIS standards
Robin V.
requirements (AVL to Passenger Information System, operator to
authority information exchange, etc.) from "B2C" requirements (public
API for mobile or web is the first use case for this).
I'm not too concerned (at the moment) with B2C requirements, but even
for B2B use cases, it could be smart to enhance vanilla SOAP.
From a personal point of view, like Ofer does, I think that SOAP has
more benefits than drawbacks from a B2B perspective. Thus, I would
recommend using Binary XML (to circumvent XML verbosity) and maybe
SOAP/TCP (to circumvent HTTP overhead).
Of course, these two technologies aren't the most widely spread, but
they have the big advantage to allow convergence of a basic HTTP/SOAP
implementation (more standard) and more efficient TCP/BinaryXML
(through pure technical adapters).
I've made several interesting and positive experiments with
Fast-Infoset (very easy to set-up from most java soap stacks). Note
that the very recent (20110310) promotion of EXI v1.0 (efficient xml)
to the rank of W3C recommendation is also an interesting fact.
On technical details, SIRI standards propose SOAP and XML, but there's
some freedom left for technical details...
JSON can be lighter than pure XML this is not true anymore with
fast-infoset. Furthermore, according to some benchmarks I did, SOAP
implementation are now incredibly fast and optimized (in my tests, it
was faster than both rmi, json...). I suspect that more job was done
to optimize widely spread SOAP stack (to take advantage of SMP
architectures) than spent on JSON libs (maybe it wasn't jackson at
that time?). Of course, it was just a benchmark and this conclusion
worth what it worth (it's a case, it was true at that time, under
those circumstances, but it's not a tautology).
In my opinion, JSON strengths are more linked to web interoperability
than related to performances concerns.
Protobuf is seducing, but I would look at it only if it can stay close
enough to soap "standards" (hum).
In all cases, keeping reference to SIRI model is what really matters.
That was "my 2 cents" :)
Regards,
Robin.
Frumin, Michael
-----Original Message-----
From: siri-de...@googlegroups.com [mailto:siri-de...@googlegroups.com] On Behalf Of Robin V.
Sent: Monday, March 28, 2011 3:14 PM
To: siri-de...@googlegroups.com
Robin V.
website. Maybe you could drop them a little mail for this...
Robin
Bruns, Winfried
Guten Tag!
I am the convenor for the CEN group which has built SIRI: CEN TC278 Wg3 SG7. I am happy to hear that SIRI is used not only in Europe but all over the world!
It would be fine, if you could send me information about SIRI projects you have finished, so I can publish them on http://www.vdv.de/en/wir_ueber_uns/vdv_projekte/siri.html
Please supply
- Project name
- Country and City or region where SIRI is used
- Company name which uses SIRI
- Company which has built or delivered the SIRI solution
- The SIRI services used in the project
In the last meeting of the CEN group it was decided, that works for building an updated version of parts 1-3 should start in November this year.
The updated version will respect demands which have been discovered during the use of SIRI in the past years.
I would like to invite you to send us a note if You feel the need for modifications in the current SIRI version (br...@vdv.de).
Please note that the flat structures in SIRI, which have been introduced in the current SIRI version for backward compatibility with legacy systems are planned to be deleted in the coming version of SIRI:
You should not use the structures with a name ending on „AsGroup“ but the standard-Structures. Example: Use structure “MonitoredVehicleJourney“ instead of “MonitoredVehicleJourneyAsGroup". The latter one will be deleted in the future SIRI version.
Please send me a note if you should already have used the now deprecated flat structure.
Yours
Winfried Bruns
Verband Deutscher Verkehrsunternehmen
Dipl.-Kfm. Winfried Bruns
Head of Information Processing
Fon: 0221/57979-120, Fax: 0221/57979-8-120
Mail: br...@vdv.de, Internet: www.vdv.de
Verband Deutscher Verkehrsunternehmen e. V. (VDV)
Kamekestraße 37-39
50672 Köln
Präsident: Jürgen Fenske
Geschäftsführung: Hauptgeschäftsführer N.N.,
Dr. Martin Henke, RA Reiner Metz
Vereinsregister-Nr. VR 4097
LELLOUCHE David
- Project name :COWS and PEPSI for RATP,
- Country and City or region where SIRI is used: France. Ile de france area
- Company name which uses SIRI: RATP, SNCF, VEOLIA, KEOLIS
- Company which has built or delivered the SIRI solution: IXXI for RATP.
- The SIRI services used in the project: Only stop monitoring and general message.
I think that the STIF or other operators could send you informations about the other SIRI solution and certainly a feed back on our first experiment
by our cen mirror french working group for the next meeting.
best regards
david lellouche
-----Message d'origine-----
De : siri-de...@googlegroups.com [mailto:siri-de...@googlegroups.com] De la part de Bruns, Winfried
Envoyé : vendredi 8 avril 2011 10:59
À : siri-de...@googlegroups.com
Objet : [SIRI-DEV] SIRI: Update and List of Projects
Bruns, Winfried
Guten Tag!
Thank you for the information. It´s on the web now:
http://www.vdv.de/en/wir_ueber_uns/vdv_projekte/siri.html
Mit freundlichen Grüßen
Winfried Bruns
Verband Deutscher Verkehrsunternehmen
Dipl.-Kfm. Winfried Bruns
Fachbereichsleiter Informationsverarbeitung