Re: [Talk-transit] Ideas for a simplified public transportation scheme
My impression is that this mess arises because bus stops are uni-directional and independent from the opposite direction. So we're used to having them as separate entities to the side of the road. Whereas tram stops are often in a single location for both directions (or close enough), so we want a single entity on the way, so at low zooms we can have a single symbol and single name label. Just like railway stations. These nodes are just labels. Me: I'd probably use highway=bus_stop for tram stops that are like bus stops, and add highway=platform for stops that have them, and attach whichever off-way entity seems most appropriate to the relation and let the data user figure it out. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers. Richard On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com wrote: 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com: 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com: In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole. A platform can be a pole, or a shelter, or a dock, or a boarding platform for a train... It is meant to abstract differences between different means of transport. That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation. Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider for processing. At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation. The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position? See above. Éric ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Information board details in bus stops
They get called a bus cage (because of the marking design) or more officially Bus Stop Clearway (ie somewhere where you can't load/park) in the UK. road_markings=yes might be more appropriate On Thu, Aug 21, 2014 at 4:11 PM, Jo winfi...@gmail.com wrote: In Belgium the letters B U S are painted on the asphalt. Hence we wouldn't call that strip, markings maybe. Jo On Aug 21, 2014 5:08 PM, Pieren pier...@gmail.com wrote: On Thu, Aug 21, 2014 at 4:52 PM, Jo winfi...@gmail.com wrote: On talk-be we were wondering what strip means. Good question. I guess it is the yellow lines marking the stop on the asphalt itself. But I'm not sure. I'll ask the contributor and forward his answer here. Pieren ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping intercity bus routes
I added service=express to the coaches that we have locally, using a
similar model to that used for train services. As long as it's clear, it
doesn't really matter (it can always be standardised at a later date).
{Formally, coaches are quite distinctive - the wheels are attached to an
underframe distinct from the coach body, which is why they are more
comfortable than buses. But I'd tend to make the distinction based on the
service offered, rather than the technology}.
Richard
On Sun, May 25, 2014 at 11:04 AM, Jo winfi...@gmail.com wrote:
In Belgium there are three operators, but in the region where they operate
they each have both city lines and regional lines and then a few long
distance lines operated with coaches. The regional lines are complementary
to the city lines in the cities as well. And some city lines go 15kms
outside the city in each direction, so the distinction is blurred.
I agree that there are too many red lines on the transport map, but apart
from using the official colours in a spiderlike representation, I don't see
a good solution to that problem.
Polyglot
2014-05-25 11:26 GMT+02:00 Jan v...@freenet.de:
Hi
Am 25.05.2014 11:02, schrieb Janko Mihelić:
I don't think we need a new tag. There would be a lot of gray area,
where do coaches end and buses start? The line isn't clear.
What would help is we should map the operator tag and then the renderers
should show the route or not based on the operator. Or different
operators could be rendered with different colors.
I think this is more a render problem than a mapping problem.
Janko
Of course it is a render problem. But you could not find the solution in
the operator tag. Why?
Have a look to Dresden. There you can find different operators. Esp.
RVD. The most lines from this operator are regional buslines around
Dresden. But there are also longdistance lines to Praha oder Berlin.
Or take a look at meinfernbus. Who is the operator? meinfernbus has the
licens an make the marketing sold tickets and so on. But the busses from
different small companys.
What should be the different between the busroutes? I think in germany
it is a little bit easier. You have lines regional or urban lines which
are orderd by gouverment.
The other ones are not orderd. the company have to earn the money only
from passenger and the minimum amount is ristricted.
Jan
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Tagging of railway station
The number of stations is quite small, so people will find a way to deal with it. Probably by re-adding nodes until the area advocates give up. On Wed, Dec 18, 2013 at 8:02 PM, Copro Grammes coprogram...@yahoo.frwrote: OK! Just one question: what do you mean saying Having separate node and area doesn't usually create too many problems ? Currently, either a node or an area is created to define a railway station, isn't it ? So there is never separate node and area in the same station. Is there something I didn't understand ? Zigeuner Le Mercredi 18 décembre 2013 10h49, Richard Mann richard.mann.westoxf...@gmail.com a écrit : The label role would be a solution, but unfortunately it isn't supported by the major renderers (afaik). So for the moment we stick with having the tags on the label node. Since the label is usually fairly obvious, having separate node and area doesn't usually create too many problems. So the main reason for change would be to fit in with a some mappers desire for everything to be tied up neatly in relations. That's not really a good enough reason. If it ain't broke, don't try to fix it. Richard On Tue, Dec 17, 2013 at 11:29 PM, Copro Grammes coprogram...@yahoo.frwrote: Thank you for your answers. I was also inclined to add railway=station tag to a node rather than to an area. But some French mappers advocate for the 'area' solution, contrary to the former version of the wiki, and I've begun to hesitate between both the approaches. So I was hoping this debate could be settled, but currently this is clearly not the case... Doesn't this matter interest anybody else ? Or doesn't anybody else have an opinion about this question ? This problem is not know (see place=*). We even already have an solution: role label. The role label could be interesting, but how can we use it ? Did you mean we could create a label relation [1] ? Or did you mean we should add a node with the role label to the stop_area relation which would be tagged railway=station (but the stop_area could also contain a bus station, a subway station, etc.) ? For new created objects I only use the new scheme but I do not delete the older tags if already tagged but only add the new ones. So I think it means you add the public_transport=station tag to the same node/area which was already tagged railway=station (as Roland did), doesn'it ? Cheers, Zigeuner [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Stop according to new PT scheme not rendered?
Simply rendering public_transport=platform+bus=yes (if that's correct) as a bus stop is a matter of a few lines of xml in the tag-transform (to insert a highway=bus_stop tag in relevant nodes, which the normal rendering processes can pick up). Though since this is functionally the same as the mappers adding a highway=bus_stop tag to the nodes then you do rather wonder what is the point. Of course it's probably more complicated than that, which is why the people who use these tags need to state what needs to be done, and in what situations. See http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform On Wed, Dec 11, 2013 at 7:36 PM, Mike N nice...@att.net wrote: On 12/11/2013 11:07 AM, fly wrote: If you keep on adding both schemes simultaneously you will not notice the problem and there will be no reason for developers to adjust the software. One of the problems in this situation is the map rendering developers have not taken an interest in the new scheme. If someone has submitted a 'pull request' that included the new tagging scheme but it was ignored, that is a different story. OSM is frequently described as a do-ocracy - in which finished and coded solutions win out over what is needed. And it's quite possible that we public transport mappers have been collecting and entering the information but have never gotten into CSS Map stylesheets, or whatever is the technology behind the renderers. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Stop according to new PT scheme not rendered?
tag-transform is an osmosis plugin. It happens before conversion to the postgres database, so you can use any tags that exist in the wild On Wed, Dec 11, 2013 at 8:07 PM, Jo winfi...@gmail.com wrote: For a long time, public_transport was not transfered to the DB used for the rendering of Mapnik. At that time it didn't make sense to update stylesheets. Jo 2013/12/11 Mike N nice...@att.net On 12/11/2013 11:07 AM, fly wrote: If you keep on adding both schemes simultaneously you will not notice the problem and there will be no reason for developers to adjust the software. One of the problems in this situation is the map rendering developers have not taken an interest in the new scheme. If someone has submitted a 'pull request' that included the new tagging scheme but it was ignored, that is a different story. OSM is frequently described as a do-ocracy - in which finished and coded solutions win out over what is needed. And it's quite possible that we public transport mappers have been collecting and entering the information but have never gotten into CSS Map stylesheets, or whatever is the technology behind the renderers. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] IFOPT-numbers for public transport platforms
UK bus stops all have codes (taken from the NaPTAN import), for example: http://www.openstreetmap.org/node/533877725 If it's not displayed on the stop, any reference should be prefixed with the source. That stop also has a publicly-displayed code which is tagged as ref=69345648. This is actually the numeric equivalent of the NaPTAN code (oxfgjmgt). Both these codes can be used to look information up on the internet. On Tue, Dec 3, 2013 at 10:13 AM, Andreas Uller a.ul...@gmx.at wrote: Dear list, First I'd like to say hello, my name is Andreas, and I consider it one of my main priorities in OSM to map things related to public transport (routes, stops) in my home city of Graz, Austria and beyond. The bus and tram lines in Graz are complete for quite some time now, so I started entering all the regional bus lines in Styria (a list of the current progress is here: [1]). Of course, I use the current tagging scheme, which can be quite tideous for regional buslines, because often there are many variants which each should get their own relation. My masterpiece so far are the bus routes 200/201 with a total of 62 variants (the timetable is so long, it's split into two files: [2],[3], route_masters in OSM: [4],[5]). So far the biggest problem was finding the correct position of bus stops in rural areas, where they often can't be seen on aerial images (no road-markings, no bays, no shelters...). Therefore, I'm very happy that we got the position of all public transport stops in Styria for use in OSM. The planned import is outlined here: [6] and a discussion has been started on the imports-Mailinglist: [7]. The reason for my mail to you is: We also received a lot of attributes for each platform, including a unique ID per platform, which has been identified as the IFOPT-number, an internationally unique number. It appears unclear, if this number should be added to all the platforms in OSM, or if this is unnecessary/unwanted. Has there already been a discussion on how (if at all) to use this number? The most straigh-forward method that comes to my mind would be to include it as ref:IFOPT, but what is the opinion on this list? I think it could become important when timetable- or real-time-data becomes available, but I don't know if this is true. I'm looking forward to you answers, Andreas [1] http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Regionalbusse_Steiermark [2] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200m_j13.pdf [3] http://verbundlinie.at/busbahnbim-auskunft/pdf/j13/stv_40200n_j13.pdf [4] http://www.openstreetmap.org/relation/955209 [5] http://www.openstreetmap.org/relation/2165551 [6] http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Import_Haltestellen_Steiermark [7] https://lists.openstreetmap.org/pipermail/imports/2013-November/002428.html ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for a new transport tag
On Thu, Mar 1, 2012 at 9:17 AM, Janko Mihelić jan...@gmail.com wrote: I must admit I don't know much about getting renderers to work, but summing frequencies of all bus lines on each way seems to be enough for now. And if you draw bus routes with colours ranging from blue (rare route) to red (busy route) it should be pretty obvious where you need to go if you want to get on a bus quickly. And for lines that aren't active on all days you can add a dashed line (which is visible only if it is the only route on the road). No renderer does summing of frequencies for you, although Maperitive is getting close (it will do summing already, but only to change labels, not to change line colours/widths) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Criteria for inclusion
I add service=something to the relation to roughly describe what the type of service is. The ones I use a service=city, service=country, service=express, service=park_and_ride. I also add a rough weekday frequency (number of buses per hour off-peak). That way people can pick out stuff they want and ignore stuff they don't. Richard On Wed, Feb 29, 2012 at 1:51 PM, Stefan Herbert Tiran stefan.ti...@student.tugraz.at wrote: Hi, On 02/29/2012 02:01 PM, Alexander Jones wrote: I just wanted to get your opinions on which routes should be included in OSM, or if there is an established set of criteria for inclusion. Fortunately OSM is not german wikipedia. There should be no worry about having too much information in the database. Yours, Stefan __**_ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-transithttp://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 Feature - Public Transport - Voting
This should be announced on the talk list. Richard On Thu, Mar 31, 2011 at 9:41 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Hi Voting is open for public transport proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Regards Teddy ___ 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] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Mon, Feb 7, 2011 at 5:39 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: I did not play around with actual renderers, but in theory the renderer should be able to get the diagram out of the order of the stops, regardless of the role. If one stop is twice in the route relation it should be obvious that it has to be some kind of loop. So in theory forward_stop and backward_stop can be replaced by the role stop. In theory data users should be able to do without roles at all (though they might appreciate some help if there are a lot of direction-specific stop names), and data users should be encouraged not to depend on them. I think the simplified advice is that roles aren't required (but that if you want to make the line-diagram service work with a two-directions relation, then - for the moment - you need to do xyz). Can anyone point me to a route relation with platform stop members, so I can check how the line-diagram service works in that situation? Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Sun, Feb 6, 2011 at 11:23 PM, Michael von Glasow mich...@vonglasow.com wrote: I did a lot of experimenting to get a simple, one-relation-per-direction line to render correctly. If I remember that correctly, the stop role is required (forward_stop, backward_stop or platform will also work). The tags on the members also seem to matter (e.g. amenity=bus_station, even with the correct role, does not get rendered.) http://www.openstreetmap.org/browse/relation/34631 doesn't have roles on the nodes (and it's one of the two relations used for the working example on http://78.46.81.38/public_transport.html ). ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow
mich...@vonglasow.com wrote:
if I may just comment on the relation: I would also use stop
rather than forward_stop and backward_stop for the roles since the
outward and return directions of a spoon route are somewhat hard to tell
apart. (Unless one stop in the loop is formally designated as the terminus
where services routinely end.)
You have to use forward_stop and backward_stop if you combine the two
directions in one relation, otherwise the same-named stop in the two
directions don't get combined on the line diagram. I think if you use
two relations, one for each direction, it combines them regardless of
role (and even if there's no role).
{I don't know what it does if there are both platform and stop nodes -
possibly puts them both in}
Richard
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Thu, Feb 3, 2011 at 10:37 PM, Michael von Glasow mich...@vonglasow.com wrote: On 02/03/2011 12:04 PM, Richard Mann wrote: ... something else (railway=tram_station) should go on the centroid as a courtesy tag. I would in fact tend towards using public_transport=stop_position, as suggested by Dominik, given that it's already being used. I don't think public_transport=stop_position is a particularly obvious tag (except as part of a wider scheme), so I'd probably mention both and see which we can persuade people to render. I've been attempting to order a relation using P2 (I don't recommend trying it yourself yet - the process needs streamlining). I managed to sort the nodes in a two-directions-with-loops relation: http://www.openstreetmap.org/browse/relation/85299 and got a reasonable line-diagram, once I'd added forward_stop and backward_stop: http://78.46.81.38/api/sketch-route?85299 I think this confirms that line diagrams will work fine with stops beside the way. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Potlatch 2 includes a display of the ways/nodes in order, and you can move them about, but it doesn't currently tell you anything about the member, except the id and the role (so it's pretty much a list of random numbers). I've raised a ticket requesting at least the member's name to be displayed, maybe also the distance from the first member (which would let you put them in rough order, unless your route doubles back on itself). If we had something like that then I think ordered relations would at last be practical in Potlatch. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On Wed, Feb 2, 2011 at 1:42 PM, Jo winfi...@gmail.com wrote: Is it possible to add a way to a relation twice with Potlatch? And is it possible to show that 1 way is part of a relation multiple times? Yes. Oxford Bus route 9 now has a certain section of the Green Road roundabout twice. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On Thu, Jan 27, 2011 at 9:06 PM, Michael von Glasow mich...@vonglasow.com wrote: Following the call for a better proposal, Tiziano, Oscar and I have drafted up a simple proposal. It is based on how we have mapped the public transport networks in our cities (Padova, Ferrara and Milan), with some improvements that came up during this discussion. Our approach was to keep it simple, therefore we have deliberately not treated special cases. For now, we want to standardize the basics; once we have agreed on those, we can discuss special cases which might not be covered by the current proposal and draw up an amendment, to be decided separately. You can find the proposal at: http://wiki.openstreetmap.org/wiki/Proposed_features/Simplified_Public_Transport_Scheme Constructive feedback and suggestions are welcome and can be sent to the list or left on the proposal's discussion page. Many thanks for this. 1) How do you envisage the mapping of loops (ie (say) six stops on one-way loop at one end of the route). I guess the two directions could be combined, or an arbitrary break made at some point round the loop. I think you need to suggest either one or the other or say that both are acceptable as long as they are ordered. 2) I think you need to define some options for tram stops (including what tags are on the single node on the track), and have a straw poll. This morning I'm tending towards using railway=platform areas/ways as stops (which is more consistent with existing tagging, and solves Teddy's problem with trams and light_rail using the same platform). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] New proposal to store public transport data
See http://www.openstreetmap.org/browse/node/533877725 for a not untypical NaPTAN bus stop ref is on a plate on the stop (and is the numerical equivalent of the Naptan Code) local_ref is on a plate on the stop, and is used to tell adjacent stops apart My guess is that there are various coding systems, and they each need to have their own tag, otherwise they'll get confused. The data user needs to know the various tags if they want to use the codes. I'd reserve ref for a unique id that can be validated on the ground (if there is one). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On Sun, Jan 23, 2011 at 10:38 PM, Richard Mann richard.mann.westoxf...@gmail.com wrote: On Sat, Jan 22, 2011 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). I think you'll find that the bulk of what you ascribe to unified stoparea (which I take to mean type=site relations) are in fact the UK NaPTan import (and not due to mappers). Richard Oh, and that 48,525 of them were added in this changeset! http://www.openstreetmap.org/browse/changeset/3891683 Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On Mon, Jan 24, 2011 at 11:40 AM, Christian christ...@balticfinance.com wrote: but it also includes people ... who would like to map also physical path a bus takes on the street. I think there's a logic in encouraging the use of ordered relations to show the paths of bus/etc routes - because this makes the data more browsable/maintainable. I think there's also a logic in putting branches in separate relations, for the same reason. If there are lots of branches that share a ref (or don't have refs), it's probably easier however to leave them bundled together. You'd hope that data users might make reasonable sense of data with errors/gaps in it, but it's good to harness the mapper's ability to look at maps/diagrams, spot the error and fix it. So I'd go for a little more order than Michal is proposing, but I'd agree that we need to keep it as simple as we can, with the advanced stuff used strictly only when necessary, and only to the extent that is necessary. On the general issue of when to use stop areas - if the raw distance is sometimes inappropriate, then we should mark these as exceptions, not mark everything. You don't even really need to group all the objects on either side of the barrier, as long as there are different names (+?network) on each side of the barrier - simply link one object on each side, and let the data user join up the rest using the name tag. So for instance, there might be a relation linking the Charing Cross station node to the Embankment station node, giving a minimum walking time. Contrariwise, you might have another relation linking Bank and Monument, advising that a penalty for going via surface level is inappropriate. (With apologies to those of you unfamiliar with the intricacies of the London Underground) Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On Sat, Jan 22, 2011 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). I think you'll find that the bulk of what you ascribe to unified stoparea (which I take to mean type=site relations) are in fact the UK NaPTan import (and not due to mappers). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On Fri, Jan 14, 2011 at 11:46 AM, ant antof...@gmail.com wrote: Example: If a housenumber is located exactly on the corner of two streets (and no street name attached to it), an algorithm could only guess which street it belongs to. Probably similar ambiguities are possible for bus stops as well (even if only in a very few cases). My opinion: we should require no stop position nodes neither stop area relations for simple and clear cases. But we should have a solid scheme at hand just in case we need them. Bus stops tend to be a lot closer to the road than houses, and don't tend to stop on corners, so I struggle to envisage a situation where it is actually ambiguous. Any ambiguity could probably be resolved by simply putting the node closer to the correct road. If it's only a small number of cases, it's unlikely anyone would bother processing the relation data (they'd just accept a tiny error rate). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
On Thu, Jan 13, 2011 at 12:27 PM, Richard Fairhurst rich...@systemed.net wrote: Hello all, I note with some alarm the very complex, relation-heavy proposal for mapping simple public transport objects. We don't appear to have got beyond the is this really necessary question yet. At the moment it's akin to putting access=yes on a highway=residential - true, harmless, and pointless. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
1) We need to see a proposal that is explicitly scalable. No more than one page to describe how to map a basic bus or tram line in a way that is consistent with existing usage (ie if you look around you will see lots of examples to reinforce your understanding). 2) There is no clear case for a new public_transport key. If existing usage of existing tags works ok for basic situations, that should be enough. 3) It doesn't matter whether people use one relation per direction or two. Both are readily parsable. However, forward/backward must refer to the direction of the way, not the direction of the route, otherwise you are cutting across other uses of those roles. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On Wed, Jan 12, 2011 at 12:21 PM, Ed Loach e...@loach.me.uk wrote: Unified_stoparea is flawed in that it isn't backwards compatible as it contradicts the documentation for highway=bus_stop (node beside way) to use it for the stopping position (rather than the platform). This is why the proposals that use public_transport tags are immediately better. You have to make sense of all the main existing schemas already (since they are unlikely to disappear). The main requirement is understanding what they are and how to tell them apart, not to try to standardise them (and especially not to standardise by multiplying the number of tags several-fold). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On Wed, Jan 12, 2011 at 2:50 PM, ant antof...@gmail.com wrote: Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. Another mapper will come and turn it into a stop area and update the route relations. But if applications can cope with only having an unordered relation and bus stop pole nodes (or indeed just tram_stop centroids), then why clutter the map with lots more tags and info that the applications can perfectly well derive for themselves 99.9% of the time? You should only supply the extra info for the 0.1% of the time when it can't readily be derived. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On Wed, Jan 12, 2011 at 4:07 PM, ant antof...@gmail.com wrote: So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. Stop areas are about linking the stop (notionally on the footway) to the road. Or they are about linking platforms with the same name. You can do that as you go along. The stopping_position and stop_area relation are just clutter. If you know the latlons of two stop areas, you can work out how to get between them by running your pedestrian routing algorithm. Marking footways between stops (other than the ones you can assume are adjacent to any roads not marked with footway=no) is more useful than linking the stop areas into a group and implying there is free access between any stop area within it. Basically you use relations to link objects which have a geographical relationship - not just a geographical proximity. There's sense in adding group objects if data relates to the group (eg to a station and not to it's individual platforms), but I'd find a convenient node or area to hold the info, not put it on an unnecessary relation. And if the information is relatively simple (eg a name), I'd settle for putting it on all the nodes, rather than create an artificial single object to hold it. 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 Wed, Dec 29, 2010 at 6:43 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: On 12/29/2010 12:30 AM, Richard Mann wrote: If someone maps a single node on the way and calls it highway=bus_stop, then that should be OK (but not recommended). unified_stoparea recommends that. You would allow but not recommend it, correct? Correct. We will have to live with these, but it's better that the use of bus_stop should homogenise to the dominant use. If someone then wants to put highway=bus_stop nodes on either side, that should be seen as the more correct tagging. The original node should be stripped of it's highway=bus_stop tag, or changed to something meaningless like highway=bus_stop_group_centroid or highway=bus_stop_position (if it genuinely is a stopping position, rather than a group centroid). What about changing it to platform, if it is really the platform/pole? We will have to live with people doing this, but it's better that the use of bus_stop should homogenise to the dominant use. 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 Mon, Dec 27, 2010 at 9:09 PM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Other mappers want to map a stop_position. At the moment they abuse highway=bus_stop as stop_position. What do you suggest these mappers to use for as stop_position? If someone maps a single node on the way and calls it highway=bus_stop, then that should be OK (but not recommended). If someone then wants to put highway=bus_stop nodes on either side, that should be seen as the more correct tagging. The original node should be stripped of it's highway=bus_stop tag, or changed to something meaningless like highway=bus_stop_group_centroid or highway=bus_stop_position (if it genuinely is a stopping position, rather than a group centroid). 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 Fri, Dec 17, 2010 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: How would you handle existing routes, only containing the stop_positions (railway=tram_stop)? Removing stop positions and adding the platform/pole? Leave them as they are. Or add platforms or highway=tram_stop nodes and put them in the relation instead of the railway=tram-stop nodes. So you would deprecate railway=tram_stop as the stop position? railway=tram_stop remains useful for rendering (it functions not as a stop-position but as the centroid of the stop area) My proposal therefore would add both (stop position and platform) [to the relation]. On this we do not have agreement. I would add platforms (or railway=tram_stop as a proxy for a platform). But not stop-positions. But what would you suggest to use as the stop_position for bus stops, if you would have to decide? I would expect data users to infer it from the position of the bus stop. Logically, you could mark a node for the stop_position between the bus-stop and the way (or even on the way if the stop_position blocks all traffic on the way). But this is pretty pointless - data users will probably ignore them anyway, and infer it from the bus stop location. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Conversation on this list (was: Proposed Feature - RFC - Public Transport)
Top tip: Tell people how you are feeling, not what you think of them. If you tell someone they are a then their reaction will be hostile; if you tell someone that you're finding the proposal a bit too complicated to understand / fit in with existing practice, then they're a bit more likely to respond constructively. If they don't respond constructively, repeat how it makes you feel - eventually they will get the message. 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 Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: You both are right, old is the wrong word for what I wanted to say. I do not want to replace or deprecate highway=bus_stop. Because English is not my first language, I catched up to consult my dictionary and I think traditional or conventional would be the better word, expressing what I wanted to say. established would be a better term ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
I think I may have figured out what it is that the established tags can't do. If you've got a railway=tram with a series of nice neat (and well-established) railway=tram_stop nodes then you can only make that railway=tram_stop node a member of a route relation once. The oxomoa conclusion was to have single-direction route relations. But this doesn't work well when you have lines that loop at the ends (fairly common with bus services), because the two relations overlap (you have to make certain nodes members in both relations, and that starts crossing a complexity/maintainability threshold). I think what we're edging towards is that expressing a tram stop as a single node isn't really enough. I think the open question is how tram stop pole nodes should be tagged, whether that affects highway=bus_stop, and how you deal with joint bus and tram stops. My suggestion: 1) highway=bus_stop - nodes to mark bus stop poles and to be members of bus relations (can also be used for tram relations) 2) highway=tram_stop - nodes to mark tram stop poles and to be members of tram relations (can also be used for bus relations). Renderers may prefer not to render these (there will generally be a railway=tram_stop node to use instead). There are only 13 of these in the world according to taginfo, so adoption of this tag for this purpose is unlikely to annoy anyone too much. 3) railway=tram_stop - nodes to mark the centre of the tram stop area, in the absence of a stop area relation. Mostly for rendering/labelling purposes. Can be used as a member of uni-directional relations, if setting up highway=tram_stop nodes is viewed as too complicated. 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 Fri, Dec 10, 2010 at 5:29 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: 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. I don't think you are going to get consensus with that sort of aggressive language (or indeed with any complex proposal that isn't graciously compatible with existing large-scale uses). The only inconsistency is that tram_stop generally refers to a stopping place and bus_stop generally refers to a quay. This is not enough reason to propose changing half a million established tags. Sometimes trams stop at bus_stops and sometimes buses stop at platforms, but that's not a reason to change the tags to something more generic. Relations for stop-groups are generally supported, but data-users need to be able to bundle adjacent stops with the same name for themselves, not rely on the presence of a relation. There appears to be a degree of consensus on using one type=route relation per direction (though it's not entirely clear whether this is really necessary), not worrying overmuch about telescopic routes or occasional diversions, and (groaning but) creating separate relations for routes that branch. Some of the work to implement this is waiting on Potlatch2 (which will have rather better relation support). I think the biggest uncertainty is how you handle loops at the end of a route - do you have overlapping single-direction relations, pick an abritrary position to change direction, or stick with having both directions in the same relation and let the data user worry about it. 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 Fri, Dec 10, 2010 at 11:11 AM, Michał Borsuk michal.bor...@gmail.com wrote: On 12/10/2010 11:20 AM, Richard Mann wrote: I think the biggest uncertainty is how you handle loops at the end of a route - do you have overlapping single-direction relations, pick an abritrary position to change direction, or stick with having both directions in the same relation and let the data user worry about it. I do it this way: end points from the timetable (Kursbuch), so the forward role goes to the last stop indicated in the timetable, and the backward role goes forth. I was thinking that role=loop on the loop stops might be one way to do it, with role=terminus for single-point route ends (and as a notional terminus on a loop)? This might also avoid the need for role=forward/backward on all the other stops. 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 Fri, Dec 10, 2010 at 3:31 PM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Think of a terminal bus station somewhere in the center of a city. Four bus lines end here. One platform of 50m. The four lines stop always at the same position (line 1 is first,..., line 4 is last). Only one pole for all buses. Where do you place your tags? Or how do you tell where to wait for bus number 4? At the pole that is 40m away from the stop position? That'd be four bus stops in the NaPTAN system, the three invisible ones being what they call customary stops (these are far more common in rural areas). I wouldn't recommend the passengers go to the stopping position (not unless I wanted them to be run over). highway=platform is for buses/nonrail railway=platform is for train/tam/rail What should be used if there are buses and trams at the same station? Whichever feels right. I'd probably use highway=platform if you can walk across the tracks at the platform, railway=platform if you can't. Does it matter? highway=bus_stop is used different. Sometimes as stop position, more often as platform/pole. See http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Results_2010-10-27 The meaning of how highway=bus_stop should be used differ. It can not be replaced easily with a new public_transport tag. I would agree that on-highway highway=bus_stop should be phased out (is anyone saying they should be retained?). I think they're a hangover from the time before we realised that tagging the pole was a better approach. In the mean time, I don't think it causes any major problem (it just isn't as clear as tagging the pole). 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 Fri, Dec 10, 2010 at 9:12 PM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Especially see the German talk page. I would like to approve a tagging schema that is clearly defined. Doing this with new tags is portably the easiest way. Redefining highway=bus_stop on or beside the way seams to be nearly impossible. Again: Have a look at the German talk page. The English-language discussion appears to have long reached a consensus (except for you). My German is not sufficient to follow the discussion, but clearly there are more people arguing each way, and shouting about it. If some people wish to use highway=bus_stop on the road, with highway=platform alongside, that can perfectly well be deciphered by software, and clearly documented as an alternative approach, and tag stats displayed to show which is dominant where. It does not need a public_transport key to confuse matters further. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
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] bus stops/platforms with electronic display of when the buses pass through
The early ones in the UK (in London) were known as countdown, and that's kinda stuck as a generic name, but I've no idea if anyone's used that as a tag. Richard On Fri, Oct 1, 2010 at 9:39 PM, Jo winfi...@gmail.com wrote: Hi, I didn't find a tag to use for synoptic displays indicating when buses are coming through (either as a time left to wait, or a full display of normal time+delay) at the bus stop level. And another one (at the bus_station level) with all the buses that are passing through (like the ones in train stations and airports). That one may even deserve its own node to indicate where it is and possibly even an indication in what direction it's facing. Jo ___ 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] child relations in type=route, route=bus
Bus stops should be nodes offset slightly from the way (not nodes on the way). How relations are handled is partly a problem with the editors. Potlatch 1.4 users (who can't readily order relation members, and who find it a pain having an excess of relations on a way), tend to do 2-way relations, and sometimes even bundle branches into one big relation. JOSM users tend towards doing ordered separate one-way relations, but you do end up with a lot of relations. Lots of relations is probably conceptually less complicated than child relations, so I'd probably go for that, editors-allowing. Richard On Tue, Sep 28, 2010 at 10:22 PM, Jo winfi...@gmail.com wrote: I'll probably be shot down on sight, but I wanted to be efficient and I created 'sub'-relations for parts of bus routes that are used by more than one line. As long as they recurse only one level deep, josm seems to be able to cope with them. I've been putting the mapping of bus routes off until child relations were properly supported. Then I went to have a look at how it all ought to be mapped and all I got now is a blurred idea of what seems to be ideal (Oxomoa, who thought of everything) and whether this practice has been accepted, or not. I can't seem to find out whether I should create a relation for each direction (which seems cleaner, but duplicates data), or work with forward and backward constructions in one relation for both directions. And, of course, I can't find any information on my own 'invention'/crutch: the use of child relations on parts of bus routes that are shared by more than 4 bus lines. This would greatly reduce the time I have to put in to maintain these relations, although it does add some complexity. I'm reading that the developers didn't mean for relations to be nested in one another, but why did they give us the possibility to create child relations, then, in the first place? I tend to like the use of relations to group data about a bus stop and to group bus stops together, as well. It's unfortunate that the tag remains HIGHWAY=bus_stop though, since it's not part of the highway, after all. This has always felt awkward to me, since I could only tag such bus stops on one way roads, as I wanted to indicate on what side of the road the stop actually was. Besides, here in Belgium each stop has a unique ref number, which is different on each side of the road. We should have come up with a better tag like public_transportation=bus_stop in the first place. All that to say, that I, now, still don't know how to tag bus_stops and quays and stopping positions, etc. Jo ___ 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] tagging stops served by multiple routes by more than one transit agency
IMHO route_ref is just a placeholder until you make the stops members of the route relations, so don't worry about it Richard On Wed, Jul 21, 2010 at 3:35 PM, Hillsman, Edward hills...@cutr.usf.edu wrote: As I mentioned in an earlier post, we have two public transit systems operating in the area of our university. They both serve a transit center/bus_station just off campus, but they share some stops on campus (and pass by some of the others’ stops on campus). They have multiple routes at some of the shared stops. I have found guidance on the wiki (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop) that where a multiple routes serve a stop, this should be tagged by listing the routes in numeric order and then (if necessary) alphabetical order, with the routes separated by semicolons, using no spaces unless they are part of the route designation. The example in the wiki is route_ref=66A;123;456;s78;x9 What is not clear is how to handle a situation in which a stop serves two operators and multiple routes for each. For example, one stop is on HART routes 5 and 12, and on USF routes A and C By inference, we would code the operators in alphabetical order, separated by semicolons, as operator=HART;USF And in this case, because the USF system designates routes by letters while HART uses numbers, we could luck out with route_ref=5;12;A;D But if both systems used route numbers, this would not indicate which routes belong to which operators. I know from experience that transit agencies in the Puget Sound region interline all the time, sometimes at transit centers/bus_stations but more often not, and most use numeric route identifiers. My understanding is that when the UK privatized some of its bus service, it had multiple companies serving the same stops. So this should not be a one-off instance here. An alternative format would be to code an operator1=HART and route_ref1=5;12, and an operator2=USF with route_ref2=A;D, but this seems error-prone to me. I’ve seen this format used in mapping some other features, but I haven’t seen documentation of it. A recent comment here suggested that it might be better not to include route information, because routes change, and situations such as this may be another reason not to do so. However, the routes near campus are very stable (the USF system adds routes, but otherwise changes them only to avoid construction). And, when we communicated with local mappers of bus_stops about our plans to upload GTFS data, we were asked whether we could upload the routes as well as the other information. So there is demand for it, even though in a trip-planning application we would use the GTFS stop_id to link between other OSM data and transit route/schedule data. We would welcome suggestions or guidance on how to handle the route tagging. Given the specialized focus of this problem, I’m not posting it to the tagging listserv. Ed Edward L. Hillsman, Ph.D. Senior Research Associate Center for Urban Transportation Research University of South Florida 4202 Fowler Ave., CUT100 Tampa, FL 33620-5375 813-974-2977 (tel) 813-974-5168 (fax) hills...@cutr.usf.edu http://www.cutr.usf.edu ___ 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] Bus stops in North America from GTFS data
Sometimes there are obscure codes on bus stops (eg in Oxford), so that
humans can text them to a Real Time Passenger Info service (called
OxonTime here). Eg the ref tag on this node:
http://www.openstreetmap.org/browse/node/533877725
For which you can get a departures list:
http://www.oxontime.com/pip/stop_simulator.asp?naptan=69345648
I make that three different stop ids, plus some other stuff that could
probably be combined to make one. If you haven't got unique ids yet,
then it's quite likely that someone will introduce them soon. You
know, you wait ages for a unique id then three come along at once...
Richard
On Fri, Jun 11, 2010 at 3:48 AM, Peter Miller peter.mil...@itoworld.com wrote:
On 11 Jun 2010, at 01:49, john whelan wrote:
Ottawa is different. The passengers complain if the bus is one minute early
or five minutes late. Quite unlike London in the UK where I used to live.
I think it stems from the minus 30c in winter time, with wind chill it can
be even colder, the passengers typically turn up about two minutes before
the bus.
Thanks for your thoughts.
Cheerio John
On 10 June 2010 20:25, Roland Olbricht roland.olbri...@gmx.de wrote:
You may want to follow
British/German standard. There is a tag that identifies stops
uniquely,
sorry can't recall at the moment. The last time I saw it was
Siegburg/Bonn train station.
Do you mean the ref tag as on node 160621? I'd strongly advice not to
follow
that way. The ref has also been used to list the lines stopping there
and
should not be used for something else.
I've never seen any item that identifies bus stops uniquely in Germany or
Britain and is visible to the ordinary passenger. It is also not needed -
all
bus stops with the same name in the same town are usually very close
together
(just stops for different directions). But being unique would be never
stated
as a formal constraint. Buses sometimes stop at two nearby stops with the
same
name. Thus there is nothing comparable to the stop_code here in Germany.
In the UK stops on either side of the road typically have the same 'name', a
different indicator sometimes imported into OSM as a 'local_ref' (or
naptan:indicator).
In London and some other places the 'indicator' is often a single letter (or
pair of letters) which is used on local maps and at the top of the pole and
is unique locally Notice the 'D' indicator on top of this bus stop:
http://www.flickr.com/photos/route79/2937392/
Here is a node in OSM which a 'Local_ref' code ('K' in this case)
http://www.openstreetmap.org/browse/node/469771254
And here is the same stop on an official TfL map used in bus shelters in the
area.
http://www.tfl.gov.uk/tfl/gettingaround/maps/buses/pdf/londonbridge-2163.pdf
This stop is also in a relation with the stop across the road:
http://www.openstreetmap.org/browse/relation/203739
But stops can be part of larger relations for a transport interchange, in
this case a railway station (although not all elements associated with the
station are included in this example yet) including platforms, other bus
stops etc.
http://www.openstreetmap.org/browse/relation/205097
Every UK bus stops also has a unique 'Naptan:AtcoCode' which is used by
information systems but not by humans.
Here are some pages about the UK dataset and the import
http://wiki.openstreetmap.org/wiki/NaPTAN
For comparison, here is a typical German stop
http://www.openstreetmap.org/browse/node/638614538
In the UK we imported all the relevant data into a naptan: namespace and
then copied elements with OSM tags into the main OSM space. This could be a
good way of working in other countries.
Finally here is a proposal for tagging some of the more complex aspects:
http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area
Regards,
Peter Miller
ITO World
www.itoworld.com
John, I would advice you to just set name to the stop_code if this is the
thing displayed on the bus stops. It is very different from the northern
European system. But passenger (or traveller) information is the primary
goal
of the OSM data. Thus a useful information in the tag that is expected to
be
crucial (name) is probably the best solution for Ottawa.
Cheers,
Roland
___
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
___
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] Bus stops in North America from GTFS data
On Fri, Jun 11, 2010 at 11:01 AM, Roger Slevin ro...@slevin.plus.com wrote: And whilst Peter Stoner is correct that Oxford is unusual in having two different next departure services (they do not supply their real time information to the national service, so this is only available to the local service) they do use the same stop codes for both - albeit they use the numeric version instead of the alpha version of the same code (as explained by Peter Miller's earlier posting). Oxford info _is_ available on the national service. And via Google Maps. The Oxontime site seems a bit less clunky to me (except the maps), having just tried all three, but each to his own. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Talk-GB] NaPTAN - Time for the rest?
On Wed, Mar 17, 2010 at 7:09 AM, Mark Williams mark@blueyonder.co.uk wrote: Gregory wrote: It only appears to go to Zoom 13 though - not quite big enough to read the print, without getting out of my chair... It goes all the way to z18, but just gives you a blank if you go somewhere it's not rendered. Blanks get rendered on demand, so go back when it's had a chance to render them. I haven't figured out quite how often it updates, but it's probably roughly weekly. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] bus route/relations done right
On Tue, Nov 17, 2009 at 12:13 PM, Peter Miller peter.mil...@itoworld.comwrote: Can I suggest we define some terms. A Line is all the journeys made using a particular reference (4, X13, Citi1 etc). Most people actually use the Route relation for this. This should include all the ways that are travelled on by the vehicle and all the stops that are called at. It might be helpful to add these stops in some sort of order (out then back) but it will not always be possible. A Line Variant (also know as a Service Variant) is a unique stopping pattern for a bunch of Journeys within a Line. (ie inbound, outbound, inbound via the school, outbound but stopping at the station and not going to the end of the route etc). This would include all the stops in order. however. I strongly suggest we don't add this data to OSM - it is too complex and not needed for mapping and should be kept in the schedules service. In particular, lets not start using the term Line to describe only a single direction (ie a variant) or we will get horribly confused. I think having the two directions in one relation is a recipe for confusion, because putting forward_stop as a role could refer to the direction of the bus service or the semi-arbitrary direction of the way. It's almost bound to be a mess. Whereas it's a lot clearer if the two directions are in separate relations. The only problem with splitting the two directions, as far as I can see, is editor support for having 2 x umpteen relations on a way. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Fwd: [OSM-talk] Train station names: Place Station ou just Place ?
UK railway term for the three letter code (eg EUS for Euston) is (wait for it): tlc (most railway locations also have a 5-digit stanox, a 4-digit national location code (nlc), a tiploc and several more, but for stations, the tlc is the nearest to a meaningful short code) I'd suggest something like tlc_ref Richard -- Forwarded message -- From: John McKerrell j...@mckerrell.net Date: Thu, Sep 24, 2009 at 8:10 PM Subject: Re: [OSM-talk] Train station names: Place Station ou just Place ? To: Cc: Talk OSM t...@openstreetmap.org On the subject of railway stations. I think it would be good if tagged them with their reference codes (no idea what the correct term is), all the stations in the UK have codes and if you know them it's quicker to use them while searching. I'm not such a geek I know all of them but the ones I use regularly I tend to know (in the UK they're also useful for the traintimes.org.uk site, e.g. http://traintimes.org.uk/sav/eus gets the next trains from Stratford-upon-Avon to London Euston). Just spotted the wiki mentions uic_ref so would this go under ref, or nr_ref (national rail) or something else? John ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] local_ref problem around Anerley in NAPTAN
1) Would it make sense to seek permision from TfL to derive labelling information from their website maps. It's such a rich source of info, it'd be a pity not to try. They're a bit daft putting copyright on their spider diagrams - if I were them, I'd want them to be copied. 2) I don't like the idea of ways for platforms, except possibly for the limited case where you've got one platform on each side. It's just not extendable. They should be areas. Sublettering for parts of platforms should probably be on nodes, representing the point on the platform that's the midpoint for boarding a train that stops at that platform (it will be in the timetable system as 2a, and a notional router ought to direct you to that point). If a platform is split into 2a and 2b, you probably need three nodes - 2a/2b and 2 (for trains that take up the full length). Richard On Wed, Sep 2, 2009 at 1:17 PM, Frankie Roberto fran...@frankieroberto.comwrote: 2009/9/2 Shaun McDonald sh...@shaunmcdonald.me.uk That was ages ago that I done that. I have added those extra details to a few stations, in some cases even adding the platform numbers. It does become more difficult when there are island platforms. The reason why I have been adding them is from a desire to know how to access the station, and how to access the platforms. It is also an increased detail thing. I had a discussion about island platforms on the wiki a while back (see http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/unified_stoparea#Sheffield). When I mapped Sheffield Station ( http://www.openstreetmap.org/?relation=79249) I noted that some platforms have up to 6 different names (2A, 2B, 3, 4, 5A, 5B). The options as I see it are: * stick all the names in a single ref= tag, semi-colon or comma separated (the former seems to be the convention?) * add the names to the stopping points (the node on the actual railway way). * splitting the platform way into different ways (eg two halves) and then tagging those separately (although this still leaves you the problem of different names for the different 'edges'). * doing something complicated with relations. Thoughts? Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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] local_ref problem around Anerley in NAPTAN
I'm not sure I like the idea of a 2 way on top of a shorter 2a and 2b way; hence my instinctive preference for nodes in the complicated situations. It can also be unclear where one subplatform starts and ends (especially where the split does't reflect a signalling berth, as is common in Germany, for instance). However, I can't really see the harm in using ways in the simple situation, and equally the full platform face name could be a way, but I'd make subplatform locations nodes rather than ways. The length of a platform could equally well be recorded as a length= tag on a node; the info is on the NR website if you know where to look - and have permission to use it. And the fact that it may not _yet_ render is - ahem - not relevant. Richard On Wed, Sep 2, 2009 at 4:42 PM, Peter Miller peter.mil...@itoworld.comwrote: On 2 Sep 2009, at 16:27, Richard Mann wrote: 2) I don't like the idea of ways for platforms, except possibly for the limited case where you've got one platform on each side. It's just not extendable. They should be areas. Sublettering for parts of platforms should probably be on nodes, representing the point on the platform that's the midpoint for boarding a train that stops at that platform (it will be in the timetable system as 2a, and a notional router ought to direct you to that point). If a platform is split into 2a and 2b, you probably need three nodes - 2a/2b and 2 (for trains that take up the full length). Personally I find linear ways pretty satisfactory for platforms, which often have no more width than a footpath after all (which are also tagged as linear features)/ Possibly we should use areas for larger platforms (ie the paved/tarmac area) with highway=pedestrian;area=yes and then add railway=platform ways to the edges of the area as required. Sub platforms can also be linear ways for their actual extent (I don't like using nodes for sub-platforms because they do have an extent which can be measured and is sometimes be important). For a platform that serves two tracks, one of either side then an area should be used with the two different sides having appropriate linear 'platforms' associated with them. I am not sure how to represent a set of steps coming down to a point in the middle of an area though. One reason to use linear ways for now is because we already have the tools to build, render and route models that use them. Areas are fine with side accesses, but not top and bottom accesses. Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Deleting relations
Thanks. I figured it might be the Is it time to confuse myself by trying to use two different editors scenario. Richard On Mon, Aug 10, 2009 at 9:08 AM, Ed Loach e...@loach.me.uk wrote: I couldn’t find a way in Potlatch. What I did was: a) In Potlatch add a dummy node to the relation b) Download the area containing the dummy node in JOSM c) Delete the relation in the relations list in JOSM d) Upload changes e) Delete the dummy node (I used Potlatch but could also have used JOSM as both were open – I had to refresh Potlatch to be aware of the JOSM changes first though). I hope you don’t mind me deleting it. http://www.openstreetmap.org/browse/relation/193015 Ed *From:* talk-transit-boun...@openstreetmap.org [mailto: talk-transit-boun...@openstreetmap.org] *On Behalf Of *Richard Mann *Sent:* 10 August 2009 01:54 *To:* osm *Subject:* [Talk-transit] Deleting relations I created a relation 193015 for Pad-Reading infrastructure, not realising that someone had already done so. 193015 has no members, but I can't see any obvious way of deleting it (in Potlatch). Is it possible? Richard ___ 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] Railway route relations
On Wed, Aug 5, 2009 at 1:12 AM, Cartinus carti...@xs4all.nl wrote: IMHO the solution is simple. Name it after what you are mapping. For vehicles: The route the cyclist follows is route=bicycle. The route bus 5 follows is route=bus. The route tram 13 follows is route=tram. The route the Eurostar follows is route=train. For infrastructure: The route of the M1 is route=road The route that is made up of the rail tracks of the East Coast Mainline is route=rail. Deprecating route= and replacing it with line= for most things where we currently use route= is a lot of work for no real gain. -- m.v.g., Cartinus ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit +1 Though I'd go for route=railway for infrastructure, since route=rail is currently being used by a lot of relations for which route=train would be better. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Railway route relations
Some information lies better on the infrastructure, so for some purposes you want both. I've concluded that infrastructure relations are probably the best way to mark whether route sections are predominantly 1-track, 2-track, 4-track etc. I don't think we've identified much of a need for infrastructure relations on self-contained railways, though I don't think they hurt. Richard On Wed, Aug 5, 2009 at 8:05 AM, Shaun McDonald sh...@shaunmcdonald.me.ukwrote: Couldn't you just use the network tag on the 3 tram route relations and merge the results to get this relations? It requires a bit more preprocessing to get the information that you are looking for, whilst making it easier for mappers and reducing the data size. Shaun ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Route relations types
There's a clear definition - a coach has it's wheels attached to an underframe distinct from the bodywork. That's why they're higher and have a more-comfortable ride. However there's an overlap caused by the 50km rule. I would surmise that the same threshold is used to require free access by freedom pass holders (over-65s). So I'd be inclined to call both route=bus, and use other tags (service=inter-urban/long-distance? vehicle=coach?) to distinguish them. Richard On Wed, Aug 5, 2009 at 1:20 PM, Peter Miller peter.mil...@itoworld.comwrote: On 5 Aug 2009, at 13:05, Frankie Roberto wrote: On Wed, Aug 5, 2009 at 12:38 PM, Roger Slevin ro...@slevin.plus.comwrote: Before anyone answers your question, please bear in mind that there is no clear definition of a “coach” ... and I have dealt with a feedback to traveline on this very point only this morning. A limited stop service between Cambridge and Oxford operated by vehicles which have “coach-style” seats and which the operator refers to as “coaches” runs a limited stop service between the two cities (the X5) – so we call this a coach. The complaint came from someone who had been unable to find this service as a “bus” because he saw a “coach” as being something which you had to prebook, and which expected a significant number of passengers to have luggage which went into luggage lockers under (or at the back of) the vehicle. Whilst I agree that there's no hard-and-fast distinction between buses and coaches, I think that using route=bus-coach is just going to confuse people! I'd suggest using either route=bus or route=coach, and simply going with whichever feels most correct (based upon what the route calls itself or how people generally refer to it). This doesn't resolve the potential ambiguities, but renderers and routing software would be advised to use a bit leeway when doing searches. I understood that one difference in the UK is if it was under 50km the operator could reclaim tax on their fuel. There is also evidently a 50 km rule about tachographs, where drivers operating longer routes need tachos, but ones on shorter routes (urban buses) don't. I think it is also useful to distinguish the sort of seating. I was on a coach last week, big leather seats and air-conditioning - very comfortable and reasonably quick. No toilet which surprised me, but it was only a 1 hour journey so I guess that is fair-enough. The experience of using a normal urban bus would have been very poor in comparison and I wouldn't have taken it. Personally I would vote for the distinction to be retained on the basis of the distance and type of vehicle. Regards, peter Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Railway route relations
Yes Frederik could tidy things up, but it's best not to change things arbitrarily (ie substituting line for route), because it just makes it harder to remember what is correct. The lack of presets for relations in Potlatch makes it doubly useful to minimise the complexity. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Multiple tracks
Ah. A choice between relationing for the specialist renderer and tagging for the specialist general renderer. Given a choice, I would opt for the latter, because it's easier for the tagger to see the results of their work - because it will be more likely to appear in renderings that they see. So it's more likely that they will do it. But perhaps the reality is that neither will be done. Much the same problem exists for cycle tracks next to roads, and the rendering is pretty poor as a result. Sometimes I get the impression that renderers think it's a matter of pride that they should be able to hack the data into shape for us. To the point that they leave things complicated (and rendered poorly) when a slightly more structured approach to tagging would simplify matters no end. I think the absolute simplest is to stick to using a single way unless there are really pressing reasons for separating them into individual tracks, and if you do separate into individual tracks then call them something different (railway=rail_track?) and leave the railway=rail way in place to continue to represent the corridor. We don't generally do separate ways for each side of a road (not least because of this rendering issue), so maybe we should accept it's not a good idea for rail either. Richard On Fri, Jun 26, 2009 at 9:27 AM, Peter Miller peter.mil...@itoworld.comwrote: On 25 Jun 2009, at 23:57, Richard Mann wrote: Rendering isn't generally that complicated. The renderer usually just draws all the lines on top of each other. Why process relations when you can just apply styles to appropriate selections of the raw data in an appropriate order? I agree that for basic rendering the tracks will go on top of each other and that for many purposes this will be sufficient and relations will not be required and we can just get on a create a detailed rail network with ways for every track and very set of points if we wish. The rendered will sort it all out reasonably well as one zooms out. However I am participating in this thread because I want to be able to produce rail maps that use different line styles for single track, twin track and multi-track routes because single track working is a real pain for operators and it is important to be able to see where they are on a map. Typically single track sections will be in one colour, twin track in another and multi-track in another one. I can already do this where there is a single way with 'tracks=1' or 'tracks=2' or 'tracks=4' etc. I would use a different colour for sections where the number of tracks was not specified. It can also do this easily where there was a relation with two or possibly more tracks as part of a group (I count the number of tracks and then render the route using a random track from the relation). As for junctions I would dump all the ways that were part of them and replace them with a node and terminate the tracks to the appropriate junction node. The code to achieve this is simple and will be reusable for other transport modes such as dual carriageways. Thinking about it, I think the most economical approach is as follows: 1) tracks should be equal to the number of parallel running tracks in the corridor 2) the tracks tag should be attached to a middle track (or an additional way on a central alignment, eg along the middle of an island platform) 3) the tracks tag should not be attached to other tracks (but won't do much harm if it is) 4) a further tag, say tracks_highzoom should define how many tracks this way represents at high zoom, if that's different. This will be 0 if it's an additional way on a central alignment, 1 if it's a middle track with the others also mapped out, and not stated if the tracks aren't individually mapped out. There are some awkward situations that need to be considered. 1) The middle track might not remain the middle track because might switch to become the outer track. Would one ignore this or select a different 'middle-track' or add an additional track? 2) How will it work where two different groups of tracks arriving at a junction and merge into a single (larger) group of tracks. The tracks north of Harringay is a pretty good test area for any tagging ( http://www.openstreetmap.org/?lat=51.5778172016144lon=-0.105679035186768zoom=16) . 3) The business of adding an additional tracks to help the rendered seems pretty unattractive. It occurs to me that we also need to deal with the situation where there are mixed modes running parallel, for example a tram running parallel to, one or in the middle of a road or a road and a cycle track running parallel or a guided busway and a cycle-track running parallel. The renderer could have a special line style for a these mixed modes and use them when it spots different modes wrapped up into a single 'dual carriageway' relation. At low-medium zooms, the renderer looks for railway=rail+tracks=X, and renders
Re: [Talk-transit] [Spam] Re: Multiple tracks
Choosing not to render a point because there's something else more important close by is relatively easy. Aggregating adjacent lines is much (much) harder. Identifying the number of lines that are adjacent is much (much) easier for the tagger than for the renderer. But I seem to be repeating myself; you either believe me or you don't. Richard On Tue, Jun 23, 2009 at 7:52 AM, Frankie Roberto fran...@frankieroberto.com wrote: On Mon, Jun 22, 2009 at 5:21 PM, Peter Miller peter.mil...@itoworld.comwrote: Can I suggest that as a start you create the detailed track layout and then we can look at different grouping strategies and see which ones the Mapnik people and routing people will find useful. Whatever you do should work for rail and trams and I see no reason for there not to be generality with roads. Lets not worry too much about the wrapping until we have stuff to wrap. I think this is a good approach. Using a tracks=1ofX tag could end up a complete waste of time if renderers can use the relations to dynamically pick whether to draw one track or more anyway. Mapnik seems to decide how many POIs to render based partly on how many it can fit on the map, so this doesn't seem infeasible. I'd like to see some discussion about strategies for tagging individual tracks though. I've attempted to do it in a few places, but mainly only at stations (where I've also drawn the platforms). Has anyone attempted to draw the switches where two lines meet? How about adding oneway=yes? Level crossings? Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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] [Spam] Re: Multiple tracks
The traditional method is to tag a node to be used as low zooms, and to tag various bits of detail to be used at high zooms. Using a relation for a point-location seems to be a rather more complicated way of achieving the same end (more complicated to create, more complicated to maintain). In the case of parallel ways, you could either: 1) create a further parallel way. This is what is done with house numbers (and to my mind would work for central reservations) 2) add information for the group to all the components (eg tracks=1of2). This works well if there's no obvious entity defining the centre line, but the components are very consistently located in respect of one another 3) create a relation for the group to hold group-level information (presumably this requires an algorithm to determine its geo-location, and could go a bit haywire if the component elements weren't strictly identical but offset, and would be complicated even if they were) The group-level information needs to be held somewhere (ie we can't just put tracks=1). But I don't think relations are the answer to all our problems. Richard On Mon, Jun 22, 2009 at 5:21 PM, Peter Miller peter.mil...@itoworld.comwrote: On 22 Jun 2009, at 12:53, Richard Mann wrote: On Roger's point about sidings - I'd map those as a separate track group, since they are the sorts of things people would expect to disappear at lower zooms. So north of Oxford station, I'd have the 4 down carriage sidings as one group, the four running lines as one group and the 4 up carriage sidings as a third group. Within each of those three groups, you could either do the individual tracks (as 1of4), or the tracks as a group (tracks=4). On loops, I'd probably exclude them from the running lines group, and use other tags (perhaps has_loops=yes) to tell me that there are extra tracks for a short-distance. You might also do has_loops:left and has_loops:right, but one-sided rendering is on the tricky side. So just south of Oxford at Kennington, you'd have the two running lines as tracks=2 (or 2xtracks=1of2) with has_loops=yes. If I had done the two tracks separately, the renderer would be entitled to expect me to have done the freight loops separately as well, so they can ignore has_loops=yes at high zooms, and just render the ways that have been drawn. Can I suggest that as a start you create the detailed track layout and then we can look at different grouping strategies and see which ones the Mapnik people and routing people will find useful. Whatever you do should work for rail and trams and I see no reason for there not to be generality with roads. Lets not worry too much about the wrapping until we have stuff to wrap. For your interest, here is an example road interchange which can be rendered as a dot if required, or used in driving instructions as 'turn left at the 'Whitehouse Junction'. http://www.openstreetmap.org/browse/relation/2470 Here is a dual-carriageway example - just bind all the parallel ways together and a renderer can then do a line down the middle at some point. http://www.openstreetmap.org/browse/relation/2490 Here is a railway station where all the elements (including tracks, sidings, platforms, buildings, car parking, taxi ranks and cycle racks) are all part of a relation. http://www.openstreetmap.org/browse/relation/2522 And here is a sample rail junction wrapped up using a relation:- http://www.openstreetmap.org/browse/relation/162263 This should make it very easy for a renderer. The general rule is 'if you can't fit in all the detail on the map and it is part of a relation then do a single dot or single line for the whole thing. Regards, Peter Richard On Mon, Jun 22, 2009 at 10:45 AM, Roger Slevin ro...@slevin.plus.comwrote: As someone who doesn't have the experience of mapping that you all do, but I do know something about public transport, I can see how the various concepts for single track and double track etc work along straightforward corridors (note these must be tracks (or maybe some other term) and not lines - as a line in public transport is something completely separate from the infrastructure) ... but what happens when operational details get more complicated ... at stations, or near and in depots and sidings? What happens for passing bays? Does a track have a directionality associated with it (even if it is only implied by a national convention of driving on the left/right... though that will give some issues on the German border where operations switch sides) - and what happens when multiple tracks are signalled for bi-directional working? I sense that there is a potential issue here between describing the physical infrastructure and describing its functional performance ... and I am not sure the boundary has been drawn correctly between the two. Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun
Re: [Talk-transit] Multiple tracks
While we could do it with relations, the dual-carriageway model might not be the best starting point, since I don't think we'll ever need to set railways up for routing programs to use. Nine months in, I can get my head round route relations and turning-restriction relations, but I struggle a bit with the value of relations to group parallel ways - it seems a complexity too far for the purpose (and I don't see much evidence of renderers making use of it to render dual carriageways). If tracks are notably more than the standard ~3m between track centres, then map them as single lines (tracks=1), as soon as they diverge. It's the renderers job to smooth the transition from tracks=2 to tracks=1. I'd do any pointwork as single lines, switching from 2xtracks=1of2 to 1xtracks=2 at some convenient point away from the junction where track separation is roughly standard (and let the renderer worry about making the transition seamless). Or just ignore pointwork for the moment. I think in time, people will map individual tracks separately. But there needs to be the ability to have a single way as a first step (not least to make it backwards-compatible), and not to make it too difficult to add descriptive detail (how many tracks, whether it is electrified, whether it has passenger services, whether it has fast services, whether it has fast/highspeed lines, whether it has freight lines). This is the sort of information that makes sense at low zooms. Separately, you might want to add the services as relations, so you can put together something more akin to the operator's maps, at a higher zoom. Richard On Mon, Jun 22, 2009 at 10:30 AM, Peter Miller peter.mil...@itoworld.comwrote: On 22 Jun 2009, at 07:51, Jochen Topf wrote: On Sun, Jun 21, 2009 at 05:09:35PM +0100, Richard Mann wrote: No, simpler than that: tracks=1 = render a single line at all zooms tracks=2 = render a double line at all zooms tracks=X = render a multiple line with X tracks at all zooms tracks=1ofX = render a single line at high zooms, but render as if tracks=X at medium/low zooms But then you'd still draw several lines nearly on top of each other in medium zoom levels which doesn't look good, which was the problem we were trying to fix? Anyway, this is a rather specialized trick about rendering the number of tracks properly. But what if you want to render other attributes. Say one of your two tracks is an industrial railway, the other a normal passenger railway and you want to distinguish those types. On medium zoom levels, is this a two track thing and we loose the type distinction, or do we keep it? The dual_carriageway and Junction relations would appear to the a good way of doing such things. I realise that the 'dual carriageway' term is not right and that other work would be required on the specifications, however it would seem a better starting point. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Junctions http://wiki.openstreetmap.org/wiki/Relations/Proposed/Dual_carriageways A group of parallel tracks would be combined using 'dual carriageway' and then a group short sections of track and nodes can be combined as a 'Junction'. The render would then have a choice of drawing modes, either a single line and single point, or multiple lines/points. Regards, Peter Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ 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
