> 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 _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
