WEBVTT 00:00.000 --> 00:11.520 Thank you, so I'm Louie, I'm walking at SNSF on the project OSD. 00:11.520 --> 00:18.560 It means open source railway designer and I will present the integration of NGE and let's 00:18.560 --> 00:25.200 take it out with just had a presentation about it in OSD. 00:25.200 --> 00:34.080 Edron told you about about, okay, Edron told you some things about the macroscopic 00:34.080 --> 00:43.640 level of the tail and at OSD we walk at a microscopic level of detail, we'll see how we do that. 00:43.640 --> 00:52.760 To make short OSD is an open source software that does transformation and helps design 00:52.760 --> 01:03.960 timetables that finally guide railway evolution and I recorded the short video if it's 01:03.960 --> 01:13.960 walking. Yes, to show you how OSD works, so I open the test scenario and I have on the 01:13.960 --> 01:21.240 left my list of train with the departure times and there are a lot of times and the rolling 01:21.240 --> 01:31.880 stocks are concerned and on the right I have more details, diagrams and analytics but this is not 01:31.880 --> 01:42.280 really important today and here we can see the itinerary of this train, for instance, on the map 01:43.960 --> 01:49.160 that we use for this scenario and we can see a lot of things here, the signals but also 01:49.240 --> 02:01.080 hidden, the electrification, the tracks, the blocks, the main things, yes, the sets and each train of 02:01.080 --> 02:10.280 this list is simulated on this microscopic infrastructure and we also can see if there is some 02:10.360 --> 02:21.240 conflicts in between the trains and what we can do is to visualize this timetable with another 02:21.240 --> 02:32.360 tool. So what you need to know is that the squares are the nodes that it represents the 02:32.440 --> 02:41.000 train stations and the lines, the trains of our timetable, we can see the departure times and 02:41.000 --> 02:48.120 a lot of times each node, the running time in between and we can navigate through it, we can also 02:48.120 --> 02:58.440 edit a train for our timetable on this tool and it changes synchronizes automatically. 03:02.360 --> 03:11.400 And this view is very important because it makes it easy to compare a transport plane and it 03:11.400 --> 03:21.480 can quickly analyze the performance of timetable and so this is not surprised, it was actually 03:21.480 --> 03:30.600 two softwares, one embedded in another and I will explain you how we did it, but first I will 03:30.600 --> 03:38.600 present briefly our CD, then NG even though we just had a presentation about it and spend some time 03:38.600 --> 03:51.240 for the design of the solution. So our CD we have many purposes and one of the main one is to 03:51.240 --> 03:58.600 reduce our dependence for the software market, you just mentioned via a tool and these 03:58.680 --> 04:08.840 elements that we aim to replace them with our free and open source software. We also work on the 04:08.840 --> 04:15.480 standardization of the tools of this industry because it can make it easier to work at the 04:15.480 --> 04:20.680 international, for instance, will also develop reasonable bricks not only for the railway industry 04:20.680 --> 04:28.200 but for other domains we try to be agnostic and for that we are the first hosted project of 04:28.280 --> 04:40.280 open rail association. And we are around 45 full-time person walking at S&CF on this project 04:41.080 --> 04:48.600 and this is very useful because we directly benefit from the insights of the person actually using 04:48.600 --> 04:53.880 our tools, I mean this kind of tool which is not always the case for software vendors. 04:54.040 --> 05:07.080 And NG, so in that's graphic editor you just had a presentation. In brief it's a very long term 05:07.080 --> 05:13.560 transport plan, transport plan designer that produces network graphic or in that's graphic 05:13.560 --> 05:21.480 in German and this is interesting to notice that they split their project into repositories 05:21.560 --> 05:28.680 one for the front end and one for the back end. And how did we manage to integrate 05:28.680 --> 05:35.160 NGF editor in OSID? We had a few constraints or guidelines, do not break NGE. 05:37.160 --> 05:43.880 Evolvated our needs and capacity because we have limited time. We want to think reasonable 05:44.840 --> 05:52.200 not only for our own use but for others and it has to be easy to maintain and get up to date. 05:53.960 --> 06:02.920 So how to make NGE usable? So for the back end we've seen that we have similar technologies 06:04.040 --> 06:11.160 but we are not sure to consider this option because we want to keep our stack clean and simple 06:11.240 --> 06:20.360 I mean try. And for the front end the design of NGE has NGE has been designed for 06:21.240 --> 06:30.520 relying almost fully on its front end. So the front end is very powerful and the back end actually 06:30.520 --> 06:37.560 is only used for persistence, the thing that we already have at OSID. So what if we can use 06:37.640 --> 06:46.040 only the front end of NGE and integrate it in OSID, like a front end package or something and make 06:46.680 --> 06:57.400 communication with it. So this feature didn't exist to just get the front end and with the 06:57.400 --> 07:06.200 refers to a refactoring NGE as separate web component but it was too much time. And we thought about 07:06.280 --> 07:15.560 another option and refactoring some code NGE to make it able to run without back end. It's 07:15.560 --> 07:26.120 actually the demo you just seen before. It's based on that. So we developed a standalone mode 07:26.120 --> 07:35.160 that runs without back end and we published a build of this version on NPM that we can use 07:36.440 --> 07:48.440 any other JavaScript framework. So that's nice. And even if it can run alone it does not communicate 07:48.440 --> 08:01.880 with anything except itself. So we had to figure out. And we decided to go through custom elements 08:01.960 --> 08:09.880 because NGE was aimed to be embedded in another software. So we could just create 08:09.880 --> 08:16.440 a custom element on NGE side and communicate with it using the element accessible from the 08:16.440 --> 08:24.440 outer of NGE. And this way we could send that inside NGE from the outer of it. We'll see after 08:24.520 --> 08:35.400 how it exactly works. And for us, we instantiate it in an iFrame. And last because we have 08:35.400 --> 08:44.520 specific needs we decided to fork the repository of NGE but just for minor changes that we 08:44.520 --> 08:53.080 cannot push on the main. And we tried to reduce the number of this hacks. It's mainly to hide 08:53.080 --> 09:05.560 some elements or to misuse others that we don't know how to use it. And now we'll see how 09:05.720 --> 09:16.040 we constricted it. So first we are based on OSAD which has a complex stack because it's 09:16.040 --> 09:23.400 designed to be scalable and some other things. But we will reduce this cup on the back end and the 09:23.400 --> 09:29.880 front end. For the back end we have a WordPress tool for the base and rest as a middleware and 09:29.880 --> 09:38.840 other things for the simulations or the the type of lines. And the front end is written in type 09:38.840 --> 09:46.920 script and NGE. So now we can use what we said earlier. The NGE standalone version. 09:48.520 --> 09:57.160 That's now runs inside OSAD but cannot communicate with anything. So this is nice because 09:57.240 --> 10:02.120 we succeeded to be agnostic of the different of the JavaScript frameworks. 10:04.360 --> 10:13.080 After some digging we found that the central element of object of NGE is an end graphic detail. 10:14.360 --> 10:22.760 In this object this object digs. It is thanks to this object that NGE displays what it displays 10:22.760 --> 10:27.480 the nodes, the tryanons and stuff. So we need to find a way to put data in this object. 10:28.680 --> 10:42.760 And in Angular there is a decorator named input. That is a property bound to the element to 10:42.760 --> 10:52.120 the property and that automatically listens to changes on this element and updated that the data 10:52.120 --> 10:59.320 of the data property from the properties value. And from that we can set new data in the 10:59.320 --> 11:12.760 net graphic detail and from also from the outer. Because the the dump property is not accessible 11:12.760 --> 11:20.600 from the outer here it's called SBB root and we only need to transform our timetable 11:21.560 --> 11:31.960 into NGE compatible object. Here it's nodes and tryanons. And then that's it. We put data 11:31.960 --> 11:40.200 our data from our timetable in NGE and it's automatically updating. So what we need to do now 11:40.280 --> 11:52.920 is the run trip to send data out of NGE. So there is a lot of objects handles in NGE, 11:52.920 --> 12:00.440 tryanons, nodes, labels and stuff but it's not important. What's important is that whenever 12:01.800 --> 12:08.440 we implemented a concept operations whenever these objects are updated, created or deleted 12:09.160 --> 12:19.400 we send a message through event emitters, standardized as operations into a node put 12:19.960 --> 12:28.280 a decorator from Angular which changed the value of the dump property operations. 12:29.560 --> 12:36.760 So from the outer of it on the oversight side we can just listen to the changes of this dump 12:37.480 --> 12:48.520 property. NGE almost done. What we did already was to send the updates of our timetable 12:48.520 --> 12:57.160 whenever our timetable was changing. So we can just do the same thing and just match the events 12:57.160 --> 13:05.160 to our Saturday compatible events and that's it. We have a closed system NGE is displaying 13:05.240 --> 13:12.760 our data and is sending back the modification that we are doing in it. So that's pretty nice 13:13.640 --> 13:21.800 and not even very complicated. We designed NGE standalone to be able to process that kind of 13:22.600 --> 13:33.880 magic. So we are not the only user of this. So that was it for the solution and I will briefly 13:34.680 --> 13:44.920 finish with how we do we cooperate. So OECD is a project open source from SNCF and NGE from 13:44.920 --> 13:58.360 SBB. We are both part of OpenRL Association which is nice and currently OECD is using NGE so that's nice 13:58.360 --> 14:04.440 but what's really nice is that we made two open source project work together from big companies. 14:06.760 --> 14:11.400 And because we use their software we try to contribute to their project, 14:11.400 --> 14:19.640 not only because we have slightly bigger task force but because we like to contribute that way. 14:19.640 --> 14:27.960 So we developed a few features. We are active on their repositories and also we did some 14:27.960 --> 14:37.240 events together. For instance, the Thailand Arc, it's another hacker event organized by SBB 14:37.960 --> 14:45.080 or the Austrian and the Swiss and the German railway company. We worked there together with 14:45.080 --> 14:55.640 Adrian last year. So why not you? And I'm done with that if you have any question. We'd be glad to 14:55.640 --> 15:17.560 answer. If there is no question, that's fine. I was clear then. 15:25.640 --> 15:45.480 Why did we not use an I-frame and not directly imported application. Because it was easier for us 15:45.560 --> 16:01.240 to communicate to instantiate like it was easier for us to instantiate it in an I-frame 16:02.600 --> 16:09.960 because we could just instantiate NGE and that's all. It's separated. It's easier. 16:10.280 --> 16:16.680 Is it difficult to extract data with the same thing the problem? 16:16.680 --> 16:32.200 Good question. Because we ran directly the application at the same server. We don't have the 16:32.440 --> 16:36.840 kind of issue about security issues using I-frame. 16:36.840 --> 16:40.680 Yes. 16:45.320 --> 16:46.680 Sorry? 16:52.680 --> 16:55.320 Is or should the NGE deployable? 16:55.640 --> 17:06.680 Yes. It's already deployed internally at SNCF. It's working. You can download the project 17:06.680 --> 17:17.720 on GitHub and work with it. We are working on a public demonstration environment but it requires 17:18.040 --> 17:27.640 more data than the Microsoft speakers. So we are currently working in it and in the few months 17:27.640 --> 17:35.240 we will have such an environment for demonstration. 17:35.640 --> 17:40.040 Are there contributors outside of SNCF or could I use this project? 17:41.640 --> 17:55.720 Yes. Only a few for now. Maybe mainly because it's a very complex project but we are keen to 17:56.680 --> 18:07.320 to embark anyone that wants to contribute. We had many contributions but not for big features. 18:10.040 --> 18:12.040 Yet. 18:13.640 --> 18:15.960 Okay, thanks a lot. I think we have to change.