Re: [Talk-GB] NaPTAN (stop) import
On 01/08/2014 11:17, Stuart Reynolds wrote: OK. Clearly I'm going to have to think on this for a bit longer. I think looking at somewhere like Swanley is a good idea, and also at somewhere like Derbyshire if the stops data hasn't been imported there. If you want to test a merge/import in the north-east corner of Derbyshire I'd be happy to sense-check any oddities that it turns up, but don't particularly want to have to dedupe a full NaPTAN import there (since lots of stops have been manually added). Cheers, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Just to remind folk, the West Mids volunteered as a pilot area for the original NapTAN import. We asked that the nodes were NOT tagged as highway=bus-stop as we wanted to survey them before they got rendered. We still haven't got round them all! And given the accuracy we're glad we asked for the silent import! In the meantime there have been so many changes , many of them major like the regrouping and renumbering of ALL the bus stops in Birmingham City Centre when all bus routes moved out of the centre in order to make way for the metro, that the original data is even less accurate. There have been at least 3 new bus stations in the region opened since then and I've lost track of the bus routes removed or changed! In short it's a MAJOR effort to keep this data maintained in OSM. Not that it's not worth it - just that with the current population of active mappers I can't see us staying on top of this. Anything serious is going to take a lot of outreach work to enthuse new mappers, and also some co-ordination with the transport folk - we gave up reporting discrepancies very quickly because of the ensuing deafening silence Regards Brian On 1 August 2014 19:30, Rob Nickerson rob.j.nicker...@gmail.com wrote: Just a few of my thoughts: 1. Bus routes Stuart wrote: I will need to think what to do when a bus turns off halfway along a road that is mapped as one line Here in Coventry we have all the bus routes mapped in OSM (splitting the road as necessary). Check out the render on the Transport layer: http://www.openstreetmap.org/#map=13/52.4056/-1.5172layers=T 2. Novam Viewer I'm pleased to see that people are still using the Novam viewer. Was worth my effort to get it migrated to the new website when we changed our mappa-mercia.org site. :-P The Novam site was set up by OSM user Xoff who is no longer living in the UK (and is no longer actively updating Novam). We would need someone to be willing to take over this if we were to enhance it. http://www.mappa-mercia.org/novam 3. A comparison tool Perhaps we need a viewer that does comparisons both ways, so both sides can accept changes from the other side if they look better. Yes, this is a great test case for building such a tool. Something that could then be used for other imported data would be great. I'm happy to help with testing but have almost no programming experience so cannot help to develop it. Stuart, is this something that you would look to develop yourself? Marc wrote: In Belgium Jo Simoens has done similar things for the public transport import of De Lijn (Flanders) and Tec (Wallonia). This could be a good start. Do we have a link to the code? Regards, R ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
I downloaded latest naptan data the other day and used qgis to filter stops.csv to just those in Tendring, or on roads that run along the border, to give me something more manageable to look at. 995 stops before any other filtering. I've not finished verifying imported stops after an initial burst of enthusiasm, but now see a workable plan for maintaining the data as: A) Finish verifying those already in OSM. Assume these are revision 1. B) Filter the 995 stops in the extract mentioned above to just those that aren't revision 1. Or have a created date newer than the majority of the rev 1 stops. Verify them. C) As new updates are released filter by created date and modified date to find new and changed entries. These are likely to be few. Verify them. Ed ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
On 01/08/14 01:36, Will Phillips wrote: I do not believe the stop areas should have been imported at all because they are not verifiable on the ground. Also, I am often unable to find much logic in the groupings other than the stops are relatively close together, so I don't think they are really useful. This is where having a unique ID for ab object comes into it's own. That is if the data source allows you to access that data using it. All that needs to be in the OSM data is 'bus stop' and it's NaPTAN reference, and anything else comes from a secondary read. Although names and the like may be worth duplicating. Where a source of a data import is readily accessible, then we don't need to duplicate the 'non-mapping' data. It may be for some imports we need a private copy of the data to make this work nicely, but that should be a natural part of the import process anyway. A clean copy of what was imported. What is available and easily accessible is growing daily ... but it does not need to be all imported into one database :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
In Belgium Jo Simoens has done similar things for the public transport import of De Lijn (Flanders) and Tec (Wallonia). He has python scripts to compare OSM data via an external reference of De Lijn to updates in a Postgis DB. He also has scripts to compute the most likely route between bus stops. This information was not in the DB of De Lijn. regards m On Fri, Aug 1, 2014 at 9:25 AM, Lester Caine les...@lsces.co.uk wrote: On 01/08/14 01:36, Will Phillips wrote: I do not believe the stop areas should have been imported at all because they are not verifiable on the ground. Also, I am often unable to find much logic in the groupings other than the stops are relatively close together, so I don't think they are really useful. This is where having a unique ID for ab object comes into it's own. That is if the data source allows you to access that data using it. All that needs to be in the OSM data is 'bus stop' and it's NaPTAN reference, and anything else comes from a secondary read. Although names and the like may be worth duplicating. Where a source of a data import is readily accessible, then we don't need to duplicate the 'non-mapping' data. It may be for some imports we need a private copy of the data to make this work nicely, but that should be a natural part of the import process anyway. A clean copy of what was imported. What is available and easily accessible is growing daily ... but it does not need to be all imported into one database :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
OK. Clearly I’m going to have to think on this for a bit longer. I think looking at somewhere like Swanley is a good idea, and also at somewhere like Derbyshire if the stops data hasn’t been imported there. In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Stuart From: Marc Gemis [mailto:marc.ge...@gmail.com] Sent: 01 August 2014 9:12 AM To: Lester Caine Cc: Talk GB Subject: Re: [Talk-GB] NaPTAN (stop) import In Belgium Jo Simoens has done similar things for the public transport import of De Lijn (Flanders) and Tec (Wallonia). He has python scripts to compare OSM data via an external reference of De Lijn to updates in a Postgis DB. He also has scripts to compute the most likely route between bus stops. This information was not in the DB of De Lijn. regards m On Fri, Aug 1, 2014 at 9:25 AM, Lester Caine les...@lsces.co.ukmailto:les...@lsces.co.uk wrote: On 01/08/14 01:36, Will Phillips wrote: I do not believe the stop areas should have been imported at all because they are not verifiable on the ground. Also, I am often unable to find much logic in the groupings other than the stops are relatively close together, so I don't think they are really useful. This is where having a unique ID for ab object comes into it's own. That is if the data source allows you to access that data using it. All that needs to be in the OSM data is 'bus stop' and it's NaPTAN reference, and anything else comes from a secondary read. Although names and the like may be worth duplicating. Where a source of a data import is readily accessible, then we don't need to duplicate the 'non-mapping' data. It may be for some imports we need a private copy of the data to make this work nicely, but that should be a natural part of the import process anyway. A clean copy of what was imported. What is available and easily accessible is growing daily ... but it does not need to be all imported into one database :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.orgmailto:Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Oliver, TNDS data (Traveline National Data Set, for other’s benefit - national set of bus coach timetables) does not currently have the route detail - known in TransXChange as tracks. This is because up to now there have been issues of IPR with OSGR coordinates derived from OS and/or Navteq data. Certainly from our point of view - and by “us” I mean the traveline regions of South East, London, East Anglia, South West, East Midlands and (shortly) West Midlands - we are all now on a merged system using OSM data so those problems have gone away. But I still won’t be exporting Tracks until TNDS asks me to. Even then, it still has the issues of “is this right”. Most of the time it is, but we do get some routes which find a shorter path along a back street rather than down the main road. Cheers Stuart From: Oliver Jowett [mailto:oliver.jow...@gmail.com] Sent: 01 August 2014 1:51 PM To: Stuart Reynolds Cc: Talk GB Subject: Re: [Talk-GB] NaPTAN (stop) import On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.ukmailto:stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Right - I was just trying to understand which was the canonical source. One of the things I've been wanting to try (but never have the time) is repair the OSM bus route relations based on the TNDS schedule info - which sounds very much like your track-finding system. But that gets dangerous if TNDS is indirectly pulling data from OSM itself.. Oliver On 1 August 2014 14:20, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: Oliver, TNDS data (Traveline National Data Set, for other’s benefit - national set of bus coach timetables) does not currently have the route detail - known in TransXChange as tracks. This is because up to now there have been issues of IPR with OSGR coordinates derived from OS and/or Navteq data. Certainly from our point of view - and by “us” I mean the traveline regions of South East, London, East Anglia, South West, East Midlands and (shortly) West Midlands - we are all now on a merged system using OSM data so those problems have gone away. But I still won’t be exporting Tracks until TNDS asks me to. Even then, it still has the issues of “is this right”. Most of the time it is, but we do get some routes which find a shorter path along a back street rather than down the main road. Cheers Stuart *From:* Oliver Jowett [mailto:oliver.jow...@gmail.com] *Sent:* 01 August 2014 1:51 PM *To:* Stuart Reynolds *Cc:* Talk GB *Subject:* Re: [Talk-GB] NaPTAN (stop) import On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
I see it as being better to put the right hints into the OSM data and the routing algorithm so that they can be automatically chosen from the TNDS data, rather than having the data in OSM, which is hard to represent some complexities such as a few journeys go via a school, some are part route, etc Shaun On 1 Aug 2014, at 15:32, Oliver Jowett oliver.jow...@gmail.com wrote: Right - I was just trying to understand which was the canonical source. One of the things I've been wanting to try (but never have the time) is repair the OSM bus route relations based on the TNDS schedule info - which sounds very much like your track-finding system. But that gets dangerous if TNDS is indirectly pulling data from OSM itself.. Oliver On 1 August 2014 14:20, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: Oliver, TNDS data (Traveline National Data Set, for other’s benefit - national set of bus coach timetables) does not currently have the route detail - known in TransXChange as tracks. This is because up to now there have been issues of IPR with OSGR coordinates derived from OS and/or Navteq data. Certainly from our point of view - and by “us” I mean the traveline regions of South East, London, East Anglia, South West, East Midlands and (shortly) West Midlands - we are all now on a merged system using OSM data so those problems have gone away. But I still won’t be exporting Tracks until TNDS asks me to. Even then, it still has the issues of “is this right”. Most of the time it is, but we do get some routes which find a shorter path along a back street rather than down the main road. Cheers Stuart From: Oliver Jowett [mailto:oliver.jow...@gmail.com] Sent: 01 August 2014 1:51 PM To: Stuart Reynolds Cc: Talk GB Subject: Re: [Talk-GB] NaPTAN (stop) import On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
The TNDS data isn't going to be based on what is already in OSM, if I've understood you correctly Oliver. Rather, in our bit, we import the GIS, route on it using proprietary (to our contractor) routing engines and manually adjust where appropriate, and then we can export the track coordinates as OSGR into the TNDS data. I haven't looked at the service tags in any detail, so what I'm about to say may well be there already. But if we want to represent the complexity then we either have to capture the individual departures at a stop or, more likely, try and represent the frequency/regularity of a service on a link. Then renderers could show dotted/thin lines, or put the service number in different colours for infrequent services. Of course, there are plenty of issues around that as well! Stuart From: Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] Sent: 01 August 2014 3:57 PM To: Oliver Jowett Cc: Stuart Reynolds; Talk GB Subject: Re: [Talk-GB] NaPTAN (stop) import I see it as being better to put the right hints into the OSM data and the routing algorithm so that they can be automatically chosen from the TNDS data, rather than having the data in OSM, which is hard to represent some complexities such as a few journeys go via a school, some are part route, etc Shaun On 1 Aug 2014, at 15:32, Oliver Jowett oliver.jow...@gmail.commailto:oliver.jow...@gmail.com wrote: Right - I was just trying to understand which was the canonical source. One of the things I've been wanting to try (but never have the time) is repair the OSM bus route relations based on the TNDS schedule info - which sounds very much like your track-finding system. But that gets dangerous if TNDS is indirectly pulling data from OSM itself.. Oliver On 1 August 2014 14:20, Stuart Reynolds stu...@travelinesoutheast.org.ukmailto:stu...@travelinesoutheast.org.uk wrote: Oliver, TNDS data (Traveline National Data Set, for other's benefit - national set of bus coach timetables) does not currently have the route detail - known in TransXChange as tracks. This is because up to now there have been issues of IPR with OSGR coordinates derived from OS and/or Navteq data. Certainly from our point of view - and by us I mean the traveline regions of South East, London, East Anglia, South West, East Midlands and (shortly) West Midlands - we are all now on a merged system using OSM data so those problems have gone away. But I still won't be exporting Tracks until TNDS asks me to. Even then, it still has the issues of is this right. Most of the time it is, but we do get some routes which find a shorter path along a back street rather than down the main road. Cheers Stuart From: Oliver Jowett [mailto:oliver.jow...@gmail.commailto:oliver.jow...@gmail.com] Sent: 01 August 2014 1:51 PM To: Stuart Reynolds Cc: Talk GB Subject: Re: [Talk-GB] NaPTAN (stop) import On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.ukmailto:stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I'm not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.orgmailto:Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
On 01/08/14 16:37, Stuart Reynolds wrote: I haven’t looked at the service tags in any detail, so what I’m about to say may well be there already. But if we want to represent the complexity then we either have to capture the individual departures at a stop or, more likely, try and represent the frequency/regularity of a service on a link. Then renderers could show dotted/thin lines, or put the service number in different colours for infrequent services. Of course, there are plenty of issues around that as well! Which is one of the targets of the 'transport' layer? I't is certainly nice to hear that OSM is providing a stable base to work from, and since your own data needs to be accurate OSM benefits in return. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Just my tuppence, since I used the Naptan stop data to make a printed map. Electronic version here: http://www.transportparadise.co.uk/busmap/ My memory is that I corrected a lot of minor positional errors, and the occasional name/bearing. I had to add in a few stops that weren't in Naptan. I wouldn't want to lose these changes, but I'd quite like to fill in stuff from Naptan that has been updated/corrected. Perhaps we need a viewer that does comparisons both ways, so both sides can accept changes from the other side if they look better. I created almost all the route relations from scratch (which was painful, but would probably have been easier if I'd used the german editor). Anyway, it basically only has to be done once, and needs human review, so I'd probably recommend doing them by hand, rather than attempting to generate them automatically from a timetable. I used service to distinguish between city/country/express services. I put frequency on the route relation (ie typical off-peak weekday per-hour frequency), such as this one: http://www.openstreetmap.org/relation/143161 If it's less than once per hour I put journeys (ie per weekday) on the route relation. Sometimes I put journeys on stops (as a flag for not rendering them). The frequencies can be summed/combined for particular ways, if required. I had to bodge that a bit for my map, but I'll probably do it properly when (if) I update it, since Maperitive now has a python capability. Richard On Fri, Aug 1, 2014 at 4:37 PM, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: The TNDS data isn’t going to be based on what is already in OSM, if I’ve understood you correctly Oliver. Rather, in our bit, we import the GIS, route on it using proprietary (to our contractor) routing engines and manually adjust where appropriate, and then we can export the track coordinates as OSGR into the TNDS data. I haven’t looked at the service tags in any detail, so what I’m about to say may well be there already. But if we want to represent the complexity then we either have to capture the individual departures at a stop or, more likely, try and represent the frequency/regularity of a service on a link. Then renderers could show dotted/thin lines, or put the service number in different colours for infrequent services. Of course, there are plenty of issues around that as well! Stuart *From:* Shaun McDonald [mailto:sh...@shaunmcdonald.me.uk] *Sent:* 01 August 2014 3:57 PM *To:* Oliver Jowett *Cc:* Stuart Reynolds; Talk GB *Subject:* Re: [Talk-GB] NaPTAN (stop) import I see it as being better to put the right hints into the OSM data and the routing algorithm so that they can be automatically chosen from the TNDS data, rather than having the data in OSM, which is hard to represent some complexities such as a few journeys go via a school, some are part route, etc Shaun On 1 Aug 2014, at 15:32, Oliver Jowett oliver.jow...@gmail.com wrote: Right - I was just trying to understand which was the canonical source. One of the things I've been wanting to try (but never have the time) is repair the OSM bus route relations based on the TNDS schedule info - which sounds very much like your track-finding system. But that gets dangerous if TNDS is indirectly pulling data from OSM itself.. Oliver On 1 August 2014 14:20, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: Oliver, TNDS data (Traveline National Data Set, for other’s benefit - national set of bus coach timetables) does not currently have the route detail - known in TransXChange as tracks. This is because up to now there have been issues of IPR with OSGR coordinates derived from OS and/or Navteq data. Certainly from our point of view - and by “us” I mean the traveline regions of South East, London, East Anglia, South West, East Midlands and (shortly) West Midlands - we are all now on a merged system using OSM data so those problems have gone away. But I still won’t be exporting Tracks until TNDS asks me to. Even then, it still has the issues of “is this right”. Most of the time it is, but we do get some routes which find a shorter path along a back street rather than down the main road. Cheers Stuart *From:* Oliver Jowett [mailto:oliver.jow...@gmail.com] *Sent:* 01 August 2014 1:51 PM *To:* Stuart Reynolds *Cc:* Talk GB *Subject:* Re: [Talk-GB] NaPTAN (stop) import On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit
Re: [Talk-GB] NaPTAN (stop) import
Just a few of my thoughts: 1. Bus routes Stuart wrote: I will need to think what to do when a bus turns off halfway along a road that is mapped as one line Here in Coventry we have all the bus routes mapped in OSM (splitting the road as necessary). Check out the render on the Transport layer: http://www.openstreetmap.org/#map=13/52.4056/-1.5172layers=T 2. Novam Viewer I'm pleased to see that people are still using the Novam viewer. Was worth my effort to get it migrated to the new website when we changed our mappa-mercia.org site. :-P The Novam site was set up by OSM user Xoff who is no longer living in the UK (and is no longer actively updating Novam). We would need someone to be willing to take over this if we were to enhance it. http://www.mappa-mercia.org/novam 3. A comparison tool Perhaps we need a viewer that does comparisons both ways, so both sides can accept changes from the other side if they look better. Yes, this is a great test case for building such a tool. Something that could then be used for other imported data would be great. I'm happy to help with testing but have almost no programming experience so cannot help to develop it. Stuart, is this something that you would look to develop yourself? Marc wrote: In Belgium Jo Simoens has done similar things for the public transport import of De Lijn (Flanders) and Tec (Wallonia). This could be a good start. Do we have a link to the code? Regards, R ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] NaPTAN (stop) import
On 01/08/14 18:32, Richard Mann wrote: I created almost all the route relations from scratch (which was painful, but would probably have been easier if Id used the german editor). Anyway, it basically only has to be done once, and needs human review, so Id probably recommend doing them by hand, rather than attempting to generate them automatically from a timetable. I was going to add route relations, but with dozens of service additions and deletions, and several routes changing each year in my area, Teesside (some routes twice a year when residents find they have no bus service any more and mount a campaign to get it re-routed again) I decided it was going to be onerous to keep them updated, so didnt bother. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] NaPTAN (stop) import
Hi, This is a spin off from the recent thread about imports, because I wanted to specifically talk about NaPTAN imports. Having briefly scanned the various wiki pages, I get the impression that the NaPTAN data was imported, once, in 2009. What I can't see, or haven't found, is any discussion about how how often this data is updated. NaPTAN (and associated NPTG) is a live data set, and is changing continually as bus stops are brought into use (e.g. new developments) and taken out of service. As I think I have mentioned, one of the reasons that I am now on this group is because of the adoption of OSM by a number of traveline regions, whose members are the very local authorities that create and maintain the NaPTAN data (including Nottingham/Nottinghamshire, since that was mentioned in the earlier thread). We therefore have an interest in making sure that the stop data on OSM is as up to date as the mapping. Is there an appetite within the community to maintain and update this data? And if so, how would we go about it, and how often might it be updated? For the record, the data set is change dated, and deleted records are retained in the data for reference until (eventually) being archived (although even then the stops are still contained in a separate archive file). So I think that the process of updating can be made a) robust, and b) reversible. Regards, Stuart ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Likewise for Birmingham (and probably most of the west mids). Stop positions in NaPTAN were as much as 200m off and we still continue to reposition as an when we map out an area. This is an example of where NaPTAN is better updating its data from OSM rather than the other way around. Cheers Andy From: Chris Hill [mailto:o...@raggedred.net] Sent: 31 July 2014 15:48 To: Stuart Reynolds; talk-gb@openstreetmap.org Subject: Re: [Talk-GB] NaPTAN (stop) import The NaPTAN data was imported for Hull and East Yorkshire at my request. I quickly realised that the data was of variable quality and resurveyed the ~1300 bus stops in Hull. Having corrected a large percentage of the stops, I informed the Hull council team, at their request, who then ignored me. I would not want any NaPTAN data re-imported in this area unless I was sure the quality has very substantially improved. Some working relationship with the council team who maintain the data would help too. Cheers, Chris, osm user: chillly On 31 July 2014 15:15:18 GMT+01:00, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: Hi, This is a spin off from the recent thread about imports, because I wanted to specifically talk about NaPTAN imports. Having briefly scanned the various wiki pages, I get the impression that the NaPTAN data was imported, once, in 2009. What I can’t see, or haven’t found, is any discussion about how how often this data is updated. NaPTAN (and associated NPTG) is a live data set, and is changing continually as bus stops are brought into use (e.g. new developments) and taken out of service. As I think I have mentioned, one of the reasons that I am now on this group is because of the adoption of OSM by a number of traveline regions, whose members are the very local authorities that create and maintain the NaPTAN data (including Nottingham/Nottinghamshire, since that was mentioned in the earlier thread). We therefore have an interest in making sure that the stop data on OSM is as up to date as the mapping. Is there an appetite within the community to maintain and update this data? And if so, how would we go about it, and how often might it be updated? For the record, the data set is change dated, and deleted records are retained in the data for reference until (eventually) being archived (although even then the stops are still contained in a separate archive file). So I think that the process of updating can be made a) robust, and b) reversible. Regards, Stuart _ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Hi, I would not wish to see a mass import in my area, but I could see some merit in comparing data 'line by line'. I can remember that in the early days (2009?) there were bus stops on the data at the time that NaPTAN was imported. Some were sensibly merged, but some were deleted before the value of merging was realised (I was probably as ignorant of how to sort it out properly in those days, as anyone else, so I don't think a witch hunt will help). Since then, I've made many cycle surveys in my area, and have updated NaPTAN stops to the extent that anything I have edited in the past is now in the right place the tags will be correct. However, some of the imported data was so inaccurate, that it was difficult to tell whether it should be moved North, South East or West, to where the nearest actual stop was. As a result of this, it is quite possible that there are stops shown in the right place with the correct tags concerning shelters, benches, tactile paving, name of stop, timetables or bus route references displayed, etc, but added to a NaPTAN reference which new data would show to actually be elsewhere. The only way of improving this would be a line by line comparison, with perhaps the transfer of a reference from new NaPTAN data, to the existing OSM data. If I appear in the history of the bus stop (Ctrl+h using JOSM), then there is a bus stop in that exact location. I suspect that this is true of many stops elsewhere, so some cautionary line by line merging is going to be needed. I use the NOVAM - viewer from http://b3e.net/novam/ to check what needs doing, (Birmingham colour scheme suits my purpose). If you use this zoom into Swanley, Kent (just off J3 of M25), you will find there are several stops which I have created, for which there is no NaPTAN data in the current database. It would obviously be sensible to add that data if you have it - just don't move the stop or change the other tags I've added please. You'll also see that I have marked some bus stops as 'not physically present'.. I think most mappers have worked from http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data (history shows this was last updated in 2011 with most of the updates from 2009), but there are more recent articles at http://wiki.openstreetmap.org/wiki/Public_Transport, and I'm not sure of what the current position is as the 'goal posts kept moving!' Some sensible consultation aiming towards a goal we can understand and achieve would be good, because I personally just reached the stage where I made sure the bus stops were in the correct place with the right tags, and left the routes part completed. I can't offer to spend time importing on a line by line basis - I'm currently trying to get Ebola areas mapped in Africa! If I can help in other ways, let me know - it makes sense to me to present the data in a way it can actually be used by someone! Regards Nick (Tallguy) On 31/07/14 15:47, Chris Hill wrote: The NaPTAN data was imported for Hull and East Yorkshire at my request. I quickly realised that the data was of variable quality and resurveyed the ~1300 bus stops in Hull. Having corrected a large percentage of the stops, I informed the Hull council team, at their request, who then ignored me. I would not want any NaPTAN data re-imported in this area unless I was sure the quality has very substantially improved. Some working relationship with the council team who maintain the data would help too. Cheers, Chris, osm user: chillly On 31 July 2014 15:15:18 GMT+01:00, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: Hi, This is a spin off from the recent thread about imports, because I wanted to specifically talk about NaPTAN imports. Having briefly scanned the various wiki pages, I get the impression that the NaPTAN data was imported, once, in 2009. What I can’t see, or haven’t found, is any discussion about how how often this data is updated. NaPTAN (and associated NPTG) is a live data set, and is changing continually as bus stops are brought into use (e.g. new developments) and taken out of service. As I think I have mentioned, one of the reasons that I am now on this group is because of the adoption of OSM by a number of traveline regions, whose members are the very local authorities that create and maintain the NaPTAN data (including Nottingham/Nottinghamshire, since that was mentioned in the earlier thread). We therefore have an interest in making sure that the stop data on OSM is as up to date as the mapping. Is there an appetite within the community to maintain and update this data? And if so, how would we go about it, and how often might it be updated? For the record, the data set is change dated, and deleted records are retained in the data for reference until (eventually) being archived (although even then the stops
Re: [Talk-GB] NaPTAN (stop) import
Many thanks - some interesting viewpoints there. I think it is safe to say that things will have improved from 2009, but also fair to admit that some data is not structured in the way that even I would like. Yorkshire is a particular problem for us. The good thing though is that NaPTAN is downloadable on an authority by authority basis and so we have scope for working through issues relatively local basis and perhaps later picking off authorities for individual auto updates once we've all agreed what that entails. On specifics, it is never going to be the case that NaPTAN will come from OSM. However, I'm keen to identify mismatches - missing stops in Swanley might be TfL infrastructure for example, while stop not present might represent custom and practice stops or virtual points on a hail and ride route. Where we can, we can update data. Looking to the future I am also keen to use OSM for those things that NaPTAN doesn't describe or which there is little will to populate. But that is a whole new discussion for another time. Would anyone who has made edits like to volunteer an area for me to start with? I live in Southend, and have direct contact with SE authorities and indirect contact with SW, EM and EA. Regards Stuart On 31 Jul 2014, at 17:02, Nick Allen nick.allen...@gmail.commailto:nick.allen...@gmail.com wrote: Hi, I would not wish to see a mass import in my area, but I could see some merit in comparing data 'line by line'. I can remember that in the early days (2009?) there were bus stops on the data at the time that NaPTAN was imported. Some were sensibly merged, but some were deleted before the value of merging was realised (I was probably as ignorant of how to sort it out properly in those days, as anyone else, so I don't think a witch hunt will help). Since then, I've made many cycle surveys in my area, and have updated NaPTAN stops to the extent that anything I have edited in the past is now in the right place the tags will be correct. However, some of the imported data was so inaccurate, that it was difficult to tell whether it should be moved North, South East or West, to where the nearest actual stop was. As a result of this, it is quite possible that there are stops shown in the right place with the correct tags concerning shelters, benches, tactile paving, name of stop, timetables or bus route references displayed, etc, but added to a NaPTAN reference which new data would show to actually be elsewhere. The only way of improving this would be a line by line comparison, with perhaps the transfer of a reference from new NaPTAN data, to the existing OSM data. If I appear in the history of the bus stop (Ctrl+h using JOSM), then there is a bus stop in that exact location. I suspect that this is true of many stops elsewhere, so some cautionary line by line merging is going to be needed. I use the NOVAM - viewer from http://b3e.net/novam/ to check what needs doing, (Birmingham colour scheme suits my purpose). If you use this zoom into Swanley, Kent (just off J3 of M25), you will find there are several stops which I have created, for which there is no NaPTAN data in the current database. It would obviously be sensible to add that data if you have it - just don't move the stop or change the other tags I've added please. You'll also see that I have marked some bus stops as 'not physically present'.. I think most mappers have worked from http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data (history shows this was last updated in 2011 with most of the updates from 2009), but there are more recent articles at http://wiki.openstreetmap.org/wiki/Public_Transport, and I'm not sure of what the current position is as the 'goal posts kept moving!' Some sensible consultation aiming towards a goal we can understand and achieve would be good, because I personally just reached the stage where I made sure the bus stops were in the correct place with the right tags, and left the routes part completed. I can't offer to spend time importing on a line by line basis - I'm currently trying to get Ebola areas mapped in Africa! If I can help in other ways, let me know - it makes sense to me to present the data in a way it can actually be used by someone! Regards Nick (Tallguy) On 31/07/14 15:47, Chris Hill wrote: The NaPTAN data was imported for Hull and East Yorkshire at my request. I quickly realised that the data was of variable quality and resurveyed the ~1300 bus stops in Hull. Having corrected a large percentage of the stops, I informed the Hull council team, at their request, who then ignored me. I would not want any NaPTAN data re-imported in this area unless I was sure the quality has very substantially improved. Some working relationship with the council team who maintain the data would help too. Cheers, Chris, osm user: chillly On 31 July 2014 15:15:18 GMT+01:00, Stuart Reynolds
Re: [Talk-GB] NaPTAN (stop) import
Stuart, If you would like to start in Swanley, that would be fine with me. I don't know about my neighbouring mappers, but I certainly use tools to check what edits are taking place in areas I have an interest. I strongly suggest you keep the area small, and use my area as a guinea pig, perhaps detailing what your aim is on a wiki page. As you've gathered 'mass imports' are something we all dread as we've put so much time effort into producing something useful, and we don't want to see it trampled. If you've got the route data available to you, you'll probably find that most of the 'not physically present' relate to the route now going elsewhere, which is why I've got bus stops elsewhere without NaPTAN data. It does get more complicated as I have two or more authorities involved. It's good to talk - I'll let you know if I'm unhappy you're welcome to contact me if you have a query. Regards Good luck. Nick (Tallguy) On 31/07/14 17:41, Stuart Reynolds wrote: Many thanks - some interesting viewpoints there. I think it is safe to say that things will have improved from 2009, but also fair to admit that some data is not structured in the way that even I would like. Yorkshire is a particular problem for us. The good thing though is that NaPTAN is downloadable on an authority by authority basis and so we have scope for working through issues relatively local basis and perhaps later picking off authorities for individual auto updates once we've all agreed what that entails. On specifics, it is never going to be the case that NaPTAN will come from OSM. However, I'm keen to identify mismatches - missing stops in Swanley might be TfL infrastructure for example, while stop not present might represent custom and practice stops or virtual points on a hail and ride route. Where we can, we can update data. Looking to the future I am also keen to use OSM for those things that NaPTAN doesn't describe or which there is little will to populate. But that is a whole new discussion for another time. Would anyone who has made edits like to volunteer an area for me to start with? I live in Southend, and have direct contact with SE authorities and indirect contact with SW, EM and EA. Regards Stuart On 31 Jul 2014, at 17:02, Nick Allen nick.allen...@gmail.com mailto:nick.allen...@gmail.com wrote: Hi, I would not wish to see a mass import in my area, but I could see some merit in comparing data 'line by line'. I can remember that in the early days (2009?) there were bus stops on the data at the time that NaPTAN was imported. Some were sensibly merged, but some were deleted before the value of merging was realised (I was probably as ignorant of how to sort it out properly in those days, as anyone else, so I don't think a witch hunt will help). Since then, I've made many cycle surveys in my area, and have updated NaPTAN stops to the extent that anything I have edited in the past is now in the right place the tags will be correct. However, some of the imported data was so inaccurate, that it was difficult to tell whether it should be moved North, South East or West, to where the nearest actual stop was. As a result of this, it is quite possible that there are stops shown in the right place with the correct tags concerning shelters, benches, tactile paving, name of stop, timetables or bus route references displayed, etc, but added to a NaPTAN reference which new data would show to actually be elsewhere. The only way of improving this would be a line by line comparison, with perhaps the transfer of a reference from new NaPTAN data, to the existing OSM data. If I appear in the history of the bus stop (Ctrl+h using JOSM), then there is a bus stop in that exact location. I suspect that this is true of many stops elsewhere, so some cautionary line by line merging is going to be needed. I use the NOVAM - viewer from http://b3e.net/novam/ to check what needs doing, (Birmingham colour scheme suits my purpose). If you use this zoom into Swanley, Kent (just off J3 of M25), you will find there are several stops which I have created, for which there is no NaPTAN data in the current database. It would obviously be sensible to add that data if you have it - just don't move the stop or change the other tags I've added please. You'll also see that I have marked some bus stops as 'not physically present'.. I think most mappers have worked from http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data (history shows this was last updated in 2011 with most of the updates from 2009), but there are more recent articles at http://wiki.openstreetmap.org/wiki/Public_Transport, and I'm not sure of what the current position is as the 'goal posts kept moving!' Some sensible consultation aiming towards a goal we can understand and achieve would be good, because I personally just reached the stage where I made sure the bus stops were
Re: [Talk-GB] NaPTAN (stop) import
On 31/07/14 17:41, Stuart Reynolds wrote: Many thanks - some interesting viewpoints there. I think it is safe to say that things will have improved from 2009, but also fair to admit that some data is not structured in the way that even I would like. Yorkshire is a particular problem for us. East Yorkshire council seem to believe open data is casting pearls before swine. Hull City council have made noises for years about open data and do precisely nothing. The good thing though is that NaPTAN is downloadable on an authority by authority basis and so we have scope for working through issues relatively local basis and perhaps later picking off authorities for individual auto updates once we've all agreed what that entails. On specifics, it is never going to be the case that NaPTAN will come from OSM. Never is a very, very long time. I suspect OSM data (with quality public transport data) will be around long after NaPTAN has disappeared in a puff of bureaucratic smoke :-) However, I'm keen to identify mismatches - missing stops in Swanley might be TfL infrastructure for example, while stop not present might represent custom and practice stops or virtual points on a hail and ride route. Where we can, we can update data. Using NaPTAN updates as I use OS Locator data, i.e. a list of places to survey, would be useful. To do that an overlay with the updates on would be useful. If we find that the updates are repeatedly good quality then more of an import might be worth looking at. At the moment any direct imports of NaPTAN data would get a veto from me based on the only evidence we have at the moment: poor quality. Looking to the future I am also keen to use OSM for those things that NaPTAN doesn't describe or which there is little will to populate. But that is a whole new discussion for another time. Would anyone who has made edits like to volunteer an area for me to start with? I live in Southend, and have direct contact with SE authorities and indirect contact with SW, EM and EA. I could help create an overlay, though the Novam viewer was very helpful when I was surveying the stops in Hull (and nearly 800 in E. Yorsk before I gave up). Maybe the Novam viewer http://b3e.net/novam/ could be extended to show an updates overlay. I'd be particularly interested if any council has used the improved OSM data to bring their feed into NaPTAN up to scratch, and if not why not? -- Cheers, Chris user: chillly ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
On 31/07/14 18:31, Chris Hill wrote: I'd be particularly interested if any council has used the improved OSM data to bring their feed into NaPTAN up to scratch, and if not why not? As the naptan data has a nice unique identifier then it should be possible to do a clean compare of what is on OSM and the raw naptan data? If the location of a node is distance from the raw data, this can be tagged, and if other fields have updated then this data can be updated on OSM. Import wise, if a node already exists, then it would be dropped from a new import. This data really is a nice example that could be developed with data management tools that would then be usable with other data sets such as lamp posts, post boxes, telephone distribution cabinets and the like? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Probably not a convenient area for you, but I added bus stops in the Glasgow area from NAPTAN data a few years back, manually merging in with existing data and surveying those where it wasn't clear (and flagging a few cases that I didn't get a chance to survey). However it took quite a bit longer than I had anticipated soI didn't do any further areas. If you were to develop some way to compare NAPTAN OSM by reference/location, and then marking as close matches to existing (needing updated or not) or possible conflicts to be survey, etc, would be interesting. But has been noted, this probably has to be reviewed on a stop-by-stop basis, as there are so many potential issues with both the NAPTAN and OSM data. Cheers, Donald On 31 July 2014 19:18, Lester Caine les...@lsces.co.uk wrote: On 31/07/14 18:31, Chris Hill wrote: I'd be particularly interested if any council has used the improved OSM data to bring their feed into NaPTAN up to scratch, and if not why not? As the naptan data has a nice unique identifier then it should be possible to do a clean compare of what is on OSM and the raw naptan data? If the location of a node is distance from the raw data, this can be tagged, and if other fields have updated then this data can be updated on OSM. Import wise, if a node already exists, then it would be dropped from a new import. This data really is a nice example that could be developed with data management tools that would then be usable with other data sets such as lamp posts, post boxes, telephone distribution cabinets and the like? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb -- Donald Noble http://drnoble.co.uk - http://flickr.com/photos/drnoble ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
On 31/07/14 17:01, Nick Allen wrote: actual stop was. As a result of this, it is quite possible that there are stops shown in the right place with the correct tags concerning shelters, benches, tactile paving, name of stop, timetables or bus route references displayed, etc, but added to a NaPTAN reference which new data would show to actually be elsewhere. I've certainly found a lot of misplaced NaPTAN nodes, and ones where the logical stop has moved. The only way of improving this would be a line by line comparison, with perhaps the transfer of a reference from new NaPTAN data, to the existing OSM data. If I appear in the history of the bus stop (Ctrl+h using JOSM), then there is a bus stop in that exact location. I suspect that this is true of many stops elsewhere, so some cautionary line by line merging is going to be needed. The OSM history mechanism is flawed in that it can only track one side of a merge (more generally, detaching a node from a way without creating a new node can be difficult, although not many NaPTAN nodes have been accidentally attached to ways). several stops which I have created, for which there is no NaPTAN data in the current database. A small proportion of NaPTAN data has gone missing either through personal mapping (people don't want the stops cluttering their map) or because people decided that the stop wasn't present, but never read the bit about leaving the node, marking physically_present=no and not a bus_stop. I've definitely seen the former and there are cases where the latter is the most obvious explanation. One of the things I find missing from the process is actually an audit against the original import, to recover those cases - or to detect deliberate damage to the imported information. Another issue with NaPTAN is stop area names. There is nothing on the ground to identify these, but the actual stop names change relatively frequently as landmarks come and go. Often stops within a stop area have different names. At the moment, this means that as you zoom out of the transport map, the name can change to one that is no longer/not used on the ground. I don't know if a re-merge would help with that, or whether there is a more fundamental problem with stop area names. On the more general issue of maintaining bulk data, I've found I've inherited several high streets where someone takes a photograph, maps it six months later, and never returns to check changes, something which really needs doing at least every three months. I have taken on maintaining those within a couple of kilometres, but I'm aware of other ones which I don't visit often enough to recognize changes, or detect errors in the original mapping. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
I have recently resurveyed all the bus stops in the centre of Nottingham (NG1 area) and quite a few changes have occurred since the NaPTAN import: most often changes to stop names but some more complicated changes to stop layouts too. I think the quality of the NaPTAN data must vary quite a lot between different areas, because I have generally found the position and names of stops in Nottingham to be accurate, other than the inevitable changes that have occurred since the import took place. I do not believe the stop areas should have been imported at all because they are not verifiable on the ground. Also, I am often unable to find much logic in the groupings other than the stops are relatively close together, so I don't think they are really useful. Like others I wouldn't support an automated update. Certainly in areas I've recently mapped, I believe this would be more likely to degrade rather than improve the data. However, it would be great to have better tools to check for discrepancies between the current NaPTAN data and the bus stops in OSM, including an easy way to merge the data on a stop-by-stop basis. Perhaps the NOVAM-Viewer could be extended for this purpose (as others have already suggested). The NaPTAN data was never imported in Derbyshire. When I was systematically surveying all the roads in Erewash (south Derbyshire), I assumed the import was going to occur at some point soon, so I didn't bother recording any bus stops because I wanted to avoid having to deal with duplicates later. I regret not doing so now. I have added them in some of this areas since, but there is still a lot to do. In these areas, where the data was not imported, it would be very useful to have an easy way to import the data over small areas, where local mappers want it to take place. Regards, Will ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
