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] NaPTAN and the new PT tagging schema
2009/6/24 Peter Miller peter.mil...@itoworld.com: On 24 Jun 2009, at 18:20, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: Can I suggest that we treat this import and any final tagging as a separate issue on separate timeline from the NaPTAN import just so long as no important information in the NaPTAN DB is lost in the process. Can you clarify what you meant by this? Is it essentially that we don't care about the new tagging schema and get on with the import? Yes. I would suggest that to avoid trying to agree a new tagging arrangement in a hurry prior to the import and keep the two projects separate. Firstly we import the rest of NaPTAN as agreed in the original discussion, and then secondly we agree a harmonised tagging arrangement of some sort and convert all the data to this new format (including the NaPTAN import). btw, did you mean this to be off-list? Feel free to copy the thread to the list if it was a mistake. Regards, Peter Ok, then to get on with the import, we need to review the errors we made with the Birmingham trail, and to get their views on the data review process - was it a good idea to import things without the highway=bus_stop tag, to get people to add them themselves? I think the one other outstanding issue is how we should represent the CUS stop types, at present in the 'active' tagging mode, they'll appear as fully-fledged highway=bus_stop nodes, like every other bus stop type, but with the addition of naptan:BusStopType=CUS, as (a rather obscure) indicator to the fact they may not exist. And then finally, we need to think about how we roll this out, county at a time is the most obvious step, I think we order the import based on requests on the transit list, followed by requests on talk-gb, with a target date to import the rest by. And on the technical front, I'm going to have to make sure that the import tools I'm using are 0.6-capable. I'm copying this over to the west-mids list so we can get their responses. -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Talk-gb-westmidlands] NaPTAN and the new PTtagging schema
On 26 Jun 2009, at 17:51, Andy Robinson (blackadder-lists) wrote: Peter Miller wrote: Sent: 26 June 2009 4:41 PM To: Thomas Wood Cc: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org Subject: Re: [Talk-gb-westmidlands] [Talk-transit] NaPTAN and the new PTtagging schema Your suggestions below make a lot of sense. I would however very much encourage you to include customary stops because they do indeed 'exist' even though there is no physical pole. Consider a road that doesn't have a name plate but when you people who live on the street what it is called they tell you. Does the street have a name or does it not - I suggest we would agree that it does? If a tree falls in a wood and there is no one to hear it did it make a sound etc. Customary stops can be confirmed by looking for physical marks of vehicles stopping or people standing around on the grass, from information at the stop opposite or from asking bus drivers. I would suggest that for now we believe NaPTAN. These are easy to add in a final cleanup anyway, just by usage of the route. The problem with the NaPTan data is that there are loads of stops that are probably just not used at all, hence we leave them turned off (silent data). I agree that we could and probably should import customary stops but I don't think we should assume they are actual in-use stops and hence should leave them silent in the database until someone confirms and adds highway=bus_stop For other areas of the country I think its fine (with the exception of CUS stops) to go ahead straight away and add the highway=bus_stop where there are few existing mapped stops. Ideally a post to the local uses in the area would confirm either way what they would like to do. You seem to be putting out different messages in the two above paragraphs. Are you saying you support the import of CUS stops or not. Also are you suggesting that bus stops are set as 'real' (ie active) stops. Possibly Roger will have some views on how many unused stops there are likely to be in the dataset. Looking at the Oct08 dataset there were 365,000 bus stops and 42,020 of them were unused at the time however this doesn't necessarily mean that they don't exist, only that no buses currently use them - in some cases they could be stops for summer-only services. I suggest that we should include all bus stops in the dataset regardless of use. We should removed stops that don't physically exist if there is no sign of them on the ground. Customary stops might need a visit to the friendly local bus operator who probably has all the information in his head. Physically marked stops can be checked by cruising the bus routes. Beyond that the only bit of data I dislike from the original run is the unverified=yes tag. It would be better to change this to verified=no for future imports (and easy to swap in West Mids.) sounds good Otherwise my experience in Brum is generally good in that with the exception of location (which is 10m to 100m off at least 50% of the time) the NaPTAN data matches the data on the ground very well. The accuracy will vary across the county and will reflect the care taken by each authority. I would expect it to be better in most places but might be proved wrong! Having a map that shows the bus stops would seem to be a good step to getting it improved by doing a physical survey or asking bus drivers to comment. If the data is hidden in the maps and not exposed it will be harder to sort out. I vote for having the data introduced as fully visisbly data but possibly we do it county by county. I am happy to be an early recipient of data for Suffolk and I think Ed Loach is keen to see the Essex data. Regards, Peter I know Brian and others have documented a few oddities here: http://wiki.openstreetmap.org/wiki/NaPTAN_Error_Log Cheers Andy Traveline would strongly advocate for their inclusion so that OSM links seamlessly to their journey planners. Regards, Peter On 26 Jun 2009, at 16:21, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: On 24 Jun 2009, at 18:20, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: Can I suggest that we treat this import and any final tagging as a separate issue on separate timeline from the NaPTAN import just so long as no important information in the NaPTAN DB is lost in the process. Can you clarify what you meant by this? Is it essentially that we don't care about the new tagging schema and get on with the import? Yes. I would suggest that to avoid trying to agree a new tagging arrangement in a hurry prior to the import and keep the two projects separate. Firstly we import the rest of NaPTAN as agreed in the original discussion, and then secondly we agree a harmonised tagging arrangement of some sort and convert all the data to
