Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Why do routers need a node on the street? Next you'll be wanting me to put a node on the street outside every house so you can route to a house. This is a problem that should be solved by the router, not in the data. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 8 December 2010 20:44, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Hello Yes, the Public Transport proposal is basically based on Oxomoa, but in some details different. I do not care about which of the two proposals will be approved. But I think it is time to get a more exact schema approved then the fuzzy/non-existing schema (A railway station of 400m length and 20 platforms or a bus stop for 3 buses per direction of 50m length is reduced to one node) we have now. There is the issue of multiple relations per line in oxomoa, which in my opinion is a total misfit. There are roles in relations, and different variants of a route can be put there. Two, or more, relations per line is not only illegal (clearly against the principle, as it was stated by its creators), but also hell to administer, and JOSM-limited. Potlatch and Merkaartor account for 2/3 edits together. This simply cannot be passed to the final draft unchanged (as is). -- 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
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 09.12.2010 13:31, Michał Borsuk wrote: There is the issue of multiple relations per line in oxomoa, which in my opinion is a total misfit. There are roles in relations, and different variants of a route can be put there. Two, or more, relations per line is not only illegal (clearly against the principle, as it was stated by its creators), but also hell to administer, and JOSM-limited. Potlatch and Merkaartor account for 2/3 edits together. This simply cannot be passed to the final draft unchanged (as is). A missing feature in a specific software implementation usually is not a criteria of using or not using a feature in an API. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/09/2010 01:31 PM, Michał Borsuk wrote: On 8 December 2010 20:44, Dominik Mahrer (Teddy) te...@teddy.ch mailto:te...@teddy.ch wrote: Hello Yes, the Public Transport proposal is basically based on Oxomoa, but in some details different. I do not care about which of the two proposals will be approved. But I think it is time to get a more exact schema approved then the fuzzy/non-existing schema (A railway station of 400m length and 20 platforms or a bus stop for 3 buses per direction of 50m length is reduced to one node) we have now. There is the issue of multiple relations per line in oxomoa, which in my opinion is a total misfit. There are roles in relations, and different variants of a route can be put there. My previous post to this list contains an example of what you may encounter in real life. The case of a telescope line may be representable in a single relation, but I really do not know how to express in a single relation that some courses skip part of the route (the market example) and follow another (including some different stops) instead. If you have a decent way of expressing that in a single relation, please do share it here - I'd happily adopt that if only someone suggests a satisfactory solution to the issue. Two, or more, relations per line is not only illegal (clearly against the principle, as it was stated by its creators), but also hell to administer, and JOSM-limited. Are you referring to the master relation which contains the relations for the route variants? In fact I don't use them in Milan (in Munich it seems common practice and I follow that), and as of today renderers seem to be fine even without it. Take the following example: http://78.46.81.38/api/sketch-line?network=SITAMref=69style=padua This line is made up of four relations (two variants with one relation for each direction), and OSM Server Side Script manages to put them together based on their ref and network tags. Obviously, the individual relations must have all the tags that would otherwise go into the master relation. Or do you mean the fact that there are two (or more) relations per line? It is true that it means more effort, which is why I would happily consolidate the information into a single route if this were doable without losing information. Editor support, as Dominik writes, I would not overestimate. JOSM may be complex, but maintaining public transportation routes is complex on itself - someone doing that is quite likely to use JOSM anyway. I don't really see a reason against using JOSM - Potlatch in my opinion is for the occasional mapper or for very quick edits; Merkaartor may have some performance benefits (being a native application) but JOSM still has satisfactory performance. Potlatch and Merkaartor account for 2/3 edits together. Now this does surprise me - I would have expected a higher market share for JOSM. If you have the figures at hand, it would be interesting to find out how many of the people who edit public transportation data use JOSM vs. other editors. Then again - if other editors do not support all that's possible, we should also consider adapting the editors to support the tagging scheme we have in mind rather than adapting the tagging scheme to what is supported by all editors. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/09/2010 06:35 AM, Dominik Mahrer (Teddy) wrote: Hi Michael In the new proposal I am missing some details on how to build relations: 1. Should the outward and return trip be represented as two separate relations, as a single relation or is that up to the mapper? Each direction should be in a separate relation. This is written in the proposal. Both directions/variants should be member of a master relation. you're right, I overlooked that. I already use separate relations for each direction so I agree on that unless we find a convenient way of reducing the number of relation needed. I don't use master relations - in most cases, the relations of a single line are sufficiently identified by their ref and network. There may be exceptions, though: the network name is not guaranteed to be unique, and in that case it may be difficult to separate two lines with the same network names which in fact belong to different networks. Plus, here in Milan line variants are often (not always) indicated by adding a slash. For instance, line 42/ may mostly follow line 42 but serve some extra stops not served by 42 (and, in some cases, skipping the last stops of 42). 2. Which members should the relation contain, and in which order? You are not the first with this question, so I added some explanations to the proposal: First the stop_positions ordered (with role stop), then platforms ordered (with role platform) and then the ways ordered (without role). 3. Which data primitive should be added for stops? Stop positions AND platform. Stop position is important for the route itself, the platform is important for pedestrian routing. Fine for me, though it does mean some more effort to enter data. Except that we might consider adding the platform right after the stop it belongs to - that would make it easier to verify that both are there. 4. How are line variants mapped? Problem 1: A - B1/B2 - C - D - E1/E2 - F In morning and evening hours the bus stops at B2 instead of B1. During school holiday the bus stops at E2 instead of E1. This gives us four possibilities really used. When you add alt-roles to a stop you can't say when is what route used. So this does not work, we need really four relations. Yes, this is a more complex variant of my market example (yours is the equivalent of two markets, say, one on Monday and Wednesday and the other on Wednesday and Friday). As I mentioned in my post, I have no feasible solution for mapping this in a single relation. Problem 2: What do you want to say with role forward/backward? Forward/backward compared to what? To the route direction or to the tagged way direction? Actually both is used in the OSM database and no one knows how to interpret it. Role forward and backward is in my eyes a nice try to solve a problem. But it confused more then it solved. We should leave this away. As far as I know, this is accurately defined: it is relative to the tagged way direction, which may or may correspond to the route direction. But I, too, realize that this part confuses people. If we agree that ways must always be sorted, each way sharing an end node with the ones before and after (which I strongly recommend), then we can extract this information from the route itself without tagging it explicitly. Practical: I map the variant with the most stops (in your example twice A B1 E1 K. In JOSM you can easily copy a relation and change what is different. So to handle your 8 variants should not take 8 times mapping one variant. That works when you have the entire route from beginning to end. But some of us (I do) often follow just a part of the way and enter that, hoping to complete it at a later occasion (or someone else doing it). And once you have two partially-complete relations, updating them both together mostly means editing each relation manually. I personally leave away the very special cases (ex. first course starts at B instead of A). This is only relevant when timetable information is added to. For some applications, namely public transport maps and route sketches, this information might still be useful. For instance, those parts of the route which are omitted by some courses could be represented as a dashed line, the rest being drawn as a solid line. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/10/2010 01:45 AM, Richard Mann wrote: highway=bus_stop on a node next to a road railway=tram_stop on a node on railway=tram railway=platform on a node or way or area next to the tram tracks This is how you are using it. It is inconsistent. It is incomplete. It is historic. Beside your opinion there exist other, better schema that are _in use_: - Oxomoa (draft) - Public Transport (proposal) - unified stoparea (proposal) - stop place (proposal) - several variations of the four listed schema. If we go on waiting to approve one of them, the number of ideas and proposals will grow and the variations of them will increase too. This is not what OSM is designed for. OSM is useless if everyone makes it different. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
