Re: [Talk-transit] NaPTAN bus stop database import - some more observations
Somebody mentioned yesterday that there were barcoded labels stuck to some bus stop shelters in the west mids. I snapped one of these whilst mapping yesterday, and have been able to do some useful correlations. http://wiki.openstreetmap.org/wiki/Image:WMAtcoBarcode.jpg (see text below) In short, for all those annoying pairs of (sheltered) stops that are difficult to tell apart for whatever reason, you now have another way of differentiating them. -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import - some more observations
In message Brian Prangle wrote: > Some more views and observations on the NaPTAN data import in Birmingham: > 1. It serves as a great QA on OSM data and shows that in the City > Centre where we have not been able to get decent GPS traces more accuracy is > needed so the potential of obtaining aerial photography is great. > 2.Its a great impetus to resurvey streets where earlier work > (potentially inaccurate from NPE tracing, older GPS devices, less points > collected, inexperience, not realising that roads have a width greater than > the rendered line so placing bus stops too close to the road etc.) can be > improved. I was in Birmingham today and obtained a trace on the top deck of a number 16 bus as it did its loop around the city centre. There are now two traces down Corporation Street. The more eratic one is me walking down the pavement. Both traces are quite close to the NaPTAN stops. Is there a reason for there not being more traces in Central Birmingham? My trace suggests that the NaPTAN points in Lower Bull Street are probably too far from the road but conversely the OSM stops are in the middle of the road. The true position may be in between. The discrepancy between my trace and Station Street is very marked. Is the turn from Hill Street into Station Street a right angle as in OSM or less sharp? The NaPTAN points are closer to my trace. -- Peter J Stoner UK Regional Coordinator Traveline www.travelinedata.org.uk a trading name of Intelligent Travel Solutions Ltd company number 3826797 Drury House, 34-43 Russell Street, LONDON WC2B 5HA ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import - some moreobservations
I've just done a quick render of what was extracted from the West Mids data set - http://dev.openstreetmap.org/~edgemaster/naptan/ 2009/4/1 Roger Slevin : > Thomas > > Ok - thanks. I will get a close approximation to this by using current data > with the same filtering criterion - and hopefully, if there are further > questions about any specific aspects of the data, I will be able to respond > to them. > > Roger > > -Original Message- > From: Thomas Wood [mailto:grand.edgemas...@gmail.com] > Sent: 01 April 2009 18:15 > To: ro...@slevin.plus.com > Cc: Brian Prangle; talk-gb-westmidla...@openstreetmap.org; > talk-transit@openstreetmap.org > Subject: Re: [Talk-transit] NaPTAN bus stop database import - some > moreobservations > > 2009/4/1 Roger Slevin : >> I would be able to comment more about the missing data and other aspect >> which you and others draw to the list’s attention if I could have a copy > of >> the NaPTAN data that has been put through the import process – can you (or >> someone else on the list) either point me to where I can find that > specific >> data set … or can send me a copy of the specific data that has been >> imported? >> > > Currently all data as of 25th March 2009 19:47:46 in the West Midlands > region with the a value of Birmingham (case insensitive) in the Town > field. > > I am planning to check to see if we missed any stops, and add any > missed based upon a bbox matching. > >> >> Best wishes >> >> Roger >> >> >> >> From: talk-transit-boun...@openstreetmap.org >> [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle >> Sent: 01 April 2009 13:41 >> To: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org >> Subject: [Talk-transit] NaPTAN bus stop database import - some >> moreobservations >> >> >> >> Some more views and observations on the NaPTAN data import in Birmingham: >> >> 1. It serves as a great QA on OSM data and shows that in the City >> Centre where we have not been able to get decent GPS traces more accuracy > is >> needed so the potential of obtaining aerial photography is great. >> >> 2. It’s a great impetus to resurvey streets where earlier work >> (potentially inaccurate from NPE tracing, older GPS devices, less points >> collected, inexperience, not realising that roads have a width greater > than >> the rendered line so placing bus stops too close to the road etc.) can be >> improved. >> >> 3. It’s also a great impetus to improve practice on surveying bus >> stops and be much more precise and comprehensive – also a stimulus to edit >> all those old bus stops where we placed them as a node on the way rather >> than to the side of ways which is our current practice. >> >> 4. QA works both ways and our surveys should help to improve NaPTAN >> data. >> >> 5. As an exercise(excuse the pun!) I cycled from Acocks Green to >> Moseley and back this morning along the No 1 bus route and surveyed 47 bus >> stops each time standing at the pole(leaning against it – you can’t get >> closer than that!) or underneath the plate at a shelter: 4 bus stops >> coincided within 3-4 m; 17 were “good enough” coinciding <8-10m. That’s >> approx 45%. The rest were out by anything up to 90m or were just missing. >> >> 6. I think either the pole where there is no shelter or the bus stop >> plate at a shelter should be what we survey – that’s where the >> identification of what we survey is located >> >> 7. Where a physical stop on one side of the road doubles up for one > on >> the other side also – I think we’re OK by surveying and tagging the > physical >> one with Andy’s suggestion of a tag opposite=yes. The NaPTAN untagged node >> on the other side can be left in place to indicate the logical >> relationship. >> >> 8. I like the idea of tagging where the bus stop is set back in a >> “lay-by” from the road which might account for some NaPTAN nodes being > some >> distance from the road >> >> 9. For our purposes “good enough” is probably sufficient rather than >> precise positional detail – I’m of the view that as long the bus stop has >> more or less the right relationships to its surroundings then that’s OK. >> >> 10. Surprised that there is no data for either the closed Digbeth Coach >> Station which is being rebuilt or the temporary replacement nearby. I >> thought we were importing off-street bus stops? Perhaps the
Re: [Talk-transit] NaPTAN bus stop database import - some moreobservations
Thomas Ok - thanks. I will get a close approximation to this by using current data with the same filtering criterion - and hopefully, if there are further questions about any specific aspects of the data, I will be able to respond to them. Roger -Original Message- From: Thomas Wood [mailto:grand.edgemas...@gmail.com] Sent: 01 April 2009 18:15 To: ro...@slevin.plus.com Cc: Brian Prangle; talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org Subject: Re: [Talk-transit] NaPTAN bus stop database import - some moreobservations 2009/4/1 Roger Slevin : > I would be able to comment more about the missing data and other aspect > which you and others draw to the lists attention if I could have a copy of > the NaPTAN data that has been put through the import process can you (or > someone else on the list) either point me to where I can find that specific > data set or can send me a copy of the specific data that has been > imported? > Currently all data as of 25th March 2009 19:47:46 in the West Midlands region with the a value of Birmingham (case insensitive) in the Town field. I am planning to check to see if we missed any stops, and add any missed based upon a bbox matching. > > Best wishes > > Roger > > > > From: talk-transit-boun...@openstreetmap.org > [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle > Sent: 01 April 2009 13:41 > To: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org > Subject: [Talk-transit] NaPTAN bus stop database import - some > moreobservations > > > > Some more views and observations on the NaPTAN data import in Birmingham: > > 1. It serves as a great QA on OSM data and shows that in the City > Centre where we have not been able to get decent GPS traces more accuracy is > needed so the potential of obtaining aerial photography is great. > > 2. Its a great impetus to resurvey streets where earlier work > (potentially inaccurate from NPE tracing, older GPS devices, less points > collected, inexperience, not realising that roads have a width greater than > the rendered line so placing bus stops too close to the road etc.) can be > improved. > > 3. Its also a great impetus to improve practice on surveying bus > stops and be much more precise and comprehensive also a stimulus to edit > all those old bus stops where we placed them as a node on the way rather > than to the side of ways which is our current practice. > > 4. QA works both ways and our surveys should help to improve NaPTAN > data. > > 5. As an exercise(excuse the pun!) I cycled from Acocks Green to > Moseley and back this morning along the No 1 bus route and surveyed 47 bus > stops each time standing at the pole(leaning against it you cant get > closer than that!) or underneath the plate at a shelter: 4 bus stops > coincided within 3-4 m; 17 were good enough coinciding <8-10m. Thats > approx 45%. The rest were out by anything up to 90m or were just missing. > > 6. I think either the pole where there is no shelter or the bus stop > plate at a shelter should be what we survey thats where the > identification of what we survey is located > > 7. Where a physical stop on one side of the road doubles up for one on > the other side also I think were OK by surveying and tagging the physical > one with Andys suggestion of a tag opposite=yes. The NaPTAN untagged node > on the other side can be left in place to indicate the logical > relationship. > > 8. I like the idea of tagging where the bus stop is set back in a > lay-by from the road which might account for some NaPTAN nodes being some > distance from the road > > 9. For our purposes good enough is probably sufficient rather than > precise positional detail Im of the view that as long the bus stop has > more or less the right relationships to its surroundings then thats OK. > > 10. Surprised that there is no data for either the closed Digbeth Coach > Station which is being rebuilt or the temporary replacement nearby. I > thought we were importing off-street bus stops? Perhaps the NaPTAN data > doesnt exist? > > 11. Cant find any nodes for taxi ranks not imported or doesnt exist > for Birmingham or Im not looking hard enough? > > 12. For the few nodes where Ive estimated the fit between OSM and NaPTAN > to be good enough Ive merged the nodes deleting the unverified tag and > editing source tag to v=naptan_import;survey > > 13. Verifying the data is going to be a long, slow process with a lot of > resurveying needed. > > ___ > Talk-transit mailing list > Talk-transit@open
Re: [Talk-transit] NaPTAN bus stop database import - some moreobservations
2009/4/1 Roger Slevin : > I would be able to comment more about the missing data and other aspect > which you and others draw to the list’s attention if I could have a copy of > the NaPTAN data that has been put through the import process – can you (or > someone else on the list) either point me to where I can find that specific > data set … or can send me a copy of the specific data that has been > imported? > Currently all data as of 25th March 2009 19:47:46 in the West Midlands region with the a value of Birmingham (case insensitive) in the Town field. I am planning to check to see if we missed any stops, and add any missed based upon a bbox matching. > > Best wishes > > Roger > > > > From: talk-transit-boun...@openstreetmap.org > [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle > Sent: 01 April 2009 13:41 > To: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org > Subject: [Talk-transit] NaPTAN bus stop database import - some > moreobservations > > > > Some more views and observations on the NaPTAN data import in Birmingham: > > 1. It serves as a great QA on OSM data and shows that in the City > Centre where we have not been able to get decent GPS traces more accuracy is > needed so the potential of obtaining aerial photography is great. > > 2. It’s a great impetus to resurvey streets where earlier work > (potentially inaccurate from NPE tracing, older GPS devices, less points > collected, inexperience, not realising that roads have a width greater than > the rendered line so placing bus stops too close to the road etc.) can be > improved. > > 3. It’s also a great impetus to improve practice on surveying bus > stops and be much more precise and comprehensive – also a stimulus to edit > all those old bus stops where we placed them as a node on the way rather > than to the side of ways which is our current practice. > > 4. QA works both ways and our surveys should help to improve NaPTAN > data. > > 5. As an exercise(excuse the pun!) I cycled from Acocks Green to > Moseley and back this morning along the No 1 bus route and surveyed 47 bus > stops each time standing at the pole(leaning against it – you can’t get > closer than that!) or underneath the plate at a shelter: 4 bus stops > coincided within 3-4 m; 17 were “good enough” coinciding <8-10m. That’s > approx 45%. The rest were out by anything up to 90m or were just missing. > > 6. I think either the pole where there is no shelter or the bus stop > plate at a shelter should be what we survey – that’s where the > identification of what we survey is located > > 7. Where a physical stop on one side of the road doubles up for one on > the other side also – I think we’re OK by surveying and tagging the physical > one with Andy’s suggestion of a tag opposite=yes. The NaPTAN untagged node > on the other side can be left in place to indicate the logical > relationship. > > 8. I like the idea of tagging where the bus stop is set back in a > “lay-by” from the road which might account for some NaPTAN nodes being some > distance from the road > > 9. For our purposes “good enough” is probably sufficient rather than > precise positional detail – I’m of the view that as long the bus stop has > more or less the right relationships to its surroundings then that’s OK. > > 10. Surprised that there is no data for either the closed Digbeth Coach > Station which is being rebuilt or the temporary replacement nearby. I > thought we were importing off-street bus stops? Perhaps the NaPTAN data > doesn’t exist? > > 11. Can’t find any nodes for taxi ranks – not imported or doesn’t exist > for Birmingham or I’m not looking hard enough? > > 12. For the few nodes where I’ve estimated the fit between OSM and NaPTAN > to be “good enough” I’ve merged the nodes deleting the unverified tag and > editing source tag to v=naptan_import;survey > > 13. Verifying the data is going to be a long, slow process with a lot of > resurveying needed. > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-transit > > -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import - some moreobservations
Brian Good comments - and from my "NaPTAN" perspective I share your view that data improvement should be a two-way thing. I am very keen to see if we can make that work through this exercise. I have always said that linear positioning of bus stops can be good enough if it is +/- 10m given that a bus is typically 12m long. But if it can be more precise than this, so much the better. Lateral displacement is more serious from the mapping perspective - and therefore the tolerance probably in both directions has to be set rather lower. Strangely at about the same time as you sent your message, one of my colleagues researching something completely different through the traveline journey planners, also commented on issues to do with the incorrect representation of Digbeth in NaPTAN data. My quick assessment is that neither the old nor the current coach stations have a NaPTAN record - and what has been happening without anyone realising it is that coaches have been shown on journey planners to be going to and from a particular roadside stop in the area of the old coach station. I have asked someone to investigate this and get it resolved in NaPTAN in the near future. I would be able to comment more about the missing data and other aspect which you and others draw to the list's attention if I could have a copy of the NaPTAN data that has been put through the import process - can you (or someone else on the list) either point me to where I can find that specific data set . or can send me a copy of the specific data that has been imported? Best wishes Roger _ From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle Sent: 01 April 2009 13:41 To: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org Subject: [Talk-transit] NaPTAN bus stop database import - some moreobservations Some more views and observations on the NaPTAN data import in Birmingham: 1. It serves as a great QA on OSM data and shows that in the City Centre where we have not been able to get decent GPS traces more accuracy is needed so the potential of obtaining aerial photography is great. 2.It's a great impetus to resurvey streets where earlier work (potentially inaccurate from NPE tracing, older GPS devices, less points collected, inexperience, not realising that roads have a width greater than the rendered line so placing bus stops too close to the road etc.) can be improved. 3. It's also a great impetus to improve practice on surveying bus stops and be much more precise and comprehensive - also a stimulus to edit all those old bus stops where we placed them as a node on the way rather than to the side of ways which is our current practice. 4. QA works both ways and our surveys should help to improve NaPTAN data. 5. As an exercise(excuse the pun!) I cycled from Acocks Green to Moseley and back this morning along the No 1 bus route and surveyed 47 bus stops each time standing at the pole(leaning against it - you can't get closer than that!) or underneath the plate at a shelter: 4 bus stops coincided within 3-4 m; 17 were "good enough" coinciding <8-10m. That's approx 45%. The rest were out by anything up to 90m or were just missing. 6. I think either the pole where there is no shelter or the bus stop plate at a shelter should be what we survey - that's where the identification of what we survey is located 7. Where a physical stop on one side of the road doubles up for one on the other side also - I think we're OK by surveying and tagging the physical one with Andy's suggestion of a tag opposite=yes. The NaPTAN untagged node on the other side can be left in place to indicate the logical relationship. 8. I like the idea of tagging where the bus stop is set back in a "lay-by" from the road which might account for some NaPTAN nodes being some distance from the road 9. For our purposes "good enough" is probably sufficient rather than precise positional detail - I'm of the view that as long the bus stop has more or less the right relationships to its surroundings then that's OK. 10. Surprised that there is no data for either the closed Digbeth Coach Station which is being rebuilt or the temporary replacement nearby. I thought we were importing off-street bus stops? Perhaps the NaPTAN data doesn't exist? 11. Can't find any nodes for taxi ranks - not imported or doesn't exist for Birmingham or I'm not looking hard enough? 12. For the few nodes where I've estimated the fit between OSM and NaPTAN to be "good enough" I've merged the nodes deleting the unverified tag and editing source tag to v=naptan_import;survey 13. Verifying the data is going to be a long, slow process with a lot of resurveying needed. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] NaPTAN bus stop database import - some more observations
Some more views and observations on the NaPTAN data import in Birmingham: 1. It serves as a great QA on OSM data and shows that in the City Centre where we have not been able to get decent GPS traces more accuracy is needed so the potential of obtaining aerial photography is great. 2.It’s a great impetus to resurvey streets where earlier work (potentially inaccurate from NPE tracing, older GPS devices, less points collected, inexperience, not realising that roads have a width greater than the rendered line so placing bus stops too close to the road etc.) can be improved. 3. It’s also a great impetus to improve practice on surveying bus stops and be much more precise and comprehensive – also a stimulus to edit all those old bus stops where we placed them as a node on the way rather than to the side of ways which is our current practice. 4. QA works both ways and our surveys should help to improve NaPTAN data. 5. As an exercise(excuse the pun!) I cycled from Acocks Green to Moseley and back this morning along the No 1 bus route and surveyed 47 bus stops each time standing at the pole(leaning against it – you can’t get closer than that!) or underneath the plate at a shelter: 4 bus stops coincided within 3-4 m; 17 were “good enough” coinciding <8-10m. That’s approx 45%. The rest were out by anything up to 90m or were just missing. 6. I think either the pole where there is no shelter or the bus stop plate at a shelter should be what we survey – that’s where the identification of what we survey is located 7. Where a physical stop on one side of the road doubles up for one on the other side also – I think we’re OK by surveying and tagging the physical one with Andy’s suggestion of a tag opposite=yes. The NaPTAN untagged node on the other side can be left in place to indicate the logical relationship. 8. I like the idea of tagging where the bus stop is set back in a “lay-by” from the road which might account for some NaPTAN nodes being some distance from the road 9. For our purposes “good enough” is probably sufficient rather than precise positional detail – I’m of the view that as long the bus stop has more or less the right relationships to its surroundings then that’s OK. 10. Surprised that there is no data for either the closed Digbeth Coach Station which is being rebuilt or the temporary replacement nearby. I thought we were importing off-street bus stops? Perhaps the NaPTAN data doesn’t exist? 11. Can’t find any nodes for taxi ranks – not imported or doesn’t exist for Birmingham or I’m not looking hard enough? 12. For the few nodes where I’ve estimated the fit between OSM and NaPTAN to be “good enough” I’ve merged the nodes deleting the unverified tag and editing source tag to v=naptan_import;survey 13. Verifying the data is going to be a long, slow process with a lot of resurveying needed. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import
On 1 Mar 2009, at 21:51, Roger Slevin wrote: Peter It would be very misleading to the OSM community for them to take any notice of your "hope" to have stopareas everywhere in the NaPTAN database. More than half of the country do not use stopareas at all in the journey planner that they use - and there is no reason for the three regions I am familiar with to create stopareas where they don't exist. Creating them as explicit stopareas, where we have perfectly good procedures that maintain implicit stopareas automatically, is not only a lot of work - but also requires continual maintenance. We do not have the resources to do this - so your "hope" is quite unrealistic. From a DfT perspective the stoparea is an optional feature within NaPTAN - and there is no realistic prospect for that to change at a national level. OSM should ignore stopareas in NaPTAN, therefore - and focus on the stoppoint records which are the fundamental content of NaPTAN. The important thing from the modelling perspective is that what OSM call a Stop Area is the same as what Transmodel calls a Stop Area, and therefore what nearly every European transport profession sector know as a Stop Area and in many other places too. There is a current proposal in OSM to use the term Stop Area for something that might be more like a Stop Place (in IFOPT). Nick Knowles has very helpfully added a good chunk of definitions onto the Stop Area proposal page giving the Transmodel terms for things and the OSM community should possibly look to hamonise terms with Transmodel where possible. It would certainly help avoid modelling issues later and make it much more attractive for other places considering offering public transport data. http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea Modelling a Stop Area is very simple. In Transmodel a Stop Area is purely a collection of Stop Points with a name and a reference. As such this could easily be modelled with a relation. With regard to the NaPTAN import , I see no reason why the OSM community should not import Stop Areas where they exist so that people can get used to modelling them and using them. Stop Areas are a useful tool for producing less detailed mapping where one wants to loose excessing detail. Other examples of where one wants to loose detail are when one is making maps of dual carriageways and railways. When one is zoomed in one wants to see lots of detail (ie two carriageways, slip roads etc, multiple tracks) and when one zooms out one wants to see only a single line. The people writing code for the renderers need data to practice on, and by providing Stop Areas for even one part of the world (ie one UK county) they have something to chew on. Another place where Stop Areas are useful is for journey planning. there is already GraphServer, a PT journey planning tool that uses OSM data (http://graphserver.sourceforge.net/gallery.html), and I am sure people in that project would be interested in seeing what use they can do with Stop Areas. The OSM community could also create algorithms to create Stop Areas in places where they don't currently exist, based on the rules in NaPTAN, for example where there are stops almost opposite each other on a road a long way from any other stops. That is just to sort of thing that someone might do when the renderers start using them and there is a reason for better coverage. Also, even if the UK NaPTAN import ignores them for now, then I know that there are some other potential imports in the EU area that could use them and so for that reason alone we should get the modelling and terminology right from the start. I wonder if we might get the stops of Toulouse soon as part of the OTT project that Hugues Romain was talking about recently? There are also loads of Stop Points avaiable from Google Transit Exchange data (http://www.gtfs-data-exchange.com/). Someone might go through those soon and see which ones are available on suitable licenses and import them. Again that is a big source of Stop Points, and as such a potential source of Stop Areas. I think we should see the NaPTAN import as being a useful catalyst for all sorts of innovation, much of which will be unexpected, and as such we should chuck as much in the pot as the project can digest, and to date that it a lot! Regards, Peter Best wishes Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Peter J Stoner Sent: 01 March 2009 21:18 To: talk-transit@openstreetmap.org Subject: Re: [Talk-transit] NaPTAN bus stop database import In message "Roger Slevin" wrote: Thomas You comment that York doesn't appear to be aware of the stoparea principle ... this is widespread. There are no downstream national a
Re: [Talk-transit] NaPTAN bus stop database import
Peter It would be very misleading to the OSM community for them to take any notice of your "hope" to have stopareas everywhere in the NaPTAN database. More than half of the country do not use stopareas at all in the journey planner that they use - and there is no reason for the three regions I am familiar with to create stopareas where they don't exist. Creating them as explicit stopareas, where we have perfectly good procedures that maintain implicit stopareas automatically, is not only a lot of work - but also requires continual maintenance. We do not have the resources to do this - so your "hope" is quite unrealistic. >From a DfT perspective the stoparea is an optional feature within NaPTAN - and there is no realistic prospect for that to change at a national level. OSM should ignore stopareas in NaPTAN, therefore - and focus on the stoppoint records which are the fundamental content of NaPTAN. Best wishes Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Peter J Stoner Sent: 01 March 2009 21:18 To: talk-transit@openstreetmap.org Subject: Re: [Talk-transit] NaPTAN bus stop database import In message "Roger Slevin" wrote: > Thomas > You comment that York doesn't appear to be aware of the stoparea principle > ... this is widespread. There are no downstream national applications that > make use of stopareas - and no pressure, therefore, to create stoparea data. > All the journey planners do use StopAreas in one form or another. Isn't it that some are completely "implicit", though not necessarily requiring identical common names, or just don't publicise their StopAreas in NaPTAN (NE England). While "Implicit" is useful and better than badly constructed "explicit", the explicit method gives more control and I hope that before too long we will have StopAreas in NaPTAN for all parts of the UK. > 2009/3/1 Thomas Wood : >> 2009/2/28 Brian Prangle : >> In other news, whilst on the train to (and from) York today, I wrote a >> sizable chunk of the StopArea code for the converter. It's in a mostly >> working state, the only issues I have to work out are StopArea >> hierarchies, particularly when a StopArea is defined in another >> region's dataset, the national rail one, for example. >> I'm either going to have to do a mass convert of the whole dataset at >> once (which I'm not looking forward to, since I suspect the memory use >> will skyrocket), or try and resolve the dependencies by parsing the >> national datasets to get a hash of all the StopAreas, and then append >> on the county level StopAreas as and when they're created, finally we >> can then upload the national StopArea points, as and when we get >> around to those types of data. (AIrports, NatRail, to name a few) > Whilst in York, I was able to photograph some bus stops, I've done a > quick comparison of the data, it seems to be the worst in terms of > standards compliance so far, but seems to be quite self consistent, > which is a small bonus. > Why quote the above? Well, it seems that York is unaware of the > existance of the StopArea principle. (At least, I couldn't find it in > a quick grepping of the data). > http://wiki.openstreetmap.org/wiki/NaPTAN/Local_schemes#York -- Peter J Stoner UK Regional Coordinator Traveline www.travelinedata.org.uk a trading name of Intelligent Travel Solutions Ltd company number 3826797 Drury House, 34-43 Russell Street, LONDON WC2B 5HA ___ 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 bus stop database import
In message "Roger Slevin" wrote: > Thomas > You comment that York doesn't appear to be aware of the stoparea principle > ... this is widespread. There are no downstream national applications that > make use of stopareas - and no pressure, therefore, to create stoparea data. > All the journey planners do use StopAreas in one form or another. Isn't it that some are completely "implicit", though not necessarily requiring identical common names, or just don't publicise their StopAreas in NaPTAN (NE England). While "Implicit" is useful and better than badly constructed "explicit", the explicit method gives more control and I hope that before too long we will have StopAreas in NaPTAN for all parts of the UK. > 2009/3/1 Thomas Wood : >> 2009/2/28 Brian Prangle : >> In other news, whilst on the train to (and from) York today, I wrote a >> sizable chunk of the StopArea code for the converter. It's in a mostly >> working state, the only issues I have to work out are StopArea >> hierarchies, particularly when a StopArea is defined in another >> region's dataset, the national rail one, for example. >> I'm either going to have to do a mass convert of the whole dataset at >> once (which I'm not looking forward to, since I suspect the memory use >> will skyrocket), or try and resolve the dependencies by parsing the >> national datasets to get a hash of all the StopAreas, and then append >> on the county level StopAreas as and when they're created, finally we >> can then upload the national StopArea points, as and when we get >> around to those types of data. (AIrports, NatRail, to name a few) > Whilst in York, I was able to photograph some bus stops, I've done a > quick comparison of the data, it seems to be the worst in terms of > standards compliance so far, but seems to be quite self consistent, > which is a small bonus. > Why quote the above? Well, it seems that York is unaware of the > existance of the StopArea principle. (At least, I couldn't find it in > a quick grepping of the data). > http://wiki.openstreetmap.org/wiki/NaPTAN/Local_schemes#York -- Peter J Stoner UK Regional Coordinator Traveline www.travelinedata.org.uk a trading name of Intelligent Travel Solutions Ltd company number 3826797 Drury House, 34-43 Russell Street, LONDON WC2B 5HA ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import
Thomas You comment that York doesn't appear to be aware of the stoparea principle ... this is widespread. There are no downstream national applications that make use of stopareas - and no pressure, therefore, to create stoparea data. In the areas of South and East England (SE, EM and EA regions on traveline) which (from this week) will be working with a combined multi-region database which also includes London, our system handles stopareas in two ways : - explicit stopareas contained in NaPTAN records, and - implicit stopareas created from the stoppoint records where stoppoints have identical commonnames and are within certain proximity limits of each other (a span of 150m for two stoppoints, or 250m for three or more stoppoints) This "implicit stoparea" process means that the stoparea data maintains itself when stoppoint data is maintained according to the rules - and works well for us. But it is an approach which works only with our particular supplier's data import processes each week. Where implicit stopareas exist in our regional journey planner they do not appear in NaPTAN and cannot be used in any other system (unless they apply the same rules when importing stoppoint data from NaPTAN). I would counsel the use of care with stopareas, therefore - as they are not widely used. You also referred to "national" stopareas - those with prefixes which begin with 9 and refer to Rail Stations, Airports, Ferry ports and Tram/Metro/LightRail stations. The existence of these stopareas is indeed in the relevant "national" area database - but they can also contain stopareas or stoppoints from local geographical data. Again the use of this is most significant in the SE, EM and regions - as these relationships define locations at which interchange can take place in the regional journey planner. I am not aware of any other regions where this is significant. Finally, I should note that because EM and EA are changing system supplier and adopting a system which relies completely on NaPTAN, a lot of data editing and improvement is going on in both regions (and will continue to do so for some time yet). So, although the development of the process of importing NaPTAN data should go ahead now, I will recommend that a fresh download of data is supplied in due course so that the current phase of data improvements in these regions in particular are captured when it is appropriate to do so. Best wishes RogerS 2009/3/1 Thomas Wood : > 2009/2/28 Brian Prangle : > In other news, whilst on the train to (and from) York today, I wrote a > sizable chunk of the StopArea code for the converter. It's in a mostly > working state, the only issues I have to work out are StopArea > hierarchies, particularly when a StopArea is defined in another > region's dataset, the national rail one, for example. > I'm either going to have to do a mass convert of the whole dataset at > once (which I'm not looking forward to, since I suspect the memory use > will skyrocket), or try and resolve the dependencies by parsing the > national datasets to get a hash of all the StopAreas, and then append > on the county level StopAreas as and when they're created, finally we > can then upload the national StopArea points, as and when we get > around to those types of data. (AIrports, NatRail, to name a few) Whilst in York, I was able to photograph some bus stops, I've done a quick comparison of the data, it seems to be the worst in terms of standards compliance so far, but seems to be quite self consistent, which is a small bonus. Why quote the above? Well, it seems that York is unaware of the existance of the StopArea principle. (At least, I couldn't find it in a quick grepping of the data). http://wiki.openstreetmap.org/wiki/NaPTAN/Local_schemes#York -- Regards, Thomas Wood (Edgemaster) ___ 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 bus stop database import
On Sun, Mar 01, 2009 at 12:26:40AM +, Thomas Wood wrote: > I believe that some of your suggestions for tags seem to be > superfluous to the way that some of the data will be structured. > I'm also all for keeping the tags as close to the standard OSM tagging > scheme as possible, for example, using alt_name rather than > naptan:alt_name. Do we really need "consistency on data origin"? I suggested in IRC that it may be worth keeping naptan:* tags that seemingly duplicate existing tags. name=* may not necessarily be the same as the NaPTAN name, just as the local name for something may not be the same as name=*. I didn’t think of any examples. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import
On Sat, Feb 28, 2009 at 10:11:00AM +, Brian Prangle wrote: > 3. If we can agree the entire tagging and import scheme would we get any > extra benefit from offering it for discussion on talkgb or should we just > get on with it? I think talk-transit is the place to discuss this, but a reminder to talk-gb that we’re discussing things here and if anyone wants to comment they should participate in the list wouldn’t go amiss. > With about 30 fields to be imported are editor screens going to look too > cluttered for the average OSMer? TIGER data takes up a lot of screen real > estate and there's a lot less fields. Should we (can we) cull the fields to > be imported? This is an editor issue. As we get more detailed we will get an increasing number of tags per object anyway. Editors might start filtering tags for brevity (though still indicating that there are more tags and allowing to view them). Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import
2009/3/1 Thomas Wood : > 2009/2/28 Brian Prangle : > In other news, whilst on the train to (and from) York today, I wrote a > sizable chunk of the StopArea code for the converter. It's in a mostly > working state, the only issues I have to work out are StopArea > hierarchies, particularly when a StopArea is defined in another > region's dataset, the national rail one, for example. > I'm either going to have to do a mass convert of the whole dataset at > once (which I'm not looking forward to, since I suspect the memory use > will skyrocket), or try and resolve the dependencies by parsing the > national datasets to get a hash of all the StopAreas, and then append > on the county level StopAreas as and when they're created, finally we > can then upload the national StopArea points, as and when we get > around to those types of data. (AIrports, NatRail, to name a few) Whilst in York, I was able to photograph some bus stops, I've done a quick comparison of the data, it seems to be the worst in terms of standards compliance so far, but seems to be quite self consistent, which is a small bonus. Why quote the above? Well, it seems that York is unaware of the existance of the StopArea principle. (At least, I couldn't find it in a quick grepping of the data). http://wiki.openstreetmap.org/wiki/NaPTAN/Local_schemes#York -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import
2009/2/28 Brian Prangle : > Hi All > > I've added to Thomas's initial work and completed what I think we should > import and what the tagging scheme should look like in > http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings. Please take a look > and shoot down in flames/agree/amend: particularly inclusion/exclusion > proposals > > Generally if the text of the proposed tag following the naptan: preamble is > in the format "word1_word2" it is our substitute for an ambiguous or verbose > NaPTAN field name, otherwise it's a copy (complete with CapitiLisation) of > the NaPTAN field name > Currently implemented is a 'tag copy' from naptan to osm tags for 'interesting' naptan fields. Of course, this is provided the field has not been caught by some other processing, such as the Indicator stuff. For example AtcoCode is mapped to naptan:AtcoCode. Current config for this is here: http://trac.openstreetmap.org/browser/applications/utils/import/naptan2osm/parse.py#L87 > > Three questions: > > Hail and ride section of route, with a linear footprint. > > Flexible zone, with an area footprint. > > 1.Presumably these are represented for HAR with 2 nodes (start and end) and > for FLX with multiple nodes (min 3) for which we would have to draw a way > between them and add a tag to the way. (naptan:HAR=yes and naptan:FLX=yes) Currently decided not to import these, for simplicity's sake. Eventually, we'll probably want to represent HAR as highway ways as part of the route relation? Possibly with a visible point in the centre for ease of rendering? Whatever we decide, we'd have to match it to the existing OSM data, my skills dont currently extend to this, but is on the long-run todo list. No idea about FLX yet. > 2.Thomas- how easy is this to add the way and tag it within the import > process or should drawing the way and tagging it be left to manual > intervention? Roger – how many of these are there? Drawing FLX zones should be fairly easy, if we decide to import them. > 3. If we can agree the entire tagging and import scheme would we get any > extra benefit from offering it for discussion on talkgb or should we just > get on with it? I've been taking the just get on with it route, filling in Tag mappings as I go. (Our edit conflicts this morning kinda proved this, more on this in a bit..) > > An observation: > > With about 30 fields to be imported are editor screens going to look too > cluttered for the average OSMer? TIGER data takes up a lot of screen real > estate and there's a lot less fields. Should we (can we) cull the fields to > be imported? We can easily not import data, the converter is currently standing at using 8 tags for a standard london bus stop. (3 of which are the standard source=naptan created_by=naptan2osm and naptan:unverified=yes) I believe that some of your suggestions for tags seem to be superfluous to the way that some of the data will be structured. I'm also all for keeping the tags as close to the standard OSM tagging scheme as possible, for example, using alt_name rather than naptan:alt_name. Do we really need "consistency on data origin"? In other news, whilst on the train to (and from) York today, I wrote a sizable chunk of the StopArea code for the converter. It's in a mostly working state, the only issues I have to work out are StopArea hierarchies, particularly when a StopArea is defined in another region's dataset, the national rail one, for example. I'm either going to have to do a mass convert of the whole dataset at once (which I'm not looking forward to, since I suspect the memory use will skyrocket), or try and resolve the dependencies by parsing the national datasets to get a hash of all the StopAreas, and then append on the county level StopAreas as and when they're created, finally we can then upload the national StopArea points, as and when we get around to those types of data. (AIrports, NatRail, to name a few) -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN bus stop database import
Brian Stoptype HAR has sub-records which contain two pairs of coordinates, one representing the entry point to the linear footprint, and the other representing the exit point. If guidance has been followed, then the linear footprint should stay on a road link with the same name along its length (but evidence indicates that the rules are not always followed strictly, either because they have been overlooked, or because the creator of the data hasn't appreciated where a road name changes takes effect). An HAR stop is a three point linear feature, anchored on the "central" point of the three. Stoptype FLX has sub-records which contain three or more pairs of coordinates which represent the boundary of the zone which is being described. The guidance indicates that the polygon formed by linking the points with straight lines should cover the relevant area - but of course it does not have to be precise, The points should be in sequence within the sub-records - and generally will be points where the boundary intersects roads entering/leaving the zone, plus additional points that pull the boundary so that it completely bounds the zone. In this process the inclusion of non-significant territory is normally ignored - the test is "does the zone cover all the roads that could be used by the Demand Responsive Transport service, and does it not cover any sections of road that are not to be used by the DRT service?" I don't have an easy way to check on the number of HAR and FLX stops there are across the country. HAR is quite common across the whole country. FLX exist in relatively few very rural areas - with Lincolnshire being one county which has a lot of them. There are few if any, however, in the whole of the South East region at present. Peter from Ito may be able to check more easily on the totals than I can. Roger _ From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle Sent: 28 February 2009 10:11 To: talk-transit@openstreetmap.org Subject: [Talk-transit] NaPTAN bus stop database import Hi All I've added to Thomas's initial work and completed what I think we should import and what the tagging scheme should look like in http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings. Please take a look and shoot down in flames/agree/amend: particularly inclusion/exclusion proposals Generally if the text of the proposed tag following the naptan: preamble is in the format "word1_word2" it is our substitute for an ambiguous or verbose NaPTAN field name, otherwise it's a copy (complete with CapitiLisation) of the NaPTAN field name Three questions: Hail and ride section of route, with a linear footprint. Flexible zone, with an area footprint. 1.Presumably these are represented for HAR with 2 nodes (start and end) and for FLX with multiple nodes (min 3) for which we would have to draw a way between them and add a tag to the way. (naptan:HAR=yes and naptan:FLX=yes) 2.Thomas- how easy is this to add the way and tag it within the import process or should drawing the way and tagging it be left to manual intervention? Roger - how many of these are there? 3. If we can agree the entire tagging and import scheme would we get any extra benefit from offering it for discussion on talkgb or should we just get on with it? An observation: With about 30 fields to be imported are editor screens going to look too cluttered for the average OSMer? TIGER data takes up a lot of screen real estate and there's a lot less fields. Should we (can we) cull the fields to be imported? ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] NaPTAN bus stop database import
Hi All I've added to Thomas's initial work and completed what I think we should import and what the tagging scheme should look like in http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings. Please take a look and shoot down in flames/agree/amend: particularly inclusion/exclusion proposals Generally if the text of the proposed tag following the naptan: preamble is in the format "word1_word2" it is our substitute for an ambiguous or verbose NaPTAN field name, otherwise it's a copy (complete with CapitiLisation) of the NaPTAN field name Three questions: Hail and ride section of route, with a linear footprint. Flexible zone, with an area footprint. 1.Presumably these are represented for HAR with 2 nodes (start and end) and for FLX with multiple nodes (min 3) for which we would have to draw a way between them and add a tag to the way. (naptan:HAR=yes and naptan:FLX=yes) 2.Thomas- how easy is this to add the way and tag it within the import process or should drawing the way and tagging it be left to manual intervention? Roger – how many of these are there? 3. If we can agree the entire tagging and import scheme would we get any extra benefit from offering it for discussion on talkgb or should we just get on with it? An observation: With about 30 fields to be imported are editor screens going to look too cluttered for the average OSMer? TIGER data takes up a lot of screen real estate and there's a lot less fields. Should we (can we) cull the fields to be imported? ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
