On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <[email protected]> wrote:
> On 2016-06-20 16:18, Paul Johnson wrote: > >> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <[email protected]> >> wrote: >> >>> >>> The situation with GTFS data itself is so bad that Google stopped >> offering Navigation for the transit mode in it's own Maps service. >> > > It's still available where I live and several other major cities I > checked, so perhaps they just disabled it in your area because they > recognized the GTFS data there was so bad? > I mean the realtime, stop-by-stop navigation that was formerly offered. Even in areas with really good GTFS feeds, this functionality is Just Gone. Closest you can get now amounts to basically a static listout of your trip similar to the paddle used by transit drivers in to familiarize themselves with the route and schedule; it doesn't follow you in realtime or take into account when your trip's fallen off schedule and won't make a transfer now. Nor will it warn you your stop is coming up. I remember this abruptly going away with the last version that had it was Google Navigation 6.9... > One example is the dissent on whether the bus stop should be a >>>> node on the vehicle's way or a node where the passengers wait. You >>>> will find all solutions implemented, because each local community >>>> decided different. The "approved scheme" will allow any variant. >>>> >>> >>> ... >>> >> >> I'm a proponent of it being the location where passengers wait for bus >> service, and the center of the position the train stops for rail >> halts, for what it's worth. >> > > Unfortunately, that could create problems if navigation tools think that a > person has to walk to the center of the platform to actually board the > train, whereas trains often run the full length of the platform but are > often shorter (or even longer!) than the platform. > > Worse, some trains only allow boarding for mobility impaired persons at > certain points along the platform, and they may not be able to make it from > the center to that location within the dwell time. > > Worse still, a short train may not even be _present_ at the center of the > platform if it's short and stops at one end or the other. While > improbable, in theory that could lead a vision-impaired person to walk off > the platform and fall onto the tracks. > Most stations I've seen have a canonical tactile map and seeing impaired users are not putting total faith in either the official tactile map nor any electronic aid they're using. Mostly because people and furniture move, maintenance closes areas, pavement buckles, etc. > I'm not sure what the solution is, though, so I've been putting the stop > positions at the center of the platform until someone tells me better. > FWIW, that seems to be what folks in other cities have done--if they mapped > any stop positions at all. > Portland tends to put the stop position where the lead cab of the lead car will line up. However, Portland hits me as a little odd (in terms of west coast light rail systems) in that there > Another example are route relations. While there are wild >>>> constructions called route_master and network which are basically >>>> collection relations, the problem that bothers most people in >>>> practice has never been tackled: We would like to see per way segment >>>> only one or very few relations and need a construction to assemble >>>> itineraries from that. That would greatly reduce maintenance. >>>> >>> >>> I'll admit I was a bit annoyed at having to duplicate way data for >>> several routes where some trips run A-B-C-D, some A-B-C and some >>> B-C-D; it would have been handy to create segments A-B, B-C and C-D, >>> and then just include the right ones in each route. But then I >>> realized my real complaint was that I had to do this _at all_ when >>> there's a GTFS feed that has _all_ of that information and could >>> easily be used to create/update all the relations. If it's >>> automated, only developers should have to care how complicated or >>> repetitive it is; the important thing is that individual mappers >>> don't, at least in the general case. >>> >> >> Hadn't learned of Route Master before, but this frustration with some >> routes not going full length or having optional loops or changed route >> based on time of day or whether or not it's snowing without changing >> the route name or number actually hit me as one of those, "are you >> actually kidding me?" kind of moments with Tulsa Transit. There's one >> route that has something like six or eight different relations because >> of this. >> > > It's always baffled me that so many agencies are willing to give the same > designation to different routes just because they share several stops. > IMHO, it'd be better to give each variant a suffix so they can be easily > identified (e.g. route 1A vs route 1B, rather than route 1 to Wherever and > route 1 to Elsewhere; references without a suffix could still refer to the > common section. Worse, what appears to be the same route can often be > different variants depending on the time of day. My local agency has > several routes where route A stops at certain places in the off-hours but > skips those stops during peak hours when route B serves those stops > instead--and route B doesn't go to all the _other_ places that route A does. > > Part of the reason we _need_ transit navigation apps (and reliable > route/schedule data to feed into them) is to hide this sort of complexity > from users. Or obviate it. Sight unseen, just trying to make sense of the situation based on just a map and what stops are handy, there's no way I'd figure this out for Tulsa's 101 Suburban Acres route. Every other trip alternates which way the route goes through the eponymous neighborhood, so depending on which half hour it is, you might need to walk to one end of the neighborhood or the other to catch the bus. Or wait up to an hour instead. And then some trips make side trips to a clinic (during it's business hours) and some trips make an additional side trip to a alzheimer's treatment community (based on some arbitrary criteria, possibly when the patients are allowed to come and go). > - How to obtain a name of a station? >>>> >>> >>> How is this complicated? >>> >> >> A lot of cities name stops without signposting the name, often in the >> form of "The Street The Route Is On at The Cross Street We're Stopping >> At", such as "South Memorial Drive at East 56th Street" or some >> similar pattern. >> > > Oh, sorry. I was assuming a decent GTFS feed, where every stop should > have an official name, even if it's only cross-streets (typical for bus > stops). I thought the question was where to put that it in OSM and/or > where renderers should look for it. > Yeah, GTFS assumes every stop is named, even though this assumption is outright broken even in GTFS's hometown of Portland beyond just naming the intersection or block number ("6300 Block Southwest Murray Boulevard" as a hypothetical name example of a stop not near a corner).
_______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
