| Re: [sumo-user] Sumo Simulation of Osnabrück |
Hi Jan, thank you for the detailed report. Unfortunately there is no standard way of doing this in Germany. Every city has its own model, so most of the time we start with an OSM import via the web wizard as well and improve incrementally. Best regards, Michael Am 02.02.2018 um 12:17 schrieb sumo@xxxxx: > 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: > > MAP DATA > > 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, > probably). > > TRAFFIC DEMAND > > 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. > > MODEL CO-EXISTENCE > > 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. > > Jan > > 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 >> sumo-user@xxxxxxxxxxx <mailto:sumo-user@xxxxxxxxxxx> >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> https://dev.eclipse.org/mailman/listinfo/sumo-user > > > > > _______________________________________________ > sumo-user mailing list > sumo-user@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/sumo-user >
Attachment:
signature.asc
Description: OpenPGP digital signature