[OSM-dev] JOSM plugin public transport update (Google Summer of Code program)

[Roland Olbricht]

> 1.
> 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
> http://wiki.openstreetmap.org/w/index.php?title=Public_transport&oldid=94550
> 2 is the documentation of the new tagging scheme? Or maybe it is
> http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Tra
> nsport&oldid=930877 ?

In general, the current version of
http://wiki.openstreetmap.org/w/index.php?title=Public_transport
is the right location. An often referred-to page is
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
which in turn refers to
http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema
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.

> 2.
> "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 
challenge.

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

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

> 3.
> "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 
about.

Having a tool that supports each and every old or obscure tagging scheme would 
be by far too much work.

> 4.
> Where can I find bug tracker for this tool?
> 
> I found
> http://svn.openstreetmap.org/applications/editors/josm/plugins/public_transp
> 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.

Best regards,

Roland