But yes, I think the Netherlands has the first GTFS-realtime feed in Europe. I hope this will set an example for our neighboring countries.
Kind regards,
Thomas Koch
OVapi.
We're technically not the agency ourselves but we take the (transmodel) datasets, integrate and convert it to GTFS (realtime).
The multiple routes with the same route_short_name are identifiable by different route_long_names.4107,ARR,1,Leiderdorp Rijnland Ziekenhuis - Leiden Stevenshof,,3,,,4083,ARR,1,Stadsdienst Alphen a/d Rijn Ridderveld Oost en Wes,,3,,,4129,ARR,1,Stadsdienst Gouda via Plaswijck en Groenhoven,,3,,,50,ARR,1,Ruwaard - Centraal Station,,3,,,211,ARR,1,Busstation - Westeinde,,3,,,188,ARR,1,Lelystad-Haven - Lelycentre,,3,,,
But i'm sensing you're looking for a way to obtain just the routes around Amsterdam?
Best way would be to transform data by removing stops from stops.txt and the subsequent relationships to stop_times,trips and routes.
myalert.type = real-time-alerts
myalert.frequencySec = 60
myalert.url = http://gtfs.ovapi.nl/new/alerts.pb
myalert.earlyStartSec = 3600
myalert.defaultAgencyId = ARR
websocket.type = websocket-gtfs-rt-updater
websocket.defaultAgencyId = ARR
websocket.url = ws://localhost:8089/tripUpdates
websocket.tripTimeUpdater = continuesDelay
<bean id="periodicGraphUpdater" class="org.opentripplanner.api.servlet.PeriodicGraphUpdater"> <property name="updaters"> <list> <bean class="org.opentripplanner.updater.GtfsRealtimeUpdater"> <property name="url" value="YOUR URL" /> <property name="defaultAgencyId" value="YOUR AGENCY ID" /> </bean> </list> </property> </bean>
gtfs-realtime-OVapi.proto
When entering your URL (http://gtfs.ovapi.nl/nl/) of OVapi (where all realtime information is contained) and executing the start-server.bat command, there is still no realtime information included when calculating a route.
Or what URL has to be entered here? (I can't find any information about this...)
I am a little bit confused about the stable and the master branch... Is it true that for the master branch a graph.properties file has to be created that includes the URL of the alerts.pb file, right? What about the tripUpdates.pb? And where does OTP get information about thefile?
Besides, the graph.properties has to be saved in the same path where the the graph is located, right?
Furthermore, is there also a standalone version of the master branch like the Trimet OTP.zip where only configuration files need to be changed and a simple start-server.bat can be executed? Or is it only accessible via Eclipse or Netbeans?
I mean, I have already loaded the mmri branch into eclipse and successfully created a graph after adapting the graph-config.xml, but I don't know how to start the server to be able to access the webinterface.
Sorry for this bunch of questions, but
everything seems very complicated without any documentation...
Would be nice to get some information about this. Thank you!
myalert.type = real-time-alerts
myalert.frequencySec = 60
myalert.url = http://gtfs.ovapi.nl/new/alerts.pb
myalert.earlyStartSec = 3600
myalert.defaultAgencyId = ARR
gtfsrt.type = stop-time-updater
gtfsrt.sourceType = gtfs-http
gtfsrt.defaultAgencyId = ARR
gtfsrt.url = http://gtfs.ovapi.nl/new/tripUpdates.pb
gtfsrt.tripTimeUpdater = continuesDelay
Based on the fact that i don't see a StopTimeUpdate.ScheduleRelationship.SCHEDULED explicitly given, these delays are in fact the actual achieved delays based on the difference between timestamp in the arrival/departure message and scheduled time.
Pretty sure the 0sec arrival-delay's in this case are just missing a arrival trigger message though.The delay going up and down is an expected behavior due to the planned extra time with regard to drive times and dwell times.
If the arrival-punctuality is positive, it is assumed the trip-punctuality will not increase, but instead will decrease. To achieve that the difference between the scheduled drivetime and theoretical maximum speed are subtracted from the punctuality at each following stop until the punctuality approaches 0.
Am Montag, 24. März 2014 17:32:46 UTC-4 schrieb Thomas Koch:Based on the fact that i don't see a StopTimeUpdate.ScheduleRelationship.SCHEDULED explicitly given, these delays are in fact the actual achieved delays based on the difference between timestamp in the arrival/departure message and scheduled time.
Does it mean that there is a route guidance system running in the background that permanently calculates the delay between the current vehicle position and the next stop in the trip? Or how is it possible to get the delay information?
Pretty sure the 0sec arrival-delay's in this case are just missing a arrival trigger message though.The delay going up and down is an expected behavior due to the planned extra time with regard to drive times and dwell times.
Ok so there is a lack of trigger messages that won't be written into the tripUpdates.pb file, which is, after taking a look at the whole decoded tripUpdates.pb file, an enormous amount of missing information. So, does OTP use every single stop arrival and departure delays for the calculation of the overall delay of a particular trip? Or does it just take the arrival delay information from the last stop_id?
If the arrival-punctuality is positive, it is assumed the trip-punctuality will not increase, but instead will decrease. To achieve that the difference between the scheduled drivetime and theoretical maximum speed are subtracted from the punctuality at each following stop until the punctuality approaches 0.
So because of the assumption that the trip-punctuality will decrease over time, it also means that, because of unexpected incidents, the delay information gets more and more inaccurate over time if the trip has plenty of stops, right?
Ok so there is a lack of trigger messages that won't be written into the tripUpdates.pb file, which is, after taking a look at the whole decoded tripUpdates.pb file, an enormous amount of missing information. So, does OTP use every single stop arrival and departure delays for the calculation of the overall delay of a particular trip? Or does it just take the arrival delay information from the last stop_id?OTP takes delays from each stoptimeupdate, note GTFS-RT has the delay-propagation thing where the same delay is propagated to subsequent stops, see https://developers.google.com/transit/gtfs-realtime/trip-updates
I also realized that a large amount of trips won't be finished with the status "STOPPED AT" the last stop, which means that it isn't possible to filter a whole trip out of the real-time information. Is there a certain reason why this is the case?
The new version of OTP is easier to deploy, without messing with XML files and such. It automatically loads GTFS en OSM files from a specified folder and if a Graph.properties is present also realtime feeds.I think there are no binaries present of the mmri-rt branch or master branch but it's not that hard to create those yourselves using git and maven.git checkout mmri-rt (for mmri-rt branch)mvn package -DskipTestsAnd you should be all set.
Op woensdag 19 februari 2014 21:30:02 UTC+1 schreef steiner...@gmail.com:No I just want to try to set up a single instance for a research for university, including GTFS realtime information. At the end I want to analyze some previous realtime data using locally stored realtime feeds from different dates.
What I have done so far is using the Trimet OTP.zip (http://maps.trimet.org/otp-dev/otp.zip), downloading OVapi GTFS data for Netherlands as well as OSM data for Netherlands and changed the graph-builder.xml file to be able to build a graph from Netherlands. The routing graph that was created is about 1,8GB and works well if I start the http://localhost:8080/opentripplanner-webapp.
The next step should include the RT information as well. Because of this, I found the OTP Documentation (https://github.com/opentripplanner/OpenTripPlanner/wiki/GTFS-Realtime), where it is recommended to change the application-context.xml, which can be found in the root directory of the otp itself:<bean id="periodicGraphUpdater" class="org.opentripplanner.api.servlet.PeriodicGraphUpdater"> <property name="updaters"> <list> <bean class="org.opentripplanner.updater.GtfsRealtimeUpdater"> <property name="url" value="YOUR URL" /> <property name="defaultAgencyId" value="YOUR AGENCY ID" /> </bean> </list> </property> </bean>
gtfs-realtime-OVapi.proto
When entering your URL (http://gtfs.ovapi.nl/nl/) of OVapi (where all realtime information is contained) and executing the start-server.bat command, there is still no realtime information included when calculating a route.
Or what URL has to be entered here? (I can't find any information about this...)
I am a little bit confused about the stable and the master branch... Is it true that for the master branch a graph.properties file has to be created that includes the URL of the alerts.pb file, right? What about the tripUpdates.pb? And where does OTP get information about thefile?
Besides, the graph.properties has to be saved in the same path where the the graph is located, right?
Furthermore, is there also a standalone version of the master branch like the Trimet OTP.zip where only configuration files need to be changed and a simple start-server.bat can be executed? Or is it only accessible via Eclipse or Netbeans?
I mean, I have already loaded the mmri branch into eclipse and successfully created a graph after adapting the graph-config.xml, but I don't know how to start the server to be able to access the webinterface.
Sorry for this bunch of questions, but
everything seems very complicated without any documentation...
Would be nice to get some information about this. Thank you!
Am Mittwoch, 19. Februar 2014 09:18:16 UTC-5 schrieb Thomas Koch:It should work find with OTP, not sure whether the necessary changes have been committed to the master branch. If it's not working you should try the mmri branch. In any case this feed is being consumed by the OTP instance behind opentripplanner.eu, the settings are:#buildingwget http://gtfs.ovapi.nl/nl/gtfs-nl.zip -P build
java -server -Xmx24G -jar otp-core/target/otp.jar -a --transitIndex -l -b build
#running
java -Xmx20G -server -jar otp-core/target/otp.jar -s -a -l -g build -p 9050
We have the following Graph.properties file:myalert.type = real-time-alerts
myalert.frequencySec = 60
myalert.url = http://gtfs.ovapi.nl/new/alerts.pb
myalert.earlyStartSec = 3600
myalert.defaultAgencyId = ARR
websocket.type = websocket-gtfs-rt-updater
websocket.defaultAgencyId = ARR
websocket.url = ws://localhost:8089/tripUpdates
websocket.tripTimeUpdater = continuesDelay
Op dinsdag 18 februari 2014 19:27:53 UTC+1 schreef steiner...@gmail.com:I am currently trying to include this information into OpenTripPlanner (OTP). The GTFS information works well there, but how is it possible to include the realtime feed into OTP?For this, I tried to expand my application-context.xml like this:<bean id="periodicGraphUpdater" class="org.opentripplanner.api.servlet.PeriodicGraphUpdater">
<property name="updaters">
<list>
<bean class="org.opentripplanner.updater.GtfsRealtimeUpdater">
<property name="url" value="http://gtfs.ovapi.nl/new/" />
<property name="defaultAgencyId" value="ARR" />
</bean>
</list>
</property>
</bean>but there is no additional information when executing the start-server.bat and calculating a route. Is this the correct URL to insert?Does GTFS Realtime generally work in the stable branch or do I need the OTP master branch?Thanks for any help!
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hello all,We would like to announce that we are supplying a GTFS feed with transit data for virtually all bus/metro/train/tram and some ferry services in the Netherlands, it also contains most international connections towards Belgium, France, Germany and the UK. The feed is licensed under CC0 license without tedious constraints about what you can and cannot do with the data.The transit data used is supplied by transit agencies via the legal framework "OpenGeo ND-OV loket", in a transmodel-based format. The transmodel-data is then converted to GTFS by us.Some technical details: the feed contains shapes for most operators and we've developed a workflow that generate shapes for all rail, tram and metro lines when missing. Currently the stop-locations are directly set by the operator but we're going to switch over to the IFOPT data-set when that becomes available, this will provide a very high quality, maintained stopplace clustering (GTFS: parent stations).We're also looking to incorporate fare information, but we're currently constrained by both the unavailability of this data and the lack of suitable structure in GTFS to model the fare-structure in the Netherlands. We're optimistic about the availability of fare information changing and the flexibility of GTFS.The feed also contains transfer information supplied by Dutch railways on specific trip-to-trip transfers, indicating whether a transfer is (im)possible on trip-to-trip detail.We're also offering a GTFS-realtime feed, currently under as-is, with tripupdates, vehicle-positions and alerts. The vehicle-positions and trip-updates contain almost all bus and tram lines and the Metro in Rotterdam (Amsterdam is in the works), the only trips not covered are vehicles not equipped with the necessary hardware. Real-time train information will also be available in the future but will likely require some new additions the GTFS-realtime standard such as platform changes.The feeds are available here:Kind regards,Thomas KochOVapi