New public transport analysis #1254
Conversation
- the order of the stops - the side of the street
when the bus passes several times on the same street, the order of the projection on these segments are random. offset the linestring before the projection to split the multiple passages in opposite direction
There are a lot of false positives on the first and last stops. Let's remove them from the analysis.
only make sens for street served transport
Maybe just include completely the roundabout, so it avoid false positive.
Access drive side like this https://github.com/osm-fr/osmose-backend/blob/c6c0e8a4598495c3b21c308081dbda92be0d1717/analysers/analyser_osmosis_roundabout_reverse.py#L64 |
|
Thanks for the drive side, I will investigate that 👍
It won't be a linestring anymore if we add a closed way in the middle of it |
|
Could you use uppercase for all SQL key word, please ? |
nlehuby
force-pushed
the
route_geom
branch
3 times, most recently
from
975555f to
9913d9d
Compare
|
I think it's ready 🚀 |
|
Look good. Thank you. Not deployed yet. |
|
Deployed yesterday. But cause lot of trouble. Take too many time on may countries.. up to timeout. Lot of exceptions: https://buildbot.osmose.openstreetmap.fr/#/failing_builds https://buildbot.osmose.openstreetmap.fr/#/builders/195/builds/262/steps/1/logs/stdio |
|
Fixed with this change 5e48988 |
|
I think, we have a false-positive here: https://ptna.openstreetmap.de/relation.php?id=9832010 Here, “stop_position” of stop 11 must be ignored for the bus being on the way to stops 9 and 10, but must be considered afterwards. Ignore stop_position where the platform is on the "wrong" side, even if it is a stop_position of this route? |
|
same here: https://ptna.openstreetmap.de/relation.php?id=9832269 and this has been reported |
|
see #1262 : the analysis about the stop order may return mainly false positives for now as the sql request has been changed. |
new public transport analysis that checks
It mostly works, but with some rough angles ... help welcomed to fine tune ;)
First, it computes the shape of each route as a linestring when possible :
it takes the ways in the relation in their order and try to make a linestring with it.
The only magic is with the un-cut roundabout : as they are closed way and don't fit in the linestring, it skips them (which is not great, see below).
For the order of the stops analysis:
Each platform is projected on the route geom (to create a kind of OSM
stop_position). Then we have an error if the order of the platform in the route relation is not the same as the order of the computed stop_position on the route linestring.Mostly tested on buses.
For the side of street analysis (only for street served transport):
It makes a buffer on the right side of the linestring geom (because as we drive on the right, the bus stop are always on the right side of the road)
Then we have an error if the platform is not inside the buffer.
I've spotted two types of false positives:
The edges of the route relation: this seems quite frequent to have the start of the linestring not fully aligned with the stop.
I've chosen to ignore the first and last stop from the analysis because I don't know how to handle this in a better way. Ideas welcomed ;)
The stops on un-cut roundabout: as I simplify the roundabout when they are closed way, if there is a stop on the roundabout, it is very likely to not fit in the computed buffer:
I guess the solution here would be to cut the roundabout when making the route linestring, but I didn't manage to dot it. Help welcomed ;)
EDIT: I finally managed to cut the roundabout 🎉 no more false positives here!
It needs to be reversed in countries that drives on the other side (take a left buffer if the bus stops are on the left side of the street). I guess we already have this kind of info as country config in Osmose, but I didn't find out how to do it : help needed here too !
EDIT: done ✔️