Experts’ Voices: Sum – es – est – SUMO – estis – sunt

August 28th, 2023 | by GEONATIVES

Posted On August 28, 2023

_{(8 min read)}

Driven by our curiosity about data formats, how established different variants are and how they are being used, we thought it would be a good idea to sneak a bit into the details of one of the most commonly used software packages for traffic simulation and start directly with that topic.

As it turns out, OpenStreetMap (OSM) seems to be the most commonly used data source for SUMO traffic networks. But it is far from representing a generalized format that can be used out of the box (one reason why SUMO has to import data and cannot run simulations directly on them) because the data format was not designed for navigation or even simulation purpose in the first place.

SUMO’s component “netconvert” has to interpret the OSM content and make it usable for the micro simulation. This process starts with making sure that lanes are described consistently, intersections are arranged in a way that they do not represent clusters but clearly defined arrangements and culminates in complementing inconsistent or incomplete attributes of data elements. Traffic lights and similar are another aspect that has to be added to OSM networks.

Therefore, why not choose something that is addressing simulation requirements better – like ASAM OpenDRIVE® (which is, of course, supported by SUMO since quite some time)? Actually, it would be a preferred source according to Jakob if only there were more data sets covering larger areas available. OpenDRIVE is mainly used for dedicated tracks, not so much for medium- to large-scale networks. High-definition navigation data could fill this gap, covering large networks by having more lane-level road information than OSM but often reasonably modeled intersections are missing as well. For now, OSM remains the gold standard in terms of coverage. The good news, however, is that “netconvert” with its interpreter-like behavior manages quite well the conversion from OSM or navigation data to OpenDRIVE, and, therefore, inherently benefits the simulation community. In the end, the import of data shall work out of the box so that the user can focus on simulation instead of fixing road networks and therefore “netconvert” gets more and more interpreting capabilities. Gaps in information shall automatically be filled e.g., by augmenting incomplete attributes based on domain knowledge or fusing intersections clusters to one big intersection.

It would be quite helpful if edited road networks were made available by the users but often such databases are kept back to not lose the advantage of a comprehensive simulation environment. Fortunately, public customers and founding regulations include the requirement of making the data (basis as well as results) publically available.

But data conversion raises another topic: heterogenous taxonomies. In order to create large databases with unified attribute assignments and data relations from various sources, it is crucial that these sources talk about the same things using the same language components. The user and developer communities seem pretty active and willing to address this topic – even in country-specific context. However, for the sake of his own efficiency, Jakob prefers to only implement the outcome of these discussions rather than spending additional time in the actual talks.

Although it might feel strange, we fully understand his personal strategy. It pretty much reflects the input we got in a talk about standardization with Brad Templeton: if you want to go fast, go alone. But in Jakob’s case, it doesn’t mean that he’s reinventing any wheels. Instead, he tries to take the wheels that others create and builds on top of them. This may, actually, be the reason for his efficiency and short turnaround times when it comes to addressing issues (read: bugs) and implementing new functionality.

Shifting from road to rail

One aspect by which we were impressed, is the recent development to take SUMO from mainly road-based traffic into the railroad sector – and, maybe, in the long run into a multi-modal operation context. First, suburban trains were added to model commuting in a more precise way. But simulating trains caught the interest of additional railroad stakeholders.

If you think road data are stored in heterogenous formats, you might want to re-think when looking at railroad data. In this domain, one finds lots of formats that are specific to individual providers and data that have been collected and processed for specific purposes. Efforts are being made to provide standardized formats (e.g. RailML) but adoption isn’t universal, unfortunately, and licensing restrictions may sometimes prevent these formats from being used widely.

Having talked about taxonomy before – the situation isn’t better in the railroad business, too: for example, the “reference track” in a station which is used to name all other tracks seems to be chosen according to the specific use case (by customer and/or by operator) and may change whenever there is construction going on. Combining all of these data sources when trying to build a railroad network for tools like SUMO is a big challenge. Sometimes data sources are even still paper-based and/or don’t have any geo-reference. Additionally it would be interesting to get the passenger information system information as open data.

Another one is that SUMO uses map-like data that shows the actual curvature and length of tracks. In the railroad business, however, it is not uncommon to use an abstracted representation of track layouts, the so-called “track plan”.

