[OSM-dev] JOSM plugin public transport update (Google Summer of Code program)
roland.olbricht at gmx.de
Fri Mar 14 21:40:20 UTC 2014
> Where can I find description of tagging scheme that the project
> should support? I can read: "The JOSM plugin
> public transport is out of sync with the public transport scheme from
> the wiki.". Can I assume that
> 2 is the documentation of the new tagging scheme? Or maybe it is
> nsport&oldid=930877 ?
In general, the current version of
is the right location. An often referred-to page is
which in turn refers to
for features that aren't explicitly changed.
These altogether is quite a vast amount of specifications and boils down to
the following elements
- For bus stops, the sign (or waiting position) off the road should be tagged
with both "highway=bus_stop" and "public_transport=platform". In addition, for
a stop a node in the way the bus uses as street can be tagged as
"public_transport=stop_position". By contrast, when reading exisiting data,
one should accept any node tagged with one or more of the before mentioned
tags should be treated as platform if it is off the road or stop position if
it is in the street.
- For all kinds of railways, from tram to long distance trains, the platforms
are preferrably tagged as way with "public_transport=platform". They may
appear as closed way representing the platform's area or open ways
representing the platform edge. Stop positions also may optionally exist.
- Bus services are represented as relations containing both the ordered
sequence of served stops and the used streets als members. This means there
should be one relation per direction and significant variant. Platforms should
have the role stop, ways of the itinerary should have the roles backward or
forward, depending on whether the vehicle passes the way with or against the
direction of the way.
Automatic conversion should under no circumstances be done without informing
the editing users, and preferrably not at all if the editing user denies.
Please remenber that the editing user might be prompted later by mail for his
changes from other mappers, so she or he should be aware what has changed.
> "Although bus lines follow most of the time the most direct way, the
> mapper has still to collect all these segments by hand. This is a
> really tedious job. A routing engine could suggest a route after the
> user has clicked starting and ending point. A sufficiently fast
> textbook implementation of an A* algorithm is present, it needs to be
> configured to the types of roads suitable for buses."
> I think that a bit different tool based on this idea would solve far
> wider problem. Linear features like highway=*, waterways and railways
> often suffer from fragmentation (and probably also other linear
> features). It makes many sort of edits overly complicated. Problem is
> limited not only to adding bus lines. Any edit that involves editing
> longer part of segmented linear feature triggers this problem. For
> example I encountered it during adding lit and surface info and it
> discouraged me from this type of edits. It is easy to imagine that
> the same will happen with many other edits.
You could in JOSM select a feature like a street by the street's name (select
all segments of that street). This would cover some of the cases. Having a
tool that does the selection part according to a direct route would also be a
help but might be more demanding - the acceptable features for waterways or
railways differ from those for streets, and even for streets the subsets that
fits for buses differs significantly from the subset for cyclists. So the
feature will require some clever user interface to handle this explanation
> Moreover only starting and ending point are not enough to generate
> fully correct bus route. It will work only for specific routing of
> bus lines that may be rare in some countries (for example in Poland).
Actually, most bus lines would be described by some few stops, usually
starting point, multiple stops in the city center, terminal and probably three
or four stops in-between. At least for Torun the patterns has also hold up. Of
course, stricly choosing only two points would be too few.
> Additionally JOSM has significant lag while operating at city-sized
> datasets (around 150MB) and changing this would be hard and
> complicated enough as separate project.
I agreee that this would be by far out of scope for this project. I developed
a concecpt called sparse editing for these cases where I would exclude
building data or dwonload only the road grid and do only specific kinds of
edits that cannot lead to consistency problems. That mitigates the size
problem, but has enough pitfalls to not promote this for the sanely impatient
> This approach may make coding more complicated but it would solve far
> more general problem.
Having another selection aid for JOSM would indeed help even more. I you want
then you could also focus the project to this challenge and leave aside the
> "plugin should no longer break well-tagged existing structures"
> Should plugin fully support outdated tagging schemes? Or is it enough
> that updated plugin will not break it?
I would suggest to follow the policy given above: Deal with all taggings that
appear sometimes to often in the database. The tagging may be updated, but the
updated version must represent the same meaning and the user should be told
Having a tool that supports each and every old or obscure tagging scheme would
be by far too much work.
> Where can I find bug tracker for this tool?
> I found
> ort/ and its git mirror but I have still to find the bug tracker.
The tool _is_ the most recent bugtracker. However, there has not gone much
work into in the last years.
More information about the dev