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

Stephen Sprunk stephen at sprunk.org
Wed Jun 22 22:56:55 UTC 2016


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 override a "name" tag on the
> stop_position, or vice versa? What about a "name:en" tag on a
> stop_position versus "name" on a platform?

It seems the current behavior is to render the name for each element 
independently, except that some (not sure it's deterministic) seem to 
get dropped entirely if they'd overlap.

Within each element, which name to render (if any) should be 
straightforward.

> - Should "Hbf" be expanded to "Hauptbahnhof", or the suffix "(Westf)"
> to "(Westfalen)"?

A renderer shouldn't have to know such things, and when people try to 
add such clever tricks, it usually ends up making things worse, e.g. a 
rule to correctly change "N Foo Ave" to "North Foo Avenue" also 
incorrectly changes "Ave N" to "Avenue North".

> - Have the tracks in the station "Vaugirard" this name or the name
> "Montparnasse"?

Or the platforms or stop positions.  I've been trying to figure out what 
to do on that front myself; so far I've simply left everything but the 
station itself unnamed because otherwise the current rendering output is 
unusable except at the highest zoom levels.  And that's for far simpler 
cases than what you describe, e.g. a station named "Akard" with a pair 
of platforms named (as signed) "North" and "South"!

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



More information about the Talk-transit mailing list