On 2016-06-20 16:18, Paul Johnson wrote:
On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <[email protected]>
wrote:
On 2016-06-20 02:07, Roland Olbricht wrote:
There had been a group that was very vocal for making a textbook
example of design by committee, and the result is now known as
"approved public transport scheme". They did not ask for input
from experienced mappers or developers. I decided to consider it
a waste of time and stopped developing.
I wasn't around at the time, so I can't speak to how it happened,
but the result seems to be a partial implementation of Transmodel,
which distinguishes a _lot_ of different things (and the complex
relationships between them) in excruciating detail because the real
world is, in fact, that complicated.
If one is putting data in by hand, it certainly seems unwieldy. It
took me over a week to do just a few rail routes in my area, and I'm
still not completely sure I got them right. I can't imagine trying
to do the hundreds of bus routes too.
I really wonder how TriMet ultimately accomplished this, since that
would seem like a decent-ish starting point since that system is in
charge of a fairly multimodal system with above and below ground
stations, split-level stations, and transit centers of almost every
description.
Same here and many other cities I've looked, so I didn't think it was
that big of a deal.
One thing that breaks things badly for me in the Tulsa area is the
vast overwhelming majority of stops in the Tulsa Transit (and
presumably other transit systems in the region) GTFS have...literally
zero indication on the ground, there's no way to tell if there is an
actual bus stop (which is typically just a signpost with a bus stop
sign on it), and if it is, whether or not that's verifiable because
the sign's gone missing.
*facepalm*
I have plenty of complaints about the transit agencies where I live, but
at least they manage to post signs properly and provide proper
maps/schedules. Their GTFS data isn't as accurate as I'd hoped, but
it's obvious they're _trying_ to get it right.
Also, like it or not, Google Maps (and hence GTFS) has set a bar for
what users expect from online maps. I'd certainly like OSM to be
better, of course, but the current situation is that OSM is
generally far, far worse.
It doesn't help that the only implementations of GTFS that actually
are anywhere near complete are basically the reference implementations
Google did in cooperation with TriMet and Tillamook County Transit,
and adjacent systems that asked TriMet how they did that (like Clark
County Transit, aka C-Tran).
Really? I've looked at a couple dozen feeds for major US and European
cities, and they seem to be reasonably complete and accurate. Then
again, all of the ones I've looked at so far are ones that offer rail
services, and the nature of rail implies a high enough level of funding
that one can probably take things like a decent GTFS feed for granted.
A small, bus-only agency can run on a shoestring budget where such
things may be seen as "unnecessary" or "too much effort".
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?
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.
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.
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.
- 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.
One of the challenges I've run into is whether to name every part of a
stop area; if I do, platform or stop position names often get rendered
_instead of_ the station name, but if I don't, it's really hard to
maintain all the relations because all the elements of a given type look
the same, plus navigators can't direct pedestrians to the right
platforms.
S
--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
_______________________________________________
Talk-transit mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-transit
