Re: [Talk-transit] Public Transport Line Diagram
Am 25.01.2011 18:30, Wojciech Kulesza: Was wondering if the planned changes to approach in mapping public transport would have an impact on this service: http://78.46.81.38/public_transport.html While it behaves quite nicely for the examples provided there, it works very bad for PT in Poland. Compare this result: http://78.46.81.38/api/sketch-line?network=ZTM+Pozna%C5%84ref=1 http://78.46.81.38/api/sketch-line?network=ZTM+Pozna%C5%84ref=1 with the appropariate relation in osm: http://www.openstreetmap.org/browse/relation/79152 Just compare your relation with the working one :) http://www.openstreetmap.org/browse/relation/361959 On first sight i'm wondering why you are mixing railway=halt and railway=tram_stop? Isn't all of it a tram line? Additionally you are missing from= and to= in your relation. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] JOSM latest takes forward/backward roles for route relations into account
Just a small hint on anyone working with relations using forward/backward roles and willing to do some experimenting: The latest JOSM (starting from revision 3788) includes a nice relation analysis and visualisation for these relations. See this ticket (scroll down for some interesting screenshots): http://josm.openstreetmap.de/ticket/5109 Would be great if you could test this build with your relations and report possible issues. Be aware though that this isn't a tested release so you might encounter weird behaviour, data corruption and all other joys of beta testing. Download the latest JOSm from http://josm.openstreetmap.de Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 14.01.2011 02:16, Tobias Knerr: Dominik Mahrer wrote: One month ago I already posted an RFC on this proposal. In the meantime I got plenty of comments and I have extended/corrected/rewritten nearly the whole proposal. I'm not very happy with the extensive use of relations. Especially nested relations strongly suggest that the level of complexity is beyond what's appropriate for a crowd-sourced project like OSM. The most prominent issue are stop area groups. The necessity of these has already been questioned. I, too, tend to think that determining them algorithmically would ultimately be a better choice. Removing the nested relations for stop area groups would eliminate one of the most complex concepts from the proposal, making it more accessible to mappers. Additionally, I suggest to reconsider the requirement to use stop area relations even in simple cases Many bus stops are very straightforward: They consist of usually two platforms with a common name. This name is usually unique within a range of several kilometres and, if tagged to the platform elements, could therefore be used instead of a relation to identify the components of the stop area. +1 I don't think the stop_area-relation for the vast majority of simple bus, tram or train stops is necessary. öpnvkarte.de and other sites working with the data prove that you can reliably determine nodes belonging to one stop via easy algorithms/preprocessing. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
Am 13.01.2011 21:33, Michał Borsuk: On 13 January 2011 13:59, André Joost andre+jo...@nurfuerspam.de mailto:andre%2bjo...@nurfuerspam.de wrote: Am 13.01.11 13:27, schrieb Richard Fairhurst: Could I have your assurance that the proponents of this proposal will also be providing good-quality patches for the three principal editors (Potlatch, JOSM, Merkaartor), with an easy-to-use interface consistent with the rest of the editor? A preset for josm is already in progress. With what's in the proposal? That's pretty arogant, don't you find? We haven't decided on the final shape yet. I don't see any arrogance here. Have you used JOSM before? I guess you did so you know that presets must be actively downloaded and enabled by the users hidden in the preferences. Somewhere besides the Doctors in Greece, the OpenPisteMap and the Japanese 50 sounds order presets. A preset could help testing the proposal during daily work and in the daily environment to see if it works like it as envisioned. Still I can't see no arrogance anywhere. And btw I like this do-ocratic part of JOSM just like some well intentioned exchange of ideas. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Naptan import stop tagging (was: Proposed changes to oxomoa schema [part 2: stops])
One question on the Naptan import: Did you use any tags from the public_transport therefore? Or are these all highway=bus_stop? Would be a great chance to increase coverage of the more detailed public_transport=platform Claudius Am 29.06.2010 02:07, Shaun McDonald: In the UK as part of the Naptan import we already have decided that bus stops must be marked exactly where they are on the ground and added to the route relation of the bus route. Shaun On 28 Jun 2010, at 19:07, Michał Borsuk wrote: Hi everybody again: This time I'd like to propose a smaller change, but this one may break compatibility with oxomoa - it has been, however, already commonly implemented. *ISSUE RAISED: * map bus stops to their physical location, not a point on the route/street * Present status: If I understand correctly, oxomoa suggests that the bus stop data (name, unique number, etc.) be entered as properties of a point on the route/street. Problems : * Lines often have stops that are quite far apart for each direction * This prohibits proper routing (GPS + walking), * this system is not very intuitive I find. *Proposed change: bus stops to be mapped exactly to where they are, and to be added to relations * Result: * better routing results e.g. one wants to find a correct way to the bus stop, and not to the average point somewhere between two stops of the same name in either direction. * more intuitive system - easier learning curve for new users. Influence on possible future software solutions: minor. May require all the stops on the route to be ordered based on their geographical location, as opposed to their place on the route (the latter is easier). Comments: I have seen this system very often implemented - two bus stops on each side, so my suggestion is just to codify the situation for future editors. Hope this is not too much at once, for more is to follow. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org mailto:Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
Am 29.06.2010 10:22, Michał Borsuk: On 29.06.2010 09:33, Tiziano D'Angelo wrote: +1 On Tue, Jun 29, 2010 at 08:23, Arun Ganesh arun.plane...@gmail.com mailto:arun.plane...@gmail.com wrote: Shouldn't we keep the schema to something that is easily compatible with the Google Transit GTFS format instead of developing something different all together? Doesn't GTFSsuggest one location for one unique stop name, whereas we want each physical location belonging to a name as a separate point? (this does not suggest incompatibility, just an overlay on GTFS) LMB GTFS covers Oxomoa's extended form of tagging a stop area as well: stops.txt contains an optional location_type where the value 1 would represent a public_transport=stop_area: 0 or blank - Stop. A location where passengers board or disembark from a transit vehicle. 1 - Station. A physical structure or area that contains one or more stop. In most cases the stop positions in both directions will have different locations and thus different stop_lat and stop_lon in GTFS as well. So we are already easily compatible. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import stop tagging
I was referring to public_transport=platform + bus=yes public_transport=bus_stop would not work because there are stop positions where trams, buses and sometimes (Karlsruhe comes to my mind) even light_rails stop at the same position (Image: http://www.dvn-berlin.de/i/verein/2009_alex_bus_hpa.jpg ) and these would be tagged as public_transport=platform + bus=yes + tram=yes (+ light_rail=yes) Claudius Am 29.06.2010 11:32, Richard Mann: They're all still highway=bus_stop. I think I'd need some convincing that public_transport=platform was appropriate for bus stops. Public_transport=bus_stop, maybe. Why change? Richard On Tue, Jun 29, 2010 at 9:59 AM, Claudius Henrichsclaudiu...@gmx.de wrote: One question on the Naptan import: Did you use any tags from the public_transport therefore? Or are these all highway=bus_stop? Would be a great chance to increase coverage of the more detailed public_transport=platform Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] OSM Transit platform: call for action
Am 28.06.2010 17:37, Michał Borsuk: On 28 June 2010 14:14, Tiziano D'Angelo tiziano.dang...@gmail.com mailto:tiziano.dang...@gmail.com wrote: Hello everybody! In the past months, as you probably read here, I mapped almost entirely the bus network of Padova, Italy. Abstract: A new standard, better suited but compatible with what has been done is needed. Hi! I have also mapped almost my entire area, and I have found that the option of combining OSM with bus timetables is not presently feasible. There are the following problems: * missing important details. Just like you did, I skipped some strange variants such as special Sunday early morning runs, or collective taxis (because they tend to go wherever the people want). Also, there is at present no provision for implementing the time of bus lines, so at present one could be advised to take a night line at daytime. I think the first step is getting hold if unique station identifiers. You would need to check if something like that exsists for your country or at least transport association. From than on it's quite easy to go forward. See http://wiki.openstreetmap.org/wiki/Naptan * no approved standard. Should the stops be within the line as a point, or as their physical location shows? Should we map a separate relation just for the branch of the line from the split, or for the entire line? What is the point of having two relations for two directions in Europe? IMHO Oxomoa seems way too difficult for beginners, and it's overblown. The overhead needed to maintain the standard is WAY too big. I have calculated that sticking to the standard would cost me 25 to 50% more time, with just marginally better results. The time to understand the standard is also not to be ignored. A new standard, better suited but compatible with what has been done is needed. Just a comment on the complexity of the public transport scheme by Oxomoa: You could get along with a very basic variant already and thus be standard-conform: - Just put all way segments and the stop_positions in a relation with from=... and to=... - Clone the relation in JOSM and reverse the order and switch from=... and to... - put those two relations in a line=bus/tram relation and you're done. Not much more effort. In later expansions you might add the public_transport=platform and stuff The wiki article is indeed very long, but as a starter it can be reduced to the above :) Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
Please find my comment on core lines below. Am 28.06.2010 19:54, Michał Borsuk: -- *ISSUE RAISED: * change to the way more complex lines are mapped, that is the introduction of tags or roles instead of nested collections* Present status: For lines with variants, each variant needs a separate relation Problems: * Nested relations are difficult to impossible to manage in potlatch, * They are difficult to understand * Creating a variant requires the entire route to be duplicated: impossible in potlatch * Extending or rerouting such lines can be hell * High risk of introducing a mess by inexperienced users (I think). I actually think my proposal is more error-resistant. * It's time-consuming! It's easy to duplicate a line once one knows JOSM, but how much time does it take to get JOSM running, from downloading to having results? A lot. *Proposed change: introduction of a core line, that is shared by all variants in all directions, and having the branches or exceptions in one direction tagged appropriately. Core line would have no tags, branch lines would be tagged arbitrarily. * Result: lower consistency of the data entered, but much less time needed to enter and manage lines. The mess can be easily dealt with by server-side software presenting data to users. If one wants a route from one's side branch of a line, one looks down the tagged branch up to the main branch, and then up to the stop needed. Nothing hard to implement. It's the 21st century, I believe that we don't have to rely on simple parsers that take nothing else but point-to-point connections. How would you enter this core line? It would be a relation with the ways and stops of the course again. So you would need the core line be a member of the branches and exception relations again. Probably I haven't fully understood how you would see your core lines respresented in the OSM data model. Pozdrowienia, Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
Oxomoa is suggesting bus stop on the way only for the most basic bus stop (think of a bus stop on a crossing on the country side with just a sign). If you have a more advanced bus stop with waiting positions for passengers on both sides of the street you add a public_transport=stop_position on the way *and* add a public_transport=platform node/way on the location you are proposing (e.g. where they are). This solution allows to fulfill the data requirements of routers you described. More details in the graphics here: http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Examples_for_the_application_of_the_model_for_stops Claudius Am 28.06.2010 20:07, Michał Borsuk: *ISSUE RAISED: * map bus stops to their physical location, not a point on the route/street * Present status: If I understand correctly, oxomoa suggests that the bus stop data (name, unique number, etc.) be entered as properties of a point on the route/street. Problems : * Lines often have stops that are quite far apart for each direction * This prohibits proper routing (GPS + walking), * this system is not very intuitive I find. *Proposed change: bus stops to be mapped exactly to where they are, and to be added to relations * Result: * better routing results e.g. one wants to find a correct way to the bus stop, and not to the average point somewhere between two stops of the same name in either direction. * more intuitive system - easier learning curve for new users. Influence on possible future software solutions: minor. May require all the stops on the route to be ordered based on their geographical location, as opposed to their place on the route (the latter is easier). Comments: I have seen this system very often implemented - two bus stops on each side, so my suggestion is just to codify the situation for future editors. Hope this is not too much at once, for more is to follow. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
Am 28.06.2010 22:16, Michał Borsuk: More details in the graphics here: http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Examples_for_the_application_of_the_model_for_stops The link you provided is a very good example of oxomoa's weakness. While the first simple bus stop is clear, for two bus stops I must create a stop_area. How do you do that? (the example is not clear enough) And more importantly, what for? Is the gain worth the extra time, which is considerable? Most of the time a relation for public_transport=stop_area is not necessary e.g. if you have two crossing bus lines which have the same name. In this case the router can easily determine that there's a changing location. But if you have more infrastructure like a taxi stand (See here: http://www.openstreetmap.org/browse/relation/152809 ) or a ferry terminal it's sometimes necessary to create a stop_area. But no need to worry: Don't do it if you think it's too much time. Eventually someone else does it. In OSM you don't have to do everything yourself. And you don't need to do the whole 1000km² yourself :) Do you have a map link to the area you are mapping public transport data? Maybe a complex example which took you time to tag? Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] RFC on tram stops
Hello Roland, My first reply would be: public_transport=stop_position/platform tram=yes If you want to keep backward compatibility definitely go for railway=tram_stop because trams are considered part of the railway network. I've never heard about nor seen any actually tagged as highway=tram_stop. I only know highway=bus_stop. Claudius Original-Nachricht Datum: Wed, 24 Feb 2010 18:14:22 +0100 Von: Roland Olbricht roland.olbri...@gmx.de An: Public transport/transit/shared taxi related topics talk-transit@openstreetmap.org Betreff: [Talk-transit] RFC on tram stops Hello everybody, What is the consensus on how to map tram stops? I've found highway=tram_stop as well as railway_tram_stop. The wiki page http://wiki.openstreetmap.org/wiki/Trams says nothing about that. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] JOSM Plugin
Am 05.02.2010 15:36, Roland Olbricht: Hello, as I consider mapping bus services as quite intricate, I've written a plugin for JOSM to make editing for comfortable. It is not very mature so far, but I would be grateful for any bug reports, comments and suggestions: The plugin itself http://78.46.81.38/misc/public_transport.jar And some documentation http://78.46.81.38/misc/public_transport.readme.txt The idea behind that is to standardise the data representation, according to http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema The plugin has successfully been used to map several bus lines in Wuppertal, in particular http://www.openstreetmap.org/browse/relation/163298 http://www.openstreetmap.org/browse/relation/359774 http://www.openstreetmap.org/browse/relation/34633 http://www.openstreetmap.org/browse/relation/359796 The source code is available at http://78.46.81.38/misc/public_transport.tar.gz I have not figured out so far how to add this plugin to the JOSM SVN. Cool. So far I've seen a new menu item Public transport having appearing in my main menu. Anything else to discover? If you were asking for a wishlist: Double-click routes or stops should actually select the relation/node and center the editor's view on the latter. What's the Tags-tab used for? It's empty when I loaded my Leipzig public transport data. I haven't discovered yet how the Suggest stops feature works. Thanks again for this plugin. Looks very promising, Clauidus ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Relations for stop areas in NaPTAN
Am 28.09.2009 15:05, Peter Miller: On 28 Sep 2009, at 13:44, Jerry Clough - OSM wrote: I've just noticed that the relations for stop places generated in the NaPTAN import do not have a type. I just happened to be browsing through some KeepRight issues and noticed a number of relation without type ones. I'm sure its unimportant right now, but I wondered how the stop place/stop area/interchange ideas are firming up, and what I should do eventually with the NaPTAN data. I noticed yesterday that the public transport article[1] is still linking to 'User:Oxomoa/Public transport schema' article for tagging information even though this is a personal page and therefore not something that others should touch. For starters should we agree not to link to personal pages for tagging information? I have developed a Stop Area article[2] based on Oxomoa's proposal and which also included feedback from CEN. It is currently available as a 'proposed feature'. however it should in general echo current practice. Would it be appropriate to now move it into the main name-space and use it as the primary overview article for stations, bus stops etc? If so should we just do it or do a formal vote first. Given that it is actually now a summary of current practice I would recommend moving it without voting but would be happy to follow the majority view. Thoughts please! [1] http://wiki.openstreetmap.org/wiki/Public_Transport [2] http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area Regards, Peter As a late-joiner to this list I definitely vote for moving Oxomoa's proposal to the public wiki space. Could anyone give a quick comment on what the consensus of the list member's on using his proposal is? I've been using it extensively and find it to be well though through and suitable for almost every possible public transport layout and on the same time offering the best possibility to have as much information covered in OSM as possible. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Relations for stop areas in NaPTAN
Am 28.09.2009 17:10, Frankie Roberto: 2009/9/28 Thomas Wood grand.edgemas...@gmail.com mailto:grand.edgemas...@gmail.com I think the type=* tag on relations is ugly, similar to the original class=* tag proposed on every element in the early days of OSM. class=* was dropped, as should type=* be. I don't know too much about class=, but I can see an argument that type= might be redundant on relations. However, given that it is in such widespread use, I guess this is a bigger debate to have. Right now, I'm more concerned about which of these patterns is better: type=site site=railway_station or type=site railway=station The first one has the advantage of following the X=Y, Y=Z tag hierarchy convention, the second has the advantage of re-using tags that have long been adopted for nodes. Frankie Why not simply: public_transport=stop_area_group etc as proposed in Oxomoa's proposal? Fixing the JOSM validator to allow public_transport instead of type is an easy task. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
