Dear Erik,

creating a valid and complete network for traffic microsimulation is not
an easy task, and a time-consuming in terms of negotiations as well --
you will need support from different city authorities, otherwise your
effort will not pay off.  We are currently facing a problem of similar
size to Osnabrück, trying to model the city of Pilsen (137 square
kilometres + suburban areas served by public transport, circa 100
signalised intersections, public transport consists of tramways, buses
and trolleybuses). The model is for us only a means to simulate
different network parameters so we do not have time to do it "properly"
from the traffic engineering point of view, the centre of our efforts it
not the traffic model but some other things. Being a relatively small
city, we have support from all sections and departments of the city
office, but we struggle anyway. We hoped that we can automate most of
the tasks but despite the great scale of tools that SUMO offers for this
case we were only partially successful.
It turns out that the main difficulties when building the model from OSM
are twofold and both are in my opinion a "system problem" and not
something that SUMO developer should deal with:
 1. incomplete map data and problems with OSM import:
   1. OSM does not contain intersection info on lanes, detectors, and
      signals and netconvert heuristics does not handle those places
      properly (but maybe the heuristics built into netedit works better
      on German map data, the examples that I have seen worked quite
      will with German data),
   2. does not contain, at least in Czech case, the elevation data,
      needed for example by emission models,
   3. in some cases the netconvert heuristics fails to correctly parse
      the info stored in Czech OSM and, for example, turns all boarding
      islands that are shared by bus and tram into a short separate
      tramway track
 2. unknown traffic demand, including public transport timetables;
    as the first approximation, we are using random trips, but we
    are waiting for data from the city authorities to put them
    into the model
Some more details follow:


We have basically tried two general approaches: use the city GIS to
extract the street graph (the GIS is unfortunately quite incomplete and
useless for our case, as it for example does not hold information about
one way streets, number of lanes and so on, but see below) and when that
failed, try to import as much as possible from OSM. In our case the OSM
import works somehow, but the built-in netconvert heuristics cripples
signalised intersections and goes ballistic on shapes like shared
bus+tram lanes. The result is that all signalised intersections will
have to be modelled by hand, currently we have managed to get a rough
version running by automatic conversion where we ignore pavements and
pedestrian crossings. Co-existence of different road types over each
other is something we did not look into yet.
In order to help with identification of intersection shapes and lanes we
are currently looking into an image processing approach that identifies
lanes and stopbars at intersections from the overhead imagery or,
possibly, from the "passport of vertical road markings" (not sure about
the appropriate translation), a rarely updated GIS layer showing in
theory all vertical markings that have been put onto all streets in the
city. If that fails, being a university, we have a bunch of undergrad
students that will have that as one of the exercises in their traffic
modelling course ...
The OSM also doesn't store information about signal plans (quite
understandably), and given that we have about 100 traffic actuated
intersections that do not run fixed signal plans, we are in real trouble
there. Our first approximation will be using the fixed timing of the
backup signal plans or maybe extract and analyse actual signal plan data
stored in the reporting database of the traffic control systems (AFAIK
almost  all intersections are on Siemens's Scala). Again an awful lot of
manual work that probably cannot be avoided. As a side note: We have the
documentation for every intersection created in the original software
provided by Siemens, but their tools do not seem to support export to
open formats like XML so that we could parse it automatically ...
Elevation data is fortunately available from other Czech map providers,
we were able to mine them from one of them using a small tool written in
Java. I haven't looked into German maps but in case you need the
elevation info and it is not there, one of the possibilities would be
Google Maps elevation API (but you will have to pay for accessing it,

This has to be modelled, as we do not know the incoming/outgoing traffic
from the city, the only measurement points that we have are the
intersection detectors and some other "strategic" detectors within the
city connected to Scala. We hope that the city authorities will provide
us with a traffic assignment model based on the classical user
equilibrium, that has been calibrated to the detector readings. This
model is being updated regularly by a contracted company.

Something that bothers us quite deeply is the fact that the city will
not maintain the model in the future -- they are quite happy with their
macroscopic model (well, why not) that is even being updated and
maintained by an external company. We would like to see a unified
approach that would seamlessly propagate any changes in the city GIS
into our microscopic model, but this is not likely to happen. Hence, the
model will have to be updated manually in the future which is likely to
result in a model that will not be maintained after the current project
has ended. That's life, I guess.
If you have any further questions or comments, do not hesitate to ask.
Maybe the kind guys from DLR would be able to give you some pointers
regarding the official ways how these things are handled in Germany.

On Wed, 31 Jan 2018, at 3:30 PM, Erik Gruener wrote:
> Dear Sumo Community,
> i have a task to model an area of the German City Osnabrück with SUMO
> and do not quite know how i would do this efficiently. Any help on
> similar projects or tips and tricks on how to simulate many different
> vehicles without specifying a destination for everyone and using the
> OSM data correctly are appreciated. :)> 
> Mit freundlichen Grüßen
> Erik Grüner
> _________________________________________________
> sumo-user mailing list
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit> 

sumo-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit

Reply via email to