On Tue, Jun 21, 2016 at 2:02 PM, Stephen Sprunk <step...@sprunk.org> wrote:
> On 2016-06-21 00:27, Paul Johnson wrote:
>
>> On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <step...@sprunk.org>
>> wrote:
>>
>>> On 2016-06-20 16:18, Paul Johnson wrote:
>>> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk
>>> <step...@sprunk.org>
>>> 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. ... 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.
>>
>
> Ah, I never thought to try that since transit here is reliable enough to
> set your watch by, so a static schedule is all I've ever needed.
>
> I found a couple transit-specific apps, but they refuse to work until I'm
> within some minimum distance of a stop. In particular, they won't tell me
> when I need to be _at_ the nearest P&R station until after I'm _already
> there_, and with off-peak headways of up to an hour, I don't want to arrive
> too early. Google Maps will tell me when the next few trains are leaving
> (and how long it'll take to drive there in current traffic) so I know
> _when_ to leave home.
RideSystems (and yes, I'm calling them out on this, since I reported the
problem a year ago via Google Play) won't even get past the "select your
transit system" thing. Plus it's basically one of those lame "browser in
an app" deals, and it *still* doesn't work all that great in Chrome.
Especially versus holding the paper timetable in hand...seriously MTTA only
charges 25ยข for the quarterly timetable, but they could probably charge $25
and they'd still sell just as fast simply because their online route
planner and the RideSystems app is so horrible.
Though having the timetable and being able to text a stop-ID to a shortcode
and wait a few seconds for which bus will show up first at the stop you
already know is convenient is better than their old trip planner by a lot:
Tear out page 4 of the timetable, fill out the form printed on it, *then
mail it to the transit system's office and wait for them to mail you the
answer*. No joke. Also, that option's still available as of the Winter
2016 timetable I have in my glovebox, for situations where my friends miss
their bus and call me up so I can basically track down their route looking
for them if they're not sure where they are.
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
>>
>
> Here, at stations where passengers either enter the platform from both
> ends or from the middle, trains stop so the center of the train is in the
> center of the platform, which means the cab's position varies with the
> train's length. At stations where passengers enter the platform only from
> one end, trains stop so the front or rear (depending on direction) of the
> train is at that end of the platform.
>
> For the former, it makes sense to put the stop_position in the middle.
> For the latter, perhaps I should put it at/near the relevant end instead?
> If it matters at all.
>
I think Portland did this because everyone's device will pass through that
point if they're remaining on the train, since regardless of whether it's a
1 car or 2 car MAX train, or a vintage streetcar (back when the Historical
Society still had timetable slots), you'd touch that point on departure
regardless. I can't test this hypothesis since I'm not aware of any app
that'll provide realtime navigation on that system anymore, and I'm like,
2000km away now.
> 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. ...
>>> 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).
>>
>
> Exactly. While a regular rider of the route can figure it out, or may
> pick up a map/schedule for offline planning, the casual or tourist rider
> will be baffled and is likely to end up in the wrong place. Most drivers
> I've talked to are very helpful, but there's only so much they can do if
> you get on the wrong bus aside from leave you on the side of the road
> praying for the right bus to come along before you get heatstroke,
> frostbite, etc. One simple mistake can easily cost you an extra hour or
> two of travel time.
Fortunately, if a driver is aware of what's going on over his radio and
familiar with the headways on the other buses that are on or cross his
route, they can usually radio ahead to hold the correct bus to wait a few
minutes for you to make a transfer. Exception being nightline drivers on
the last run of the night are dead set on dragging their feet on this
because they just want to go home after driving since 4 in the afternoon.
> - 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).
>>
>
> That's how nearly all bus stops here are named, aside from those part of
> complex bus/rail stations that tend to have multiple bays/platforms. I
> don't see the problem with that.
>
> It's when you get to those complex stations that you run into questions of
> naming the individual pieces vs the station as a whole, but it still
> doesn't seem that difficult until you get to rare cases, e.g. multiple
> stations that have grown together into one confusing, amorphous blob.
The transit renderer doesn't seem to like to consider the same stop running
different directions through the same intersection unless you bang the name
up. A stop might be 41st and Yale in one direction, and Yale and 41st
going the other way through the intersection, for example.
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
