Re: [Talk-transit] NaPTAN data import in Birmingham update
I think most of these issues stem from a few fields that were inadvertantly missed from the Birmingham area import. They were later corrected on the other regions within the West Midlands, but I witheld from doing a blanket fix since some of the Birmingham data had already been corrected by the time I realised. It was planned to merge in the missing tags at a later point through an automated change comparison process with the source data. My focus will be once again on the NaPTAN import in about a month. On 26/05/2009, Peter Miller wrote: > > On 26 May 2009, at 18:09, Roger Slevin wrote: > >> Brian >> >> I would be very interested to have the evidence about the transposed >> stops if that is possible. Thanks. >> >> Do you not have access to “bearing” – it’s in the source data, but I >> am not sure what you have access to. I can certainly let you have a >> file with the bearing data in it, if you do not have access to this >> from anywhere else. > > I think the bearing must be one of the fields that has been 'culled' > during the import; personally I would consider it essential > information for the next import/update pass. Without that information > will be hard to know if the name/identifier or bearing should be > changed. It is actually necessary to have access to the schedules > themselves to know how the stops are being used. >> >> CUS is a fact of life – nothing I can offer in response to that. > > The Stop-Type field would indicate what sort of stop it is (CUS for > customary) if it had been imported. Without this information it is > hard to review the NaPTAN data well and provide hard-hitting feedback > on the data. > > I know that as the number of tags for a node increasing that it > becomes difficult for Potlatch to manage, but I think that we are > going to solve that one to get the most out of this data-set. Possibly > someone needs to talk to Richard. > > You can of course also check data you are not sure about using the ITO > NaPTAN service that we gave a few people in the area access to for > evaluation purposes during the initial import. That will reflect the > current data rather than the data at the time of the import and will > include all the tags including the ones that have not been imported > into OSM this time. > > > > Regards, > > > > Peter > > >> >> If stops have been removed – but not removed or replaced in NaPTAN – >> then I would again like evidence to take back to colleagues who >> maintain NaPTAN. It is possible that they have changed the stop >> sub-type from MKD to HAR – that is the preferred method of handling >> this situation in NaPTAN. A formal HAR record has an entry point, >> what I call an “anchor” point in the middle, and an exit point. The >> guidance tells editors that these should all fall on the same named >> road (but in practice we know that a lot of them do not adhere to >> this rule). What is almost certainly the case in almost every case >> is that the length of the HAR section is not the same as the full >> length of the road ... most well-created HAR records would have >> entry and exit points which are at least a few metres short of the >> road junctions at each end. >> >> Best wishes >> >> Roger >> >> From: talk-transit-boun...@openstreetmap.org >> [mailto:talk-transit-boun...@openstreetmap.org >> ] On Behalf Of Brian Prangle >> Sent: 26 May 2009 17:19 >> To: talk-transit@openstreetmap.org >> Subject: [Talk-transit] NaPTAN data import in Birmingham update >> >> Having surveyed (and resurveyed) about three hundred bus stops I >> think I could draft (soon) a definitive report on how to proceed. >> >> There's also a few points to emerge about the Birmingham data >> >> 1. I'm coming across regular transpositon of stops from opposite >> sides of the road ( would be useful to have bearing data) >> 2. Not having the CUS marker on customary stops makes for hard work >> surveying and editing on estates where practically every other stop >> is CUS >> 3. Came across two routes (36 and 36C) where whole roads have had >> their bus stops physically removed (still showing as NaPTAN data) >> and the timetables show the roads as Hail and Ride zones. Couple of >> things here - I presume that actual practice has gone beyond the >> capacity of NapTAN data to keep pace ( I'll add the details to the >> NaPTAN error log on the mappamercia wiki shortly) and how do we >> import the HAR data - or represent it ( I can't remember where our >> previous discussions got to). In the meantime I'll probably just tag >> the roads as HAR=yes and HAR_route_ref= xx. (Without the timetable >> there's nothing visible on the ground to indicate to surveyors that >> they are in a HAR zone) >> >> Note for Thomas - I know you're into exam season - none of this is >> desperate - there's a few thousand more bus stops to survey and >> verify yet! >> ___ >> Talk-transit mailing list >> Talk-transit@openstreetmap.org >> http://lists.openstreetmap
Re: [Talk-transit] NaPTAN data import in Birmingham update
On 26 May 2009, at 18:09, Roger Slevin wrote: Brian I would be very interested to have the evidence about the transposed stops if that is possible. Thanks. Do you not have access to “bearing” – it’s in the source data, but I am not sure what you have access to. I can certainly let you have a file with the bearing data in it, if you do not have access to this from anywhere else. I think the bearing must be one of the fields that has been 'culled' during the import; personally I would consider it essential information for the next import/update pass. Without that information will be hard to know if the name/identifier or bearing should be changed. It is actually necessary to have access to the schedules themselves to know how the stops are being used. CUS is a fact of life – nothing I can offer in response to that. The Stop-Type field would indicate what sort of stop it is (CUS for customary) if it had been imported. Without this information it is hard to review the NaPTAN data well and provide hard-hitting feedback on the data. I know that as the number of tags for a node increasing that it becomes difficult for Potlatch to manage, but I think that we are going to solve that one to get the most out of this data-set. Possibly someone needs to talk to Richard. You can of course also check data you are not sure about using the ITO NaPTAN service that we gave a few people in the area access to for evaluation purposes during the initial import. That will reflect the current data rather than the data at the time of the import and will include all the tags including the ones that have not been imported into OSM this time. Regards, Peter If stops have been removed – but not removed or replaced in NaPTAN – then I would again like evidence to take back to colleagues who maintain NaPTAN. It is possible that they have changed the stop sub-type from MKD to HAR – that is the preferred method of handling this situation in NaPTAN. A formal HAR record has an entry point, what I call an “anchor” point in the middle, and an exit point. The guidance tells editors that these should all fall on the same named road (but in practice we know that a lot of them do not adhere to this rule). What is almost certainly the case in almost every case is that the length of the HAR section is not the same as the full length of the road ... most well-created HAR records would have entry and exit points which are at least a few metres short of the road junctions at each end. Best wishes Roger From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org ] On Behalf Of Brian Prangle Sent: 26 May 2009 17:19 To: talk-transit@openstreetmap.org Subject: [Talk-transit] NaPTAN data import in Birmingham update Having surveyed (and resurveyed) about three hundred bus stops I think I could draft (soon) a definitive report on how to proceed. There's also a few points to emerge about the Birmingham data 1. I'm coming across regular transpositon of stops from opposite sides of the road ( would be useful to have bearing data) 2. Not having the CUS marker on customary stops makes for hard work surveying and editing on estates where practically every other stop is CUS 3. Came across two routes (36 and 36C) where whole roads have had their bus stops physically removed (still showing as NaPTAN data) and the timetables show the roads as Hail and Ride zones. Couple of things here - I presume that actual practice has gone beyond the capacity of NapTAN data to keep pace ( I'll add the details to the NaPTAN error log on the mappamercia wiki shortly) and how do we import the HAR data - or represent it ( I can't remember where our previous discussions got to). In the meantime I'll probably just tag the roads as HAR=yes and HAR_route_ref= xx. (Without the timetable there's nothing visible on the ground to indicate to surveyors that they are in a HAR zone) Note for Thomas - I know you're into exam season - none of this is desperate - there's a few thousand more bus stops to survey and verify yet! ___ 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] NaPTAN data import in Birmingham update
Brian I would be very interested to have the evidence about the transposed stops if that is possible. Thanks. Do you not have access to "bearing" - it's in the source data, but I am not sure what you have access to. I can certainly let you have a file with the bearing data in it, if you do not have access to this from anywhere else. CUS is a fact of life - nothing I can offer in response to that. If stops have been removed - but not removed or replaced in NaPTAN - then I would again like evidence to take back to colleagues who maintain NaPTAN. It is possible that they have changed the stop sub-type from MKD to HAR - that is the preferred method of handling this situation in NaPTAN. A formal HAR record has an entry point, what I call an "anchor" point in the middle, and an exit point. The guidance tells editors that these should all fall on the same named road (but in practice we know that a lot of them do not adhere to this rule). What is almost certainly the case in almost every case is that the length of the HAR section is not the same as the full length of the road ... most well-created HAR records would have entry and exit points which are at least a few metres short of the road junctions at each end. Best wishes Roger From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle Sent: 26 May 2009 17:19 To: talk-transit@openstreetmap.org Subject: [Talk-transit] NaPTAN data import in Birmingham update Having surveyed (and resurveyed) about three hundred bus stops I think I could draft (soon) a definitive report on how to proceed. There's also a few points to emerge about the Birmingham data 1. I'm coming across regular transpositon of stops from opposite sides of the road ( would be useful to have bearing data) 2. Not having the CUS marker on customary stops makes for hard work surveying and editing on estates where practically every other stop is CUS 3. Came across two routes (36 and 36C) where whole roads have had their bus stops physically removed (still showing as NaPTAN data) and the timetables show the roads as Hail and Ride zones. Couple of things here - I presume that actual practice has gone beyond the capacity of NapTAN data to keep pace ( I'll add the details to the NaPTAN error log on the mappamercia wiki shortly) and how do we import the HAR data - or represent it ( I can't remember where our previous discussions got to). In the meantime I'll probably just tag the roads as HAR=yes and HAR_route_ref= xx. (Without the timetable there's nothing visible on the ground to indicate to surveyors that they are in a HAR zone) Note for Thomas - I know you're into exam season - none of this is desperate - there's a few thousand more bus stops to survey and verify yet! ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN data import
2009/3/6 Brian Prangle : > Hi everyone > > We discussed at our West Mids meeting last night the best way forward. Here > is what we would like to see happen: > > 1. Proceeed with the import on the basis of the proposed naptan taggings. > All imported data should have the naptan: prefix as we feel it is important > to identify the source of the data and differentiate it from OSMer-generated > data > 2. If it's easy to code, generate ways between related nodes for things > like plusbus zones, stopareas etc. We didn't discuss however how to tag > these, so I guess just leave them untagged. If it's going to be difficult > and slow down the implementation, then ignore it and just import the nodes > and we'll have to generate ways manually. StopAreas are very common in the London data that I've been testing against, as noted in previous emails to the list, the converter does convert the majority into relations. The only issues I'm having with it is trying to keep list of the national StopAreas. I should tackle this problem sometime this coming week. I guess a relation for a plusbus zone will also probably be good, a polygon can be derived from it automatically, I think we'd have to invent a new, creative relation scheme, since a stop area relation doesn't suit it well. > 3. Rather than import for the whole West Midlands, just import for > Birmingham as a test area - it's easier for us to cover as there fewer bus > stops in a smaller area, and it also won't piss off our neighbours in > Coventry - most of us are based in Birmingham. That's fine, I think I'll add a bbox filtering option. > 4. The import should not tag the data with highway=bus_stop. We'd rather > have un-rendered nodes that we can see in the editors and then either merge > with existing data or "switch on" by tagging where we haven't yet surveyed. > It is OK however to tag taxiranks with amenity=taxi (very few people have > been surveying and tagging these) I can just flip these tags fairly easily, so isn't much of a problem. > 5. Can we have a csv file of the data so we can keep track of our > verification and record variations, problems on the ground etc. and > co-ordinate activities so we don't go off duplicating effort? In the future > other OSMers will have the benefit of Christophe's visual tool to do this. > We'll give regular updates here on how we're faring and produce a short > report summarising our experience for future imports. A csv file of the data, can you be more specific on _what_ you mean by data? The wiki is an excellent place for coordinating tidy-up projects. Notes on changes can be stored on the nodes themselves, if suitable, otherwise we'd need an annotation tool with Christophe's visual tool. > 6. As a local initiative we are proposing to cease using (and convert > existing data) the ref=xx tag for identification plates we find on the > ground as it doesn't currently match any naptan data (and so can't be > regarded as a global standard reference) and we will use instead > asset_ref=xxx. This is Andy's suggestion and as he's the one who's entered > most of this data and he'll have to do most of the work - we all agreed > readily! Do we now want to import any suitable asset_refs (from whatever the equivalent field is called) from naptan, where they exist (most suited for other regions)? > > Let us know if there are any problems with this > > Regards > > Brian Regarding Peter's comments about obtaining the data, I'm already getting it from the official site for testing the converter, since the license they give there allows it explicitly. Regarding the data import more generally, do we have a rough timeline of when we want this done by? We should probably avoid the 0.6 and licensing changes, so we don't create more work for ourselves than is absolutely required. Gerrit - NaPTAN references nodes as being part of a StopArea, somewhat like our relation structure. The converter is already pulling them in according to the unified stop area spec. (Except for not having the stop-points on the road way, just beside, but thats just a moot point) -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN data import
Brian Prangle schrieb: > 2. If it's easy to code, generate ways between related nodes for > things like plusbus zones, stopareas etc. We didn't discuss however > how to tag these, so I guess just leave them untagged. If it's going > to be difficult and slow down the implementation, then ignore it and > just import the nodes and we'll have to generate ways manually. I the naptan extract for the West Midlands I have lists only seven stopareas in the area. So, it is probably not worth bothering importing them at the moment. Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN data import
Dammit. Once again I replied to the original author only, this morning. :( here is what I wrote... --- Hi Brian. Brian Prangle wrote: > We discussed at our West Mids meeting last night the best way forward. Here > is what we would like to see happen: These are some good ideas, I believe. > 2. If it's easy to code, generate ways between related nodes for things > like plusbus zones, stopareas etc. We didn't discuss however how to tag > these, so I guess just leave them untagged. If it's going to be difficult > and slow down the implementation, then ignore it and just import the nodes > and we'll have to generate ways manually. Can you please clarify this? >From your words I assume that NAPtaN groups stop elements by drawing a perimeter around them? Or connect them all with ways? If that is the case I oppose the physical marking you seem to suggest and would rather group them logical by means of a relation. OSM does have the necessary data models for that, which NAPtaN seems lacking. The conversion would be something like: If element is withing boundaries in NAPTaN, they will become members of the stop_area-relation. If I misunderstood, please ignore :) Gerrit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
