Look up OSM IDs of matched positions

[aggour211]

We had an issue understanding what are the data points that the Barefoot server returns. It seems that the response from the server contains many points on a given road. As you can see on the following screenshot: But there seem that OpenStreetMap does not have as many points (nodes) as you return (see this road for example) on the same road. Where do these intermediate points come from, and how do we filter out these "extra" nodes, which are not from OpenStreetMap apparently ? Here are my input JSON file and output JSON response: input.json

output.json

Thank you, Issam

[smattheis]

What do you mean by extra nodes? - The red bullets are the exact position matches on the road for each position sample. (Note that if you defined matcher.distance to some value greater than zero, it omits some of your position samples.)

Further, you're right that OSM roads are split into road segments. This is because otherwise the map is not routable. To determine the road of a particular matched position, you can simply use the slimjson or debug output format of the matcher. These formats contain the road gid used by barefoot and which indicates road segments and not OSM roads. To look up OSM roads, you can simply use the database as e.g. a GID 504230 maps to 322047896:

sudo docker exec <container> psql -h localhost -U osmuser -d <database> -c "select * from bfmap_ways where gid=504230;"
  gid   |  osm_id   | class_id |   source   |   target   | length | reverse | maxspeed_forward | maxspeed_backward | priority |                                            geom                                            
--------+-----------+----------+------------+------------+--------+---------+------------------+-------------------+----------+--------------------------------------------------------------------------------------------
 504230 | 322047896 |      112 | 2014228966 | 1829190868 |      1 |      -1 |                  |                   |      2.5 | 0102000020E610000002000000430070ECD95303401114E40C6A6C4840457AF601ED5303405CE102756F6C4840
(1 row)

The reverse look up is similar:

sudo docker exec <container> psql -h localhost -U osmuser -d <database> -c "select * from bfmap_ways where osm_id=322047896;"
  gid   |  osm_id   | class_id |   source   |   target   | length | reverse | maxspeed_forward | maxspeed_backward | priority |                                                                                                            geom                                                                                                            
--------+-----------+----------+------------+------------+--------+---------+------------------+-------------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 504230 | 322047896 |      112 | 2014228966 | 1829190868 |      1 |      -1 |                  |                   |      2.5 | 0102000020E610000002000000430070ECD95303401114E40C6A6C4840457AF601ED5303405CE102756F6C4840
 504231 | 322047896 |      112 | 1829190868 |  267104800 |      1 |      -1 |                  |                   |      2.5 | 0102000020E610000002000000457AF601ED5303405CE102756F6C4840A9674128EF530340C5CD041E736C4840
 504232 | 322047896 |      112 |  267104800 |  247277351 |      1 |      -1 |                  |                   |      2.5 | 0102000020E610000006000000A9674128EF530340C5CD041E736C48401D6C5622F5530340772A85E5746C4840A2AC29DA66540340A7DDF98F966C48407558E1968F5403408E7E8F55A56C484055F080577054034022B7706AB16C48402FE5D76A6A5403401B92A4B5B36C4840
(3 rows)

Given the OSM ID, it's also straight forward to get OSM road information:

sudo docker exec <container> psql -h localhost -U osmuser -d <database> -c "select * from ways where id=322047896;"
    id     | version | user_id |       tstamp        | changeset_id |                                                   tags                                                   |                                         nodes                                         
-----------+---------+---------+---------------------+--------------+----------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------
 322047896 |       1 |  210173 | 2015-01-14 18:47:59 |     28145242 | "name"=>"Rue du Commandant L'Herminier", "oneway"=>"yes", "highway"=>"residential", "surface"=>"asphalt" | {2014228966,1829190868,267104800,2014228972,247277759,247277760,3287262127,247277351}
(1 row)

Note: The debug format contains pretty detailed information and also all the roads that have been found for matched trip.

All the same can be done programmatically where you could implement your own output format. For instance, modify the debug output format as you need it.

[inconnu26]

Ok I understood. But @aggour211 meant to say: How to differentiate data points of OpenStreetMap, from the data points that are linked to "position matches on the road for each position sample" ? I think I found out how. OpenStreetMap positions points have less significant figures like "48.8408341, 2.4175855". Whereas "position matches on the road for each position sample" are with more significant figures, like "2.4176617057280243,48.842320370753406". That is he way I filtered them out, and it worked fine for us. Is that correct ? Thank you !

[smattheis]

You shouldn't got that way because the precision of position data is not reliable to distinguish this kind of thing. Instead, you should use the right output format, which depends on what you need: 1.) Do you do online (real-time stream) or offline (batch) map-matching? 2.) Do you need information about position samples or also paths between samples? 3.) With regard to samples, do you need context infos (link ids) or geometry information (coordinates) of matched positions/paths?

[inconnu26]

1. Offline map-matching
2. No we only need the data from the map path, no intermediate "position matches on the road for each position sample". Having data from the path itself would be very interesting too (like: "name"=>"Rue du Commandant L'Herminier", "oneway"=>"yes", "highway"=>"residential", "surface"=>"asphalt")
3. We need the map data coordinates of the path that is best matching the GPS data. So nothing more than the coordinates found on the OpenStreetMap database. But, as we said in answer "2)", more data about each path, would be a plus.

[inconnu26]

So basically, we would need a better way to filter out the unneeded points than using the non-perfect "have less significant figures" filtering. Could you help us ? Maybe somewhere in the code we could ask the Matcher server to return only the points of the map and not the point that correspond to the closest GPS point on the matched path...

[smattheis]

Sorry for getting back to you so late. I will have a look at it during next days. (Also with regard to the u-turn issue, I have a patch and will push it with that.)

[inconnu26]

Hi, Thank you very much ! I would be glad to have a patch for this ! It would help us a lot !!