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