And here’s the trick that Jakob has been working on recently: converting OSM railroad track layouts into track plans. For the ones of us who have tried and struggled to do this on a small scale, it is even more impressive that Jakob seems to have managed this task on a larger scale and made it part of SUMO.

But let’s look at another aspect of railroad databases which is familiar to us from collections of road data: it’s the lack of data and the prevalence of data inconsistencies. The world doesn’t seem to be simpler just because you eliminate one degree of freedom by putting a vehicle on rails. As said before, things change over time, data sources are heterogeneous and when it all comes together in simulation, you notice each bug or mismatch. Therefore, as usual, the one who combines the data sets becomes the one to validate them and point the owners of the respective data to the flaws. Fortunately, though, most flaws are caused by missing data, not so much by actual bugs in data sets themselves. At the end mapping tables might help to link between the different data sets.

Now, imagine you have to work with a behemoth like a national railway company with all sorts of departments, separated, in addition, by operation and infrastructure. Try to report to any of these departments your findings in terms of data gaps and inconsistencies you have uncovered in certain data sets, and you will soon notice that for the sake of “efficiency” – as they call it – they will most probably refuse your input. No wonder because they might already occupy themselves with changing the reference track for the next upgrade of a station and, thus, render all prior data mapping irrelevant.

But back to SUMO itself: in addition to the network data also the traffic agents and their behavior have to be adapted for the railway domain: A train sets off differently from trucks and often trains follow specific speed courses instead of going full throttle. The validation of these dynamic models is challenging because there is no simulation tool (at least non is known to be easily available) that could be used as reference. Thus, having a look on how SUMO is letting the trains drive is currently the only validation. Calibration of the models has to be done by the users. Just as for cars, SUMO provides a list of traction models for trains, each with it’s own set of parameters and the user can pick among them or extend them.

Into the sky and beyond

Of course, more transport modes can be simulated by SUMO. Apron traffic was easily integrated but some users added also the movement of the planes including takeoff and landing. It wasn’t complex because it is quite similar to the motion of trains in terms of regulating entry to different apron sections. At the end, the many vehicle movement models such as the one by Krauß are quite flexible and can be adapted to model some aspects of plane movements.

Shipping and river traffic could be added, too. Jakob just didn’t have the time to dig into this domain to start a proper implementation of this kind of mobility. Nevertheless, it could be interesting because for some cities ferries are an important transport mode and also the freight traffic and handling of goods in large harbors are often optimized with the help of simulation frameworks as well. Also the impact on the surrounding traffic by a harbor is an objective of simulations. One of Jakob’s dream is to be able to load and ship road vehicles using other transport devices. And talking about important transport modes: what about ropeways?

All these potential additional modalities have one thing in common: OSM’s data model with nodes and ways often includes these networks already. At the end the importer will again be adapted to the input data and not the other way around.

The SUMO community

We learned that SUMO is more than just road traffic simulation; that’s why we talked also about the SUMO community. There are more contributors and contributions jumped after moving the development project to Github. Since 2017 SUMO is an Eclipse Foundation project to strengthen and streamline the discussion and progression of the development of the software. However this may adds some more constraints to contribute due to the official character but nevertheless the number of commitments is growing (despite the fact that Jakob and his colleagues are the heavy contributors doing far more than 50 percent of the work). The working groups within the Eclipse Foundation project are still small, the discussion groups are generating many wishes and a lot of them were addressed by cooperation projects. The community spirit was always good and gets better because SUMO is attracting more and more new users such as industry clients and public authorities.

These new stakeholders bring also new and old topics into the community: Industry users are using the simulation for reinforcement learning for optimizing vehicles as well as traffic control. But they still ask about the coupling with driving simulators, which started with a coupling of SUMO and Virtual Test Drive (VTD) several years ago. Often SUMO is used for the classic research questions about how to improve the routing in cities, optimize traffic light control programs and analyze the impact on and improvements for traffic of vehicle-to-anything communications. In particular, public authorities with limited budget are interested in using SUMO for their traffic management tasks and, therefore, the community is growing also in Africa and South America.

It seems to be that the SUMO community is by now large and robust enough to keep an eye on current features while adding new. Therefore, code got a longer durability than other open source projects driven only by few contributors.

After the long talk with Jakob there were still a lot of untouched topics on our and his list. It seems that we might meet again. Thanks to Jakob for this impressive work and the fascinating dive into various but nevertheless interrelated topics!