Hi
Can I introduce myself as a new member of the talk-transit list (and completely new to the OSM community). For my sins I have been responsible for the development and implementation of the NaPTAN database within the UK and also for chairing the European standards work on IFOPT which Peter Miller has referred to in earlier posts (and which leans heavily on NaPTAN for some of its core functions). I am also the project manager for traveline south east - and in that role I am heavily involved in the use of NaPTAN data within a large public transport information system. I have spent a couple of hours this afternoon skimming all the posts on the talk-transit list to date . and whilst I have some thoughts about some of the earlier discussions, it is probably best that I don't reopen discussions on them right now. I can, however, respond to questions about what is intended with aspects of NaPTAN, where there are weaknesses in the data, etc etc. As Peter has commented, the database is a distributed one compiled and maintained by more than 140 local transport authorities over the past 7 or 8 years (but quite a lot of data in NaPTAN was inherited from legacy databases). Some parts of the country use certain aspects of the database more extensively than others - and that is reflected in the quality of the data being different between areas. Some are more consistent with the latest guidelines, others are less so. I can also suggest some pragmatic ways of using the data, based on my experience of running traveline south east for almost 10 years - how to make a purse out of a sow's ear, maybe . but I think the pragmatic approach has generated very usable public-facing information. I appreciate that there are some differences of opinion about what OSM is wanting to do with bus stop information - and whether it should include "service" information. As Peter Miller has aluded to in previous postings the NaPTAN database is solely a database of access points - and this is completely separate from the "route and timetable" data which is handled quite separately (albeit the latter is referenced to the former). The complexity of routes and timetables, the frequency of changes in them, and the exceptional arrangements for public holidays and other special situations, make the nature of this data very different from that which can be mapped - and in my view (and in the view of the data standards) it forms a very separate layer of information which might be summarised by designating each "route" (but is it a once-a month market service in a rural area, or a high-frequency urban service running seven days a week? - and is it a close variant of another "route", maybe with a similar number, maybe provided by a different operator, etc). I would counsel strongly against getting into the service information aspect of public transport at this stage - but focus instead on the infrastructure that is needed, and to which any route and schedule information will be linked. Incidentally we find from experience that most bus services can be routed on maps using a shortest-route algorithm following normal roads between bus stops - the need for additional waypoints is quite rare for normal stopping services, and even for most limited-stop services. Buses really do normally find the shortest route between their stops! That's enough for my opening post . I look forward to contributing to this project as a public transport data specialist, and I look forward to learning in the process about the world of mapping and OSM in particular. Best wishes to you all Roger
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
