It’s one of those bus routes where the some of the bus stops are reached on little spurs (where the bus goes to the stop then doubles back on itself).
In this case, there are three of those.
Whoever what is particularly baffling me is that Relatify doesn’t like two of the spurs:
I can’t figure out what I’m doing wrong!
All the stops are present in the relation in the correct order,
and I am pretty sure all the ways are present in the correct order too.
I wonder if Relatify thinks that the Limavady and Coleraine platform nodes are too far from the way the bus notionally drives on (whereas the Airport platform is right beside the way).
Here your PTv2 route enters a oneway road in the wrong direction.
OSM Inspcetor does not recongnize/test that
Relatify knows about this
PTNA is not configured for that area (Irland at all) but would detect that problem “PTv2 route: using oneway way in wrong direction: … way-ID” among other errors
I’m currently away from my dev environment, I’ll be back Septermber 12 and could configure that area then.
Mmh, JOSM is fine with that but Relatify does not consider that appendix - I don’t know why.
PTNA would complain only about the “barrier=gate” and “barrier=lift_gate” on that stretch. Implied “access=no” applies for both, so “psv=yes” or “bus=yes” or … is missing.
BTW: highway=busway is not rendered on Carto, so I was a bit confused looking at this map style.
Does the bus travel over that way in both directions? If so I’d say it should be included twice, as it is effectively no different to ways 1 and 2.
But if way 3 is (for example) a loop around the inside of a bus station, so the bus goes around the loop rather than reversing direction, it should only be included once.
Yeah, I’d agree with you, and that’s the way I’d been doing it.
Although in first scenario, it’s usually one of those things where the notional ‘way’ is an abstraction of what is in reality is a big area of concrete. In reality, busses turn into the bus station, make their way across the concrete, and pull into a particular marked ‘bay’ (or ‘stand’), passengers get on and off, and then the bus reverses out of the bay, and back out over the concrete.
There’s not really any way you can capture that amount of detail on OSM, nor would really serve that much purpose to do so, even if you could, I don’t think. (As the exact bays used by busses tend to vary day to day, depending what else is going on.)
I agree there is no point adding arbitrary ways to that kind of big concrete apron that buses can cross freely. I think there is nothing wrong with saying that a bus reaches the end of a way and then turns around (in some way that does not need to be defined) and follows the same way in reverse.
Is your concern at this point specifically about the Relatify warnings at Limavady? If there is no apparent “real world” impact beyond some warnings from a QA tool, there may be no point spending more time on this. I notice there is an open bug that looks like it might be related to this (although there is not much detail so hard to be sure):
I believe the developer is currently working on rewriting the entire OpenStreetMap platform so it may be a while before this is fixed…
Well, now OSM Inspector says the relation 17989741 is invalid too
Apparently the ways are incorrectly ordered. But it won’t tell me where.
I doubt this is something I can fix in iD editor, because it was probably the iD editor that disordered them in the first place!
Looking at the final way of the Limavady bus station spur, I thought based on previous posts you were going to include it twice, as the bus traverses that way in both directions. But I only see it once, which I think would break the continuity. That seems to be what OSM inspector is complaining about here?
OK, OSM Inspector definitely wants the tagging of spurs to go ‘3-2-1-1-2-3’, not ‘3-2-1-2-3’.
Whereas Relatify doesn’t like them either way!
I’m kind of at a loss here, because I don’t want to fill up OSM with broken relations, but the validation tools can’t agree how to tag a relation, so how am I supposed to decide?
I’ve looked at the relation and OSMI can handle the other dead ends as well as that dead end of this route just fine, all with the same structure. In fact, this method of adding the same way twice in a row seems to be the canonical solution (in that many other routes don’t throw an error in OSMI either). At that point, I wouldn’t bother fixing for a tool which may or may not be entirely correct in that situation.
OSM Relatify | OpenStreetMap public transport made easy
Thank you!
