import location-based counting data

[namdre]

e.g.:

• lon;lat;dir;count
• det;count + det;lon;lat,dir

where dir is a cardinal direction

There are two possible kinds of data output here:

• edgeData files as used by routeSampler (https://sumo.dlr.de/docs/Tools/Turns.html#edge_counts)
• flowFiles + detectorFiles as used by dfrouter/flowrouter (https://sumo.dlr.de/docs/Demand/Routes_from_Observation_Points.html#dfrouter)

Further thoughts:

• flow files and edgeData files can be freely converted when the detectors exist.
• detector ids could be taken from the input data (or synthesized if missing)
• mapping coordinates to edges (see below) is the core functionality

Envisioned features:

• using location accuracy information to restrict/enlarge the set of candidate edges
• picking the most plausible road type if there are multiple candidates
• handling / reporting ambiguities

[vishalmhjn]

I have worked on this and I think it is appropriate to share my approach. I will briefly try to explain the method. Given geo-referenced files with detector locations (lat, lon), we need a map matching tool to assign these to the OSM network. I leveraged the shared-streets matcher to match the OSM links with the detector locations. Although the codes I developed are specific to my case study, I think with little formatting they can be applied to other study areas as well. These are the steps:

1. Download OSM network using Overpass API (run.sh)
2. Run the shared-streets tool to assign OSM links and geo-referenced detectors a unique SHST (shared-streets id). This tool can match points/ links with links. (shared_streets.sh) for SUMO network: shst match $SUMO_NETWORK_GEOJSON --out=$SUMO_SS --snap-intersections --follow-line-direction --search-radius=10 --offset-line=1 for detectors: shst match $DETECTORS_GEOJSON --out=$DETECTORS_SS --snap-intersections --follow-line-direction --follow-line-direction --snap-intersections --search-radius=100 --offset-line=1
3. Match the OSM links and detectors files using the common SHST attribute. (merge.py). Here we have a link-OSM/SUMO for each detector
4. Finally, generate the additional XML file for SUMO

If this approach is interesting and according to your plans, I will be glad to share the codes.

[namdre]

Thank you for sharing your approach. I'd appreciate it if you could link you codes so that others may be able to follow those steps. However, It doesn't solve the full problem originally envisioned for this issue:

• incorporating directional information into the map matching
• generating counting data files for consumption by other tools (#6609)
• (implicitly) being a lightweight tool without external requirements. Map maching geo-coordinates to a sumo network edge can already be accomplished with very few lines of code (https://sumo.dlr.de/docs/Tools/Sumolib.html#locate_nearby_edges_based_on_the_geo-coordinate)
• handling / reporting ambiguities (i.e. matching accuracy, picking the most plausible road type if there are multiple edges within the given range/ accuracy)
• mapping groups of nearby detectors to groups of adjacent lanes

[vishalmhjn]

Here is the link to the repository. I will add a working example and document it better.

[namdre]

Given a file det.csv of the following form

id;lat;lon
foo;52.432559;13.496612;1000
bar;52.432373;13.496142;500

It can be turned into a file with detectors with:

python tools/detector/mapDetectors.py -n net.net.xml -d  det.csv -o det.add.xml

With the mapped detectors and file flow.csv of the following form

Detector;Time;Count
foo;0;1000
bar;0;500

It can be turned into edgeData (i.e. for routeSampler) with an existing tool:

python3 /scr1/sumo/tools/detector/edgeDataFromFlow.py -d det.add.xml -f flows.csv -o edgedata.xml -q Count -i 60

[namdre]

a nice dataset is found at https://api.viz.berlin.de/daten/verkehrsdetektion This containts lon/lat data with direction information at a granularity of 8 different compass rose directions (i.e. southeasth, south, southwest).

[ambuehll]

I'm popping by this thread since datasets are being advertised. Here is the one we published while at ETH Zurich/NYU Abu Dhabi: https://utd19.ethz.ch

• loop detectors from >40 cities worldwide geo-referenced (Zurich, London, Tokyo, Munich, Madrid, etc.)
• traffic flow / occupancy data for the same cities in a 3-5min resolution
• free to use for research

[namdre]

loop detectors from >40 cities worldwide geo-referenced

What about a map-matching to OSM data? Is that also available? How did you / would you go about it?

[ambuehll]

It's not matched to OSM, it's only WGS84 coordinates.

The dataset also has a file with a "helper-link", which is a line shp that follows the road in the direction that the detector is measuring flow. So this helper-link can be matched to OSM edges which are closest and in the same direction. And then the lane is the one closest to the SUMO-lane. This helper-link was done by hand, so not really scalable.

@vishalmhjn's approach is interesting. Haven't checked the detector mapping script. But I would transform the SUMO network to a polygon shp with the lanes' width and then match loops to these polygons (over or closest). Also, there is need for a fall-back if there are three loops and three lanes, then all loops should be assigned to a lane, and this isn't necessarily their closest lane. I think, what I did once:

1. measure distance for each loop to candidate lanes (within a certain distance threshold)
2. choose the combination that
   • assigns all loops to a separate lane
   • minimizes the sum of all distances

hope that helps.