Re: [Talk-transit] GTFS, tools and pt tags generally

[Stephen Sprunk]

On 2016-06-21 11:40, Roland Olbricht wrote:
OTOH, this doesn't seem like a huge problem if we're importing the 
data

from elsewhere using automated tools and only tweaking by hand where
it's wrong--and ideally, there should be some sort of feedback 
mechanism

to get the source corrected so even that's a short-term problem.


Well, that's explicitly deprecated in OSM. Please look in the wiki
about mechanical edits.

If you have useful and free data then the better approach is to mix
them up with OSM data outside OSM and give the OSM mappers a tool such
that each mapper can pick what he/she deems useful in OSM.


I'm sorry if I was unclear.  I didn't mean that one person should just 
blindly dump every GTFS feed into OSM and leave it to others to clean 
up.  I was thinking of something that an individual mapper could use to 
import the feed(s) in their particular area and resolve conflicts or 
errors before uploading, e.g. in JOSM.


One of my concerns is that if multiple people are working in the same 
area with the same source data then they should respect each others' 
corrections of that data.  Also, if there are multiple tools available, 
e.g. GO-Sync and a JOSM plugin, they translate things in exactly the 
same way so they're not constantly messing up each others' work.



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.


I think this is where local differences matter. In large parts of
Europe, the transit agencies themselves have already good information,
OSM is more or less on par with that, and Google lags significantly
behind.


That seems odd; the GTFS feed should just be an export of the data that 
the agency is using for their own tools; it shouldn't be worse somehow.  
I can see how a group of dedicated OSM mappers could improve the 
geolocation or station amenities, but we could still free them up from 
having to maintain routes/routemasters and such.


Perhaps it's different in Rightpondia, but here in Leftpondia, it's 
common to see major (sometimes network-wide) changes to routes and 
schedules every 3-6 months.  The thought of having to create hundreds of 
routes and thousands of stops from scratch even once is daunting; that a 
large chunk of my work would get wiped away before I even finished the 
first pass makes it pointless.  OTOH, if tools could do most of the work 
and then point me to a handful of places where they couldn't figure out 
the right action, it could be done in a few minutes to maybe a few 
hours, depending on the scope of a given change.


And: how to tell apart services that run a few times per day from 
those

that have a headway of a few minutes?


That's starting down a slippery slope to including full schedule data.


Once again, please note that this is a huge difference in local 
culture.

...
If you would like to improve relevance of OSM, discriminating between
these three levels of service would be a prime concern.


Hmm.  It still seems a slippery slope to me, but if folks in areas where 
such a distinction exists find it relevant, I wouldn't stand in their 
way.


This is in contrast to a number of service that run once a day on 
schooldays.

...
And the right solution for this is not to delete these services from
OSM but to mark them as low-frequency service.


If someone were mapping school bus routes in the US (AFAIK, nobody is), 
I'd probably have the same reaction.  Or I might suggest creating an 
entirely new mode tag for them so there's no chance of being confused 
with non-school bus routes; it seems a more significant distinction than 
light_rail vs tram, for instance.



- Where to start/end routing of vehicles?


Sorry for the misunderstanding. I'm talking about getting a vehicle
from stop to stop. While the overall level of detail is often good
enough for routing, this doesn't hold always. To find and resolve the
mapping issues it makes sense to check whether you can route from stop
to stop. If not, this is always a strong hint that there are mapping
issues.

I do notice as a benefit from this discussion that not all transit
agencies (Tulsa, Portland) care whether their routes can be lawfully
driven in reality. That's different here in, at least in Western
Europe, maybe all Europe.


Lawfully?  Non-lethally would be a good start!  Routes from many 
agencies here, if taken literally, require you to go through buildings, 
off bridges to a crossing road without using any ramps, across rivers 
without a ferry, etc.  Bus stops can be in the middle of traffic lanes 
or hundreds of meters from the road.  Such things are why it's critical 
to _not_ undo someone else's manual corrections when importing 
updates--yet somehow _not_ preserve old imported data that _wasn't_ 
corrected.



I would like to see a set of rules that answer questions like:
- Does a "name:en" tag on the pole 

Re: [Talk-transit] GTFS, tools and pt tags generally

[Stephen Sprunk]

On 2016-06-21 15:12, Paul Johnson wrote:

On Tue, Jun 21, 2016 at 2:02 PM, Stephen Sprunk 
wrote:

I found a couple transit-specific apps, but they refuse to work until
I'm within some minimum distance of a stop.  ...


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.


I was going to say "at least they tried", but after a year, I agree.


Plus it's basically one of those
lame "browser in an app" deals, and it _still_ doesn't work all that
great in Chrome.


I don't get why so many folks waste money on that, other than to tell 
clueless execs that "we have an app" when all they really have is the 
same old website with a app-like shortcut.


Building a custom app probably isn't cheap, but there _must_ be decent 
off-the-shelf apps out there that can work from a standard GTFS feed.  
Or they could just make their regular web site work well on mobile 
devices too; few riders would care it's not an "app".



... 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.


*boggle*

Here, they publish a 24x7 customer service phone number that works for 
both trip planning and any other questions/complaints from riders.  
Their web/app trip planner isn't bad, but it doesn't seem to be any 
better than Google Maps, which indicates it's using the exact same data 
that's in the GTFS feed (maybe the feed itself).



[Cross-streets is] 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.


I'm not sure what you're referring to; the only bus stops I see in all 
of Tulsa are the ones at or near Denver Avenue Station, and only one of 
DAS's bays seems to be labeled.


Here, there'd be four distinct stops named something like "41st NB @ 
Yale", "41st SB @ Yale", "Yale EB @ 41st" and "Yale WB @ 41st".  The 
only rendering challenge I see is if they're so close at low zoom that 
the names would overlap, but since they're all pretty much the same name 
anyway, it doesn't matter in practice.



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
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit