Strip user's via points from output geometry

[ezheidtmann]

For map matching of a complete GPS trace, we want a pristine geometry based on
official data. This change makes sure that only the first and last points may
be via points; all other points are in the road network.

I am not sure why the code is the way it was -- perhaps because we need those intermediate points for actual routing? I'm also not certain that my changes aren't a bad idea, but it seems to work well for me.

[TheMarex]

@ezheidtmann can you explain what exactly the problem is? You only want points that are on segment endpoints? I can see the problem with linear referencing if new points are inserted, but consider that a driver might do a uturn at each via point (even in the middle of a street segment). Just omitting these points will generate a wrong route geometry.

What might work for you is to filter all the points at the position that are contained in indices array. These are exactly the via points you try to filter here.

[ezheidtmann]

Ah, I think I see. I hadn't considered u-turns. Your suggestion of filtering out points by referencing indices makes sense and should work for me. Closing for now. Thanks very much!

[ezheidtmann]

Stripping points by indices doesn't seem to work. It appears that if a point in the original trace is close enough to a point on the way, the match will reuse the point on the way. Thus if I strip all points listed in indices, I get an incomplete result: in one example, the resulting LineString skipped about a half mile of a curving road.

More background on my use case: I have thousands of GPS traces representing trips on the road network. I want to be able to do statistics about traffic volumes on road segments. Without access to OSM node ids (#514) or way ids, I figured I would be able to do segment identification by start & end coordinates. But the via points screw that up.

So for my use case, this PR is currently my best bet (I can ignore U-turns for now). Re-opening, but I will keep this up to date as I work on it.

[emiltin]

as a work-around, you can encode osm ids in the way names, and then extract them later. if you don't need the name, you discard the usual name and just encode the id, otherwise you can use s schema like "wayname{id}". the downside is that it will increase the space needed for way names.

[TheMarex]

@ezheidtmann ah thanks for the good context. Down the road this will get fixed when we add linear referencing to the match output (e.g. for each point in the geometry you will get a mapping to the way and which edge of the way it belongs to)

I'm going to keep this open until we actually fixed that, but won't merge it because it breaks the API. Of course if someone needs this in the meantime, they can use your branch. 👍

[ezheidtmann]

@TheMarex That linear referencing is exactly what we need! If you can point me in the right direction, I will try to put some time towards it. Where would I start? Thanks!

[Fabian190]

@emiltin Hi, I like your idea to replace the street names with the OSM ID's. My question is now where exactly I have to to this because i can't find the correct place. My search for this was mainly in the extractor.cpp file. Would be great if you can give me assist.

Thanks!

[emiltin]

you would do that in the lua profile. check the bicycle.lua file which does something similar to store the way type inside the name:

https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/bicycle.lua#L225

[Fabian190]

@emiltin Hey, thanks very much I found a solution for me. For everyone else add these lines like in the attachment.

Now I got one more question, is there an easy way to change the paramenter "route_name" that this don't only show the popular names but any street names where I drive?

[emiltin]

can't you just look at the instructions for the way names?

[Fabian190]

Hey, that's true and I got what I need. So thanks very much for the support.

[TheMarex]

Closing here because it will be superseded by https://github.com/Project-OSRM/osrm-backend/tree/feature/traffic_data which adds arbitrary identifiers to edges and returns them in the match response.