WEBVTT 00:00.000 --> 00:10.960 So, welcome to this talk about OTP. 00:10.960 --> 00:17.520 You had a bit about open trip planer before, but I hope to give you some more information 00:17.520 --> 00:23.680 about how you can use open trip planer and what I have been using open trip planer for 00:23.680 --> 00:27.840 the past few years. 00:27.840 --> 00:34.360 So, my name is Jonas Linson, I'm a software developer living in Sweden in Gothenburg, South 00:34.360 --> 00:37.680 Potter of Sweden, or South Western Potter of Sweden. 00:37.680 --> 00:44.160 I have been working with public transportation solutions for 25 years and with open trip 00:44.160 --> 00:52.080 planer for the past 6 years setting up and configuring the open trip planer solution 00:52.080 --> 00:57.960 for the southern part of Sweden. 00:57.960 --> 01:05.000 So open trip planer is a multimodal search engine, it's a Java application that has been 01:05.000 --> 01:09.040 in development since 2009. 01:09.040 --> 01:14.480 We have cleared a hair for that has been involved for, I don't know, if that is from 01:14.480 --> 01:19.400 the start and some of the e-dwell preserves as well. 01:19.400 --> 01:27.800 It is a active community, but we are also actively sitting for more competent developers 01:27.800 --> 01:33.640 to be able to extend all the capabilities of this platform. 01:33.640 --> 01:39.920 We have, as we can see here, a range 100 commits per week. 01:39.920 --> 01:44.760 So, is that a lot or is that very little? 01:44.760 --> 01:51.440 It depends on the product that you are working on, some of you might find that lot or 01:51.440 --> 01:56.200 some of you might have more than 100 commits per day, I don't know. 01:56.200 --> 02:05.520 The developers are actively sitting and developing together since starting of this year 02:05.520 --> 02:13.680 and they have an active form for discussing all the matters for that all the difference 02:13.680 --> 02:21.600 in the different people are experiencing and we are using it for that as well. 02:21.600 --> 02:29.760 Many of the talks they have been considering data and data is the core of being able to 02:29.760 --> 02:37.200 do development as you are only hearing from the previous talk as well. 02:37.200 --> 02:45.560 And open free planner handles time-tube data on both analytics and GTFS formats and also 02:45.560 --> 02:52.800 real-time information, which is very important in both the series as we have some 02:52.800 --> 03:01.960 targets before and GTFS RTS, and to be able to transfer between different stops, you 03:01.960 --> 03:08.840 also need to route on the street network and there we consume the information from open 03:08.840 --> 03:09.840 street map. 03:09.840 --> 03:19.920 So that is a really important part of being able to do and transfer its calculations. 03:19.920 --> 03:22.920 Here are some of the numbers that we are handling. 03:22.920 --> 03:31.920 We have 8.000 stops, so almost as many as people here in Phastam today were 03:32.160 --> 03:34.160 this weekend. 03:34.160 --> 03:41.520 We manage more than a million addresses to be able to decide from your home address to 03:41.520 --> 03:44.000 a specific stop or vice versa. 03:44.000 --> 03:46.680 If you sitting at work, you want to go home. 03:46.680 --> 03:54.000 You can either use a search for the address or if you know the longitude and let's 03:54.000 --> 03:59.320 you, some of you might do that, you can do that as well. 03:59.320 --> 04:08.560 We handle real-time data, so we have 300 real-time updates per second, which we consume 04:08.560 --> 04:18.600 to be able to provide a travel message that is current for you. 04:18.600 --> 04:25.880 So that is 300 queries per second, roughly 1 million queries per day. 04:25.880 --> 04:33.840 And at the core of being able to provide search results, we have time table data, which 04:33.840 --> 04:43.920 most of you might see in this decision and be translating that into just CSE files, might 04:43.920 --> 04:49.880 be one solution, but I would like, or I mean, it's much prefer to have months of something 04:49.880 --> 04:55.880 more structured like a GTFS or Netflix data. 04:55.880 --> 05:04.880 And using that information, routing as the core of OTP functionality. 05:04.880 --> 05:12.280 So in this room, we are, I think, the definition room or the specification of this room 05:12.280 --> 05:22.120 was 80 people, so 100 of the total people here at Boston this weekend, roughly, so the 05:22.120 --> 05:27.760 total amount in here at the conference is 8000, which are the amount of stops that we 05:27.760 --> 05:32.360 handle in front of, or it's off the screen. 05:32.360 --> 05:41.520 And when a person wants to travel, he needs to decide, or the engine needs to do the calculation 05:41.520 --> 05:51.360 on how to provide a good transit's alternative between all of the people at Boston. 05:51.360 --> 06:00.760 Or only in this room, you can have many different alternatives, how to get from the here 06:00.760 --> 06:03.000 to the end of the room. 06:03.000 --> 06:06.880 So that is the core of the functionality. 06:06.880 --> 06:11.280 And we also have the problems with the real-time updates. 06:11.280 --> 06:18.760 So in some cases, it's just that you just barely make it to the train, or bus, on in 06:18.760 --> 06:25.000 some cases, you just barely miss it, but it is very important when you do your searches 06:25.000 --> 06:31.480 that you get the information or the suggestions that are still possible to take. 06:31.480 --> 06:37.080 And sometimes you can just run and then you make the transfer. 06:37.080 --> 06:45.680 And sometimes I think that many of you going here experience some of the problems that 06:45.680 --> 06:51.240 occurred this weekend, that there are lots of delays and lots of cancellations and in case 06:51.240 --> 06:55.920 of cancellations, you can't go at all. 06:55.920 --> 07:06.480 In some cases, delays or this situation, we have had 20 below, and the during the Christmas 07:06.480 --> 07:08.080 weekend and such. 07:08.080 --> 07:16.520 And if you get stranded on a stop with snow, 20 below, then you really, really need 07:16.520 --> 07:23.040 a real-time based travel solution that can get you where you're going. 07:23.360 --> 07:29.240 Now you need to get real-time data that is accurate. 07:29.240 --> 07:43.840 Some people have more troubles for needs to have actual processing information on how 07:43.840 --> 07:46.800 to get from one place another. 07:46.880 --> 07:54.640 Open Trip Planner does have a solution or panel wheel share searches. 07:54.640 --> 08:03.160 And what is a wheel share accessible, accessible search, it depends. 08:03.160 --> 08:11.640 As many things you have talked about before here, data quality is very key to making it 08:11.640 --> 08:21.960 possible to provide a valuable search results. 08:21.960 --> 08:31.720 In some cases, it would be very nice to have a flux capacitor in your transfer. 08:31.720 --> 08:35.920 There are me also looking at data. 08:35.920 --> 08:39.960 There are definitely time-traumal nutrients in Sweden. 08:40.400 --> 08:43.160 I don't know if you ever know that. 08:43.160 --> 08:51.960 So if a traffic operator knows of a delay at a stop, and they do a manual update on 08:51.960 --> 08:57.560 the next stop and saying, we know that the train will be 20 minutes late. 08:57.560 --> 09:08.600 If they don't then update the stop after that, you can go from one stop to the next 09:08.640 --> 09:11.440 in-minestimments. 09:11.440 --> 09:14.280 So this of course is a problem. 09:14.280 --> 09:21.640 And we do manipulate the information to, as this is nothing case, we don't have 09:21.640 --> 09:24.200 and try to own the trains in Sweden. 09:24.200 --> 09:29.640 Maybe in future, I don't know, or maybe in the past. 09:29.640 --> 09:35.560 So another information or consistency problem that we have with Rio de la 09:35.880 --> 09:40.600 Beta is what if we don't have any real-dometat? 09:40.600 --> 09:48.040 If we have only the time-table information available, then the user that watches the 09:48.040 --> 09:55.960 map and their mobile app, they see that there might be a bus on this way. 09:55.960 --> 09:59.480 I think that you won't have experience this, right? 09:59.480 --> 10:09.560 So, and in the application for Scona, the position for those buses are transparent, 10:09.560 --> 10:11.720 so does the goes buses? 10:11.720 --> 10:13.880 Will there be a bus? 10:13.880 --> 10:15.960 Will there not be a bus? 10:15.960 --> 10:18.680 That is the message, right? 10:18.680 --> 10:26.280 So to manipulate the real-dometat, to be able to trust it, that is very important. 10:26.280 --> 10:35.240 And we have had some of the talks here also focusing on the key aspect of having real 10:35.240 --> 10:38.280 real, really accurate data. 10:38.280 --> 10:44.360 And being unable to understand what that data means, it's also important. 10:44.360 --> 10:51.680 When I first looked at some issues that we have, I thought this happened. 10:51.680 --> 10:53.680 The train that seems just platform. 10:54.640 --> 11:02.000 It arrived out in one platform, and it left on another platform. 11:02.000 --> 11:04.720 So I thought that this was the case. 11:04.720 --> 11:06.800 It wasn't a big surprise. 11:06.800 --> 11:09.840 No, no, 111 trains in Sweden either. 11:09.840 --> 11:11.760 Bombers, right? 11:11.760 --> 11:19.600 But after train arrives at platform 1, and it is disconnected so that the only different 11:19.680 --> 11:25.280 part of the train continues, it leaves on platform 1, 8. 11:25.280 --> 11:28.400 Two different platforms. 11:28.400 --> 11:34.160 So it is not a levitating train, also for the future in Sweden. 11:34.160 --> 11:37.680 So maybe next year, right? 11:37.680 --> 11:42.800 And to be able to travel, don't only go by train. 11:42.800 --> 11:45.120 You use your feet, right? 11:45.120 --> 11:53.200 To get to the final destination, or some of you might feel the train station as the final destination. 11:53.200 --> 11:58.080 I think train stations are very nice in bus stations as well, but I don't live there. 11:58.080 --> 12:05.280 So I go by, I continue from the bus stop and train stop by foot. 12:05.280 --> 12:11.680 So it is very important to also use the OpenSuite map data to be able to chance get to the end 12:11.680 --> 12:14.800 point, or where I'm actually going. 12:14.800 --> 12:22.880 If the street map data isn't connected to the public transport data, then it's not possible to do 12:22.880 --> 12:25.840 the transit on a specific stop. 12:25.840 --> 12:34.080 Because I can't exit the bus, because there is no street available actually in the data. 12:34.080 --> 12:39.840 So it is as if the street doesn't exist at all. 12:39.840 --> 12:49.920 So then the routing engine, having no possibility to suggest a transfer at a stop, 12:50.720 --> 12:59.680 unless you go to the next stop, or the stop on that, and get off, transfer, and go back. 13:01.360 --> 13:06.960 And the people using the app are very confused. 13:06.960 --> 13:12.480 So aren't the public authority, and transfer to authority? 13:12.480 --> 13:15.040 No, what they're due. 13:15.040 --> 13:21.520 And the answer is, yeah, there might be some truth to that as well. 13:21.520 --> 13:28.000 But it is the quality of data, and the all the hard work that the people update in the 13:28.000 --> 13:31.760 upper street map information is due. 13:31.760 --> 13:36.400 But up near the information is not always enough as well. 13:36.400 --> 13:49.360 We have to decide on what different things matter, or the, I was a bit distracted. 13:49.360 --> 13:53.280 There are one map, and one stair at the button left. 13:53.280 --> 13:59.520 And there is one larger stair in the middle of the image. 13:59.520 --> 14:03.760 Are those one, two, or three stairs? 14:03.760 --> 14:05.360 Right? 14:05.360 --> 14:11.520 When you have a flat platform, as you have many longer stairs, 14:11.520 --> 14:15.360 does that still make it one stair, or is it a team? 14:15.360 --> 14:24.400 And this depends, or this makes a difference, because when you have a longer stair, 14:24.400 --> 14:34.720 then the routing engine has to consider the transfer time, which is times 1.5. 14:34.720 --> 14:37.040 Or, yeah, how you can feel it. 14:37.040 --> 14:45.040 So the people that have set up the transfer times between the train and the bus, 14:45.040 --> 14:49.040 if they think that that's two stairs, 14:49.040 --> 14:53.280 then they have decided, OK, this is the travel time, 14:53.280 --> 14:55.600 and that we can have this suggestion. 14:55.600 --> 15:01.360 And if open street map data is not accurate, 15:01.360 --> 15:06.320 then we won't have that as a valid transfer point. 15:06.320 --> 15:12.320 So we won't have that option in the results. 15:12.320 --> 15:16.720 But it would be always fun as a way. 15:16.720 --> 15:22.160 It might not always be the way that you want it to. 15:22.160 --> 15:28.000 But it is the way that the data allows it to do. 15:28.000 --> 15:35.200 And I hope to have maybe one more developer, or two, 15:35.200 --> 15:40.000 to make it more and better, solution to get 15:40.000 --> 15:44.080 public transportation for all of you. 15:44.080 --> 15:45.680 So does it?