Re: [Talk-transit] Mapping public transport network in Port au Prince
On 1 September 2011 06:03, Sébastien Pierrel sebastien.pier...@gmail.comwrote: Hello list, I'm getting the local mappers of Haiti to map the taptap routes in Port au Prince. Has anyone already mapped the transit network of a similar country? There's a brief mention of shared taxis in the wikihttp://wiki.openstreetmap.org/wiki/Shared_transportbut not very helpful. We're considering to tag relations with the following tags: type=route route=bus bus=share_taxi name=* (example http://www.openstreetmap.org/browse/relation/1734930) I found 2000+ instances of the key shared_taxi and 250 for share_taxi but I couldn't locate them. What tools would you recommend to extract relations? Eventually, we want to work on this data with qgis/postgis. I have done some work on the sharetaxi article in Wikipedia some time back, but that got massively messed some time back ( http://en.wikipedia.org/wiki/Share_taxi). My understanding is that these services vary from 'fixed route-variable times' through to completely random routes. Another question is if the services stop anywhere on the route or only at fixed points or possibly there are some fixed points and then anywhere on the route in addition. If there are fixed points then these can be added as stops. In the UK we have 'hail-and-ride' which are linear sections of route where the vehicle will stop which are treated like bus stops. We also have share taxi 'demand responsive' services and can defined 'flexible zones' as polygons where the service will pick people up from anywhere within the zone. These can then all treated as being 'bus stops'. It is still hard to describe the services themselves. Fixed routes can be added a bus routes (as in your example). If not then you may be more on your own! Here is a diagram and some modeling details from the UK schema if that helps. http://www.dft.gov.uk/transxchange/schema/2.0/examples/flexible/ I will be very interested to hear how you get on with this one. Regards, Peter Miller ITO World Ltd Feedback of all sort is much appreciated. Cheers, /Seb. ___ 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] New administrator and comments/questions on the new public transport schema
On 2 May 2011 05:44, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Hi Peter On 05/01/2011 10:49 AM, Peter Miller wrote: Just to say that I have just set Stefan Bethke up as an admin. There are now two administrators, myself and Stefan which is much better. I would like to also say how impressed I am with the new public transport schema which is proving to be very useful for modeling the main railway stations in London. I have also been working on the OSM wiki over the past week providing more detail about this schema on more pages. Here are a few pages that I have pretty much finished. http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation Thanks for your work on the wiki! No problem. I plan to keep going a while on the above. One question I do have is about how to tag the boundary of a station. For some purposes it seems to be important to have a node representing the station, and a node is also useful because it can be positioned over the main concourse or at any other appropriate location as opposed to being in the centre of the boundary which is often in the tracks/platform area. This begs the question about how to tag the area of the station. On normal maps a stop_area should not be drawn. So there is another possibility to draw the boundary (if alreay supported by renderers): public_transport=station area=yes If you have a building this should be tagged with: public_transport=station building=yes Thanks, but that doesn't answer how one avoids getting two station names rendered, one from the node positioned at exactly where one wants it and which can be used in route relations and another from the centre of the area? Take Paddington Station in London as an example. Here is the overarching stop_area for all the elements of public transport associated in some way with Paddington Station (this including the mainline station, two underground stations and a bunch of bus stops). http://www.openstreetmap.org/browse/relation/204439 Here is the stop area for Paddington mainline station itself (note that there is a node with role 'station' and the outline of the station with the role 'building'). Incidentally I am also starting to add footways within the station to the relation with the role 'access'. http://www.openstreetmap.org/browse/relation/1562706 Here is the station node. Note the 'note' that reads DO NOT delete as route relations cannot have the building (area) as a 'stop'. http://www.openstreetmap.org/browse/node/558489676 And here is the boundary of the station from which I removed the 'railway=station' tag and added a note that reads please do not add a railway=station tag - there is already a node performing this function. http://www.openstreetmap.org/browse/way/8877521/history I am not 100% comfortable with this approach because without a 'railway=station' tag the area is rendered as any other building rather than as a station. However.. if one adds the 'railway=station' tag to the building outline then one gets another instance of railway station rendered on the map. I know that we shouldn't tag to suit the renderer - this is more a question about how we want to tag things unambiguously and what we want the map to look like and therefore what we want the rendered to do! What I would recommend in your examples: Add type=public_transport public_transport=stop_area to all the relations. I agree with you. Some of those stop areas are older and are not tagged correctly and I missed the type=public_transport off the new ones. In earlier days during the RFC of the proposal there was a public_transport=stop_area_group what exactly fitted your needs for your http://www.openstreetmap.org/browse/relation/204439 During the discussion we removed this from the proposal and we saied one should leave away such a relation as a whole. I personally still add such relations and do not remove them. Have a look at the following example: http://www.openstreetmap.org/browse/relation/1279034 This is the stop_area_group relation containing ONLY other stop_areas. One for railway and the other for the bus. The relations for the railway also includes parkride and the stations building (http://www.openstreetmap.org/browse/way/82160292) The other realation for the bus stations contains a station tagged with area=yes to show the outline of the bus station ( http://www.openstreetmap.org/browse/way/83334745). A railway=station is not used anymore and has been replaced by public_transport=station. Actually it does not get rendered completely, but I think this is only a question of time until the renderers are updated. Thanks for the above. The professional European transport model (transmodel) allows
[Talk-transit] New administrator and comments/questions on the new public transport schema
Just to say that I have just set Stefan Bethke up as an admin. There are now two administrators, myself and Stefan which is much better. I would like to also say how impressed I am with the new public transport schema which is proving to be very useful for modeling the main railway stations in London. I have also been working on the OSM wiki over the past week providing more detail about this schema on more pages. Here are a few pages that I have pretty much finished. http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation One question I do have is about how to tag the boundary of a station. For some purposes it seems to be important to have a node representing the station, and a node is also useful because it can be positioned over the main concourse or at any other appropriate location as opposed to being in the centre of the boundary which is often in the tracks/platform area. This begs the question about how to tag the area of the station. Take Paddington Station in London as an example. Here is the overarching stop_area for all the elements of public transport associated in some way with Paddington Station (this including the mainline station, two underground stations and a bunch of bus stops). http://www.openstreetmap.org/browse/relation/204439 Here is the stop area for Paddington mainline station itself (note that there is a node with role 'station' and the outline of the station with the role 'building'). Incidentally I am also starting to add footways within the station to the relation with the role 'access'. http://www.openstreetmap.org/browse/relation/1562706 Here is the station node. Note the 'note' that reads DO NOT delete as route relations cannot have the building (area) as a 'stop'. http://www.openstreetmap.org/browse/node/558489676 And here is the boundary of the station from which I removed the 'railway=station' tag and added a note that reads please do not add a railway=station tag - there is already a node performing this function. http://www.openstreetmap.org/browse/way/8877521/history I am not 100% comfortable with this approach because without a 'railway=station' tag the area is rendered as any other building rather than as a station. However.. if one adds the 'railway=station' tag to the building outline then one gets another instance of railway station rendered on the map. I know that we shouldn't tag to suit the renderer - this is more a question about how we want to tag things unambiguously and what we want the map to look like and therefore what we want the rendered to do! Regards, Peter Miller ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Additional administrators needed please
I have very belatedly noticed a load of posts to talk-transit needing moderation. I have been through them all discarding the dross and releasing the valid ones. Many apologies for people who's posts got held up. Can we have some offers of additional administrators for this list as I am the only one at present. The only duty is to review 'first posts' and to allow posts by real people and to deny spam. Can we have two volunteers please? Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Spam] Re: child relations in type=route, route=bus
On 2 October 2010 05:28, Michał Borsuk michal.bor...@gmail.com wrote: 2010/10/1 Jo winfi...@gmail.com [...] I'm pretty sure that if one gets the PT companies to share their data, it's not going to be in there with child relations. Usually (e.g. HaFas) timetables consist of a number of routes, and those are very detailed, each direction is mapped separately, and e.g. if a bus ends its day not at the terminus, then it's yet another route. This approach is easier to store in a database, but is in my opinion that one step too detailed for humans to manage in OSM. It would apparently make sense to make a collection named line 123, and store child routes withing that collection, but as of today there is no efficient way to deal with this. Transmodel breaks public transport routes down into the following: Line: (a service with a single service number - 13, X3, 200 etc) Route: A physical path through the network (on tarmac or rails normally) Service Pattern: A sequence of Stop Points called at in turn with an associated Route (a line will normally have 2 or more Service Patterns) Timing Pattern: A set of timing for a particular Service Pattern (service patterns can have multiple timing patterns) Vehicle Journey: A departure time and set of dates/days with an assoicated Timing Pattern (A timing pattern can have mulutiple Vehicle Journeys). There is also a way of grouping Service Patterns into Directions and methods to deal with trains that divide and join (ie the front and back are eventually heading for different places). Many other tedious exceptions can also be modeled. More here for brave people http://en.wikipedia.org/wiki/Transmodel Personally I suggest that we limit the transit information in OSM to the minimum and leave the detail in GTFS. Personally I would like someone to create a bus-map application using OSM together with GTFS schedules - doing that would remove a lot of the pressure to model public transport in OSM. I do suggest that we add bus stops to OSM as they are physical features, the rest to my mind belongs in the schedules file. To achieve that we would need some solid mapping from the bus stops in GTFS to their features in OSM. There are many GTFS files available already here: http://www.gtfs-data-exchange.com/agencies Regards, Peter -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ 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] Proposed additional tags for bus stops and animport of San Fracisco data
On 15 Jul 2010, at 11:21, Joe Hughes wrote: Peter, I think it would be helpful to look at GTFS data from a few diverse providers when testing ideas about imports, as data tends to reflect the historical practices of the particular agency in ways like naming patterns, which details are present, etc. There's a great deal of GTFS data on gtfs-data-exchange.com, but I'd recommend, say, TriMet and Port Authority of Allegheny County in addition to the SFMTA data that you're already examining. As you mentioned, the street and directional information should be optional, as there are boundary cases like stops in shopping centre parking lots, large station complexes, and underground private ways which might make it difficult to provide reasonable street/direction values. By and large I could see how that information would be useful for snapping stop points to varying road network data sets (setting aside the issue of how to deal with stop points on traffic islands in the centre of the road). In general, though, we should be careful not to depend too much on things which are likely to be available from source data in only some parts of the world. (Consider places where not all roads have agreed-upon names.) Thanks for your continued efforts on this issue! Thanks Joe, We are going taking a look at Chicago data next as I am going to be there shortly and we will then look at the others you recommend to see what will work in different places. Btw, if anyone has any contacts in Chicago then do let me know. In general in osm there should nearly always be a highway way associated with on-street stops which is used by the vehicle and there should also be a node where people wait for the vehicle by the way. Where the highway doesn't have a name, or has a name that is not unique then I would suggest that a relation is used to bind the stop to the way. Some bus bays don't usefully have a direction - if they are reverse out bus bays for example, and also in some other situations but these are generally not considered to be 'on-street'. With reference to the proposal to define the use of the bus stop by the services that use it I think one is in danger of getting into circular definitions which get confusing when mistakes are make. Which is wrong, the stop, or the service? In the UK it has been very useful to first settle which side of the road the bus stops are on using the bearing and then to ensure that the correct services are connected to them and sort them out any cross wiring which might mean moving some services to the other stop of the pair. Re stops in the middle of the road, the rule at the ordnance survey in the UK is that a road should be represented as two parallel ways where there is a central barrier, divider or structure such as a bus stop in the middle. I am not sure how a bus stop would be described in NaPTAN, possibly there would be two nodes, one for each direction or possibly just one with no bearing. As you say Joe, lets review many different systems and see what will work in different places. Regards, Peter Cheers, Joe On Thu, Jul 15, 2010 at 8:53 AM, Peter Miller peter.mil...@itoworld.com wrote: I have been looking at the GTFS data for San Francisco over the past few days and considering how one could do a bus stops/tram stop import for the place and more generally for the GTFS data. However... in the process I want to be be 100% clear which road the stop serves and in which direction to improve the quality of map rendering which is not possible with the current bus stop tagging. Here is the general bus stop positioning problem for bus stops in osm as I see it. The osm community has agreed to place the bus stop beside the road at the place where people wait which is good, however if that stop is close to a junction or to two roads that run parallel then it is not clear which road it serves. This is a problem when it comes to creating clear map rendering where one wants to snap the stop to correct side of the correct road and not left them floating as they are currently. An additional complication comes when one wants to position the symbol correctly when the road widths on the rendering are exaggerated requiring the node to be nudged sideways for it to not appear within the junction itself. I propose that we formalise a couple of NaPTAN tags into the main bus stop schema and try these with a SF import. 'Street' tag: to indicate the name of the associated street 'Bearing' tag: to indicate the direction in which vehicles leave the stop, to be clear this is the immediate direction taken, not a sight- light to the next bus stop. NaPTAN uses compass points N, NE E etc'. Here are some examples of where the addition tags are useful. In the first case it is not clear without the street tag which of two parallel streets are served
Re: [Talk-transit] Proposed additional tags for bus stops and animport of San Fracisco data
On 15 Jul 2010, at 11:21, Joe Hughes wrote: Peter, I think it would be helpful to look at GTFS data from a few diverse providers when testing ideas about imports, as data tends to reflect the historical practices of the particular agency in ways like naming patterns, which details are present, etc. There's a great deal of GTFS data on gtfs-data-exchange.com, but I'd recommend, say, TriMet and Port Authority of Allegheny County in addition to the SFMTA data that you're already examining. As you mentioned, the street and directional information should be optional, as there are boundary cases like stops in shopping centre parking lots, large station complexes, and underground private ways which might make it difficult to provide reasonable street/direction values. By and large I could see how that information would be useful for snapping stop points to varying road network data sets (setting aside the issue of how to deal with stop points on traffic islands in the centre of the road). In general, though, we should be careful not to depend too much on things which are likely to be available from source data in only some parts of the world. (Consider places where not all roads have agreed-upon names.) Thanks for your continued efforts on this issue! It is probably worth clarifying that in osm the only times that one would need the additional bearing or street tags is when there is an element of doubt about which the road is the correct one due to the bus stop being close to a junction or being directly between two close parallel roads. By contrast as a gtfs data supplier where the final road datasets unknown then it would be advisable to always provide a bearing for on- street stops in case the location of the roads in the roads dataset are offset from the position of the stops in the gtfs dataset due to accumulated positional errors resulting in the stops being positioned on the wrong side of the road. Regards, Peter Cheers, Joe On Thu, Jul 15, 2010 at 8:53 AM, Peter Miller peter.mil...@itoworld.com wrote: I have been looking at the GTFS data for San Francisco over the past few days and considering how one could do a bus stops/tram stop import for the place and more generally for the GTFS data. However... in the process I want to be be 100% clear which road the stop serves and in which direction to improve the quality of map rendering which is not possible with the current bus stop tagging. Here is the general bus stop positioning problem for bus stops in osm as I see it. The osm community has agreed to place the bus stop beside the road at the place where people wait which is good, however if that stop is close to a junction or to two roads that run parallel then it is not clear which road it serves. This is a problem when it comes to creating clear map rendering where one wants to snap the stop to correct side of the correct road and not left them floating as they are currently. An additional complication comes when one wants to position the symbol correctly when the road widths on the rendering are exaggerated requiring the node to be nudged sideways for it to not appear within the junction itself. I propose that we formalise a couple of NaPTAN tags into the main bus stop schema and try these with a SF import. 'Street' tag: to indicate the name of the associated street 'Bearing' tag: to indicate the direction in which vehicles leave the stop, to be clear this is the immediate direction taken, not a sight- light to the next bus stop. NaPTAN uses compass points N, NE E etc'. Here are some examples of where the addition tags are useful. In the first case it is not clear without the street tag which of two parallel streets are served, and in the second it is not clear which of three nearby streets are served. http://www.openstreetmap.org/browse/node/816289382 http://www.openstreetmap.org/browse/node/817535874 With these tags we should then be able to do an automatically import. Here are some initial observations on the data. In general the data is good except for a few places where there appear to be duplicates for some stops in similar but not identical locations. This would require a manual clean-up of some busy streets following the import. Stops on either side of the road have the same name. This is not a problem if the bearing field is set correctly from the schedule data - setting the bearing is non-trivial but can be done. The stop naming is 'street street' where the first street name is for the street that the stop serves. This will allow the stops to have the 'street' field set. Sometimes the location of the stop is wrong and places the stop on the other side of the road. This can be sorted manually afterwards given that the bearing field and street fields will show what is actually required. There is a licensing issue for the SF data
[Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
I have been looking at the GTFS data for San Francisco over the past few days and considering how one could do a bus stops/tram stop import for the place and more generally for the GTFS data. However... in the process I want to be be 100% clear which road the stop serves and in which direction to improve the quality of map rendering which is not possible with the current bus stop tagging. Here is the general bus stop positioning problem for bus stops in osm as I see it. The osm community has agreed to place the bus stop beside the road at the place where people wait which is good, however if that stop is close to a junction or to two roads that run parallel then it is not clear which road it serves. This is a problem when it comes to creating clear map rendering where one wants to snap the stop to correct side of the correct road and not left them floating as they are currently. An additional complication comes when one wants to position the symbol correctly when the road widths on the rendering are exaggerated requiring the node to be nudged sideways for it to not appear within the junction itself. I propose that we formalise a couple of NaPTAN tags into the main bus stop schema and try these with a SF import. 'Street' tag: to indicate the name of the associated street 'Bearing' tag: to indicate the direction in which vehicles leave the stop, to be clear this is the immediate direction taken, not a sight- light to the next bus stop. NaPTAN uses compass points N, NE E etc'. Here are some examples of where the addition tags are useful. In the first case it is not clear without the street tag which of two parallel streets are served, and in the second it is not clear which of three nearby streets are served. http://www.openstreetmap.org/browse/node/816289382 http://www.openstreetmap.org/browse/node/817535874 With these tags we should then be able to do an automatically import. Here are some initial observations on the data. In general the data is good except for a few places where there appear to be duplicates for some stops in similar but not identical locations. This would require a manual clean-up of some busy streets following the import. Stops on either side of the road have the same name. This is not a problem if the bearing field is set correctly from the schedule data - setting the bearing is non-trivial but can be done. The stop naming is 'street street' where the first street name is for the street that the stop serves. This will allow the stops to have the 'street' field set. Sometimes the location of the stop is wrong and places the stop on the other side of the road. This can be sorted manually afterwards given that the bearing field and street fields will show what is actually required. There is a licensing issue for the SF data which is currently only available on a 'limited, and revocable license' which 'does not include any right to sublicense'. http://www.sfmta.com/cms/asite/transitdata.htm Clearly this is not sufficient as it stands and we would need to get approval for what we wanted prior to doing the actual work. Any thoughts on the tagging proposal? Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed additional tags for bus stops and animport of San Fracisco data
On 15 Jul 2010, at 08:59, Michał Borsuk wrote: On 15.07.2010 09:53, Peter Miller wrote: This is a problem when it comes to creating clear map rendering where one wants to snap the stop to correct side of the correct road and not left them floating as they are currently. An additional complication comes when one wants to position the symbol correctly when the road widths on the rendering are exaggerated requiring the node to be nudged sideways for it to not appear within the junction itself. I propose that we formalise a couple of NaPTAN tags into the main bus stop schema and try these with a SF import. As far as I know, the current trend is to add the bus stop to the lines (relations) which stop there. http://www.openstreetmap.org/browse/node/354589964 Does that fit your situation? Good point, but it only helps when the relations exist - and that requires someone to maintain the relations which is a problem and don't always happen. It is still then difficult to decide which road to put the stop against on the rendering and also where exactly to route a person on foot to in order to the bus stop. Personally I don't like the idea of requiring routes in order to establish something physical and this is a solution to that problem. Needless to say this is not a mandatory field! Peter Regards, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ 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] GTFS compatibility
Reviewing the San Francisco data a little more has made me think about the modelling of stations in GTFS. At the Market St/8th Street junction there are buses, a surface tram and a underground metro. The GTFS feed has the following details for stops and services from them: Metro Civic Center Station/Downtn: L, J, N, S, K, T Metro Civic Center Station/Outbd): L, J, N, S, K, T Also some surface stops A 'Market St 8th St' with: L-OWL, N-OWL, K-OWL, T-OWL, M-OWL, F, 6, 9, 9L, 21, 71, 71L A 'Market St Hyde St' with: L-OWL, N-OWL, K-OWL, T-OWL, M-OWL, F, 6, 9, 9L, 71, 71L A 'Market St Hyde St' with: 19, 21 And an '8th St Market St' with: 19 I would suggest that the first two are being treated as metro platforms and that the rest are surface bus stops/tram stops. As such it would be neat if the name of the metro platforms matched the platform names not the station with a suffix. According to osm there are four entrances. I note that Google Maps shows only two features, a metro station listing 'Light rail from this station' (which includes the F which is actual a surface route) and a single bus stop feature listing everything else. This is not a bad representation but given the level of detail on google maps with its building outlines and land parcels it would be good to be able to model public transit in more detail. That detail could either be in GTFS or in osm or both. I would suggest that GTFS includes a feature called 'station entrance' to complete the model and that the standard recommends that stops are created for each platform. I note that the osm data has the four station entrances (which do not currently render) but not the station itself or the platforms. There is a route relation for bus service 7 on Market St but there isn't a 7 in GTFS and there are no route relations for the other services, ie 6,L,21 etc. All in all we are still in a bit of a muddle! Personally I think osm should concentrate on the physical infrastructure in osm and that GTFS should ensure there is a stable ID to connect the Stops into this physical osm model and hold all the service details. Google will no doubt sort out their own physical models or start using osm ;) I wonder if http://www.öpnvkarte.de could work directly from GTFS. Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS compatibility
On 13 Jul 2010, at 20:22, Joe Hughes wrote: Hi Peter, Thanks for digging into this issue. I think that your goals of improving the precision and identifier-stability of existing open transport data are good ones. The question is then: how and where can the OSM community apply leverage to help make this happen? Thanks for responding Joe. I think The OSM can help by building great physical models of the fixed infrastructure. The most useful bit required from the Transit Agency is then a good fixed ID to associate schedules to the platforms/Stop Points that they are referring to. If they don't provide a good ID then some technical matching might be possible using the name and the lat/long of the stop as a signature for the stop. At the end of the day, the people that you want to influence are the people that create and maintain the data on the agency side. In many cases, when they create their exports, they're looking for the minimal transformation that they can make between their existing databases and the export format, such that the data looks decent in consuming applications. Agreed. We will mention this to agencies when we talk to them. Clearly better information does create a better experience though. Given this, I'd posit that you'd have a much greater effect on data exporting practices by building an OSM-based transport renderer that makes a bad-looking rendering when the input data has the characteristics you mentioned (i.e. stops on opposite sides of the street represented by a single logical stop in the data). I suspect that this would be much more meaningful to agency folks than an abstract recommendation in a spec document. Given the success of ITO's visualizations, I expect that you have a deep understanding of how well the visual approach can work. Thanks! We are already able to use such data where it exists - for example on this map which uses the bearing and street name in NaPTAN to snap stops to the correct roads: http://www.flickr.com/photos/peterito/2102416239/sizes/o/in/pool-559...@n22/ We are creating some tools to visualise GTFS content on an OSM background which we hope will be useful. More details in soon. As for the potential new fields you mentioned, I recommend proposing them to the community on the gtfs-changes list; some of the things you've mentioned are already under discussion, and merely lack willing participants for an end-to-end test of the the features to verify that they work as intended when used with real data. Fixed Stop IDs for linking to schedules are the only things that the OSM community can't do for themselves - possibly we start by working on data providers to supply these using the current standard in the stop_id field. When we have some examples in use we can push for more content. Any suggestions of places that use good permanent IDs? I signed off from gtfs-changes some time ago, possibly you could forward my emails to the list if that would help? Happy to get involved if that would be productive, do let me know. Either way, I hope that a desire for tidier data won't get in the way of OSM making the most of the wealth of transport data that's already been made available to the public. Agreed. Finding places with good GTFS stops data and then importing it in OSM would be a great start. Regards, Peter Cheers, Joe On Tue, Jul 13, 2010 at 1:54 PM, Peter Miller peter.mil...@itoworld.com wrote: Apologies form coming into the conversation late( (I have just returned from the State of the Map conference which was very impressive as always). I have been spending some time looking at GTFS stops data for San Francisco today. There seems to be a problem where there are multiple stops with the same name, there also appear to be different names for the same physical stop which may appear multiple times as I don't believe there are that many actual stops on the ground. On the junction of Market St Castro St there are 8 bus stop points in GTFS They are called: Market St Castro St Market St Castro St Market St Castro St Castro St Market St Market St Castro St Market St 17th St Castro St 17th St 17th St Castro St And then the following for metro services (note the names are not that well chosen as a pair) Metro Castro Station/Downtown Metro Castro Station/Outbound Not all of the above have actual services from them and Google Transit bails out, merges the services into a smaller number of stops (one for bus and one for metro) and when one pulls up a service lists them as 'services available from near here'. The full list of stops (some of which have no services) do however appear on the google streetview images. We have experience of the UK NaPTAN database where there is a separate DB for the stops from the schedules and from the mapping). I would suggest that: We recommend that GTFS is modified so that Stop_ID should ideally be used for a stable
Re: [Talk-transit] Bus stops in North America from GTFS data
On 11 Jun 2010, at 09:44, Richard Mann wrote:
Sometimes there are obscure codes on bus stops (eg in Oxford), so that
humans can text them to a Real Time Passenger Info service (called
OxonTime here). Eg the ref tag on this node:
http://www.openstreetmap.org/browse/node/533877725
For which you can get a departures list:
http://www.oxontime.com/pip/stop_simulator.asp?naptan=69345648
I make that three different stop ids, plus some other stuff that could
probably be combined to make one. If you haven't got unique ids yet,
then it's quite likely that someone will introduce them soon. You
know, you wait ages for a unique id then three come along at once...
It is not easy to bring 140 transport authorities and probably over
1000 independent transport operators (many of which are very small)
into a single naming and identification system, especially when prior
to 1997 the public transport sector had had precious little
investment. However every public transport access point (bus stop,
railway station, airport gate) now has a unique AtcoCode, for the
above stop it is '34000199404'. (11 digits) (ATCO stands for
'Association of Transport Co-ordinating Officers)
Every bus stop in the UK also has a unique shorter code called a
'NaPTAN Code'. For each the above stop it is 'oxfgjmgt' (8
characters), however when one types that code on a mobile phone one
uses the numbers '69345648' which is the numeric form of the NaPTAN
Code used by oxontimes above.
Needless to say OSM has its own node-id for the feature but the
feature includes the ATCO Code and the alphabetical form of the Naptan
Code from which the numeric form can be calculated.
More about naptan codes here
http://www.dft.gov.uk/naptan/smsPrefixes.htm
Regards,
Peter
Richard
On Fri, Jun 11, 2010 at 3:48 AM, Peter Miller peter.mil...@itoworld.com
wrote:
On 11 Jun 2010, at 01:49, john whelan wrote:
Ottawa is different. The passengers complain if the bus is one
minute early
or five minutes late. Quite unlike London in the UK where I used
to live.
I think it stems from the minus 30c in winter time, with wind chill
it can
be even colder, the passengers typically turn up about two minutes
before
the bus.
Thanks for your thoughts.
Cheerio John
On 10 June 2010 20:25, Roland Olbricht roland.olbri...@gmx.de
wrote:
You may want to follow
British/German standard. There is a tag that identifies stops
uniquely,
sorry can't recall at the moment. The last time I saw it was
Siegburg/Bonn train station.
Do you mean the ref tag as on node 160621? I'd strongly advice
not to
follow
that way. The ref has also been used to list the lines stopping
there
and
should not be used for something else.
I've never seen any item that identifies bus stops uniquely in
Germany or
Britain and is visible to the ordinary passenger. It is also not
needed -
all
bus stops with the same name in the same town are usually very close
together
(just stops for different directions). But being unique would be
never
stated
as a formal constraint. Buses sometimes stop at two nearby stops
with the
same
name. Thus there is nothing comparable to the stop_code here in
Germany.
In the UK stops on either side of the road typically have the same
'name', a
different indicator sometimes imported into OSM as a 'local_ref' (or
naptan:indicator).
In London and some other places the 'indicator' is often a single
letter (or
pair of letters) which is used on local maps and at the top of the
pole and
is unique locally Notice the 'D' indicator on top of this bus stop:
http://www.flickr.com/photos/route79/2937392/
Here is a node in OSM which a 'Local_ref' code ('K' in this case)
http://www.openstreetmap.org/browse/node/469771254
And here is the same stop on an official TfL map used in bus
shelters in the
area.
http://www.tfl.gov.uk/tfl/gettingaround/maps/buses/pdf/londonbridge-2163.pdf
This stop is also in a relation with the stop across the road:
http://www.openstreetmap.org/browse/relation/203739
But stops can be part of larger relations for a transport
interchange, in
this case a railway station (although not all elements associated
with the
station are included in this example yet) including platforms,
other bus
stops etc.
http://www.openstreetmap.org/browse/relation/205097
Every UK bus stops also has a unique 'Naptan:AtcoCode' which is
used by
information systems but not by humans.
Here are some pages about the UK dataset and the import
http://wiki.openstreetmap.org/wiki/NaPTAN
For comparison, here is a typical German stop
http://www.openstreetmap.org/browse/node/638614538
In the UK we imported all the relevant data into a naptan:
namespace and
then copied elements with OSM tags into the main OSM space. This
could be a
good way of working in other countries.
Finally here is a proposal for tagging some of the more complex
aspects
Re: [Talk-transit] Bus stops in North America from GTFS data
On 11 Jun 2010, at 09:44, Richard Mann wrote:
Sometimes there are obscure codes on bus stops (eg in Oxford), so that
humans can text them to a Real Time Passenger Info service (called
OxonTime here). Eg the ref tag on this node:
http://www.openstreetmap.org/browse/node/533877725
For which you can get a departures list:
http://www.oxontime.com/pip/stop_simulator.asp?naptan=69345648
I make that three different stop ids, plus some other stuff that could
probably be combined to make one. If you haven't got unique ids yet,
then it's quite likely that someone will introduce them soon. You
know, you wait ages for a unique id then three come along at once...
One final thing.
One can type the AtcoCode or the alpha NaPTAN code into this search
box to get departure times for any stop in the UK:
http://www.nextbuses.mobi/
And an XML API is also available. Details here:
http://www.pti.org.uk/nextbuses.htm
I notice from the above link that an iPhone app is also available
using the service (and of course the codes), so it really is coming
together in the UK. Personally I think we should complete the import
of NaPTAN into OSM (even for places where no one has specifically
requested it). We also need to create a process to monitor divergence
between OSM NaPTAN and the version in data.gov.uk
(http://data.gov.uk/dataset/naptan
) which is updated every 3 months at present.
In summary I think the UK has done a good job on this one and which
could be replicated elsewhere!
Regards,
Peter
Richard
On Fri, Jun 11, 2010 at 3:48 AM, Peter Miller peter.mil...@itoworld.com
wrote:
On 11 Jun 2010, at 01:49, john whelan wrote:
Ottawa is different. The passengers complain if the bus is one
minute early
or five minutes late. Quite unlike London in the UK where I used
to live.
I think it stems from the minus 30c in winter time, with wind chill
it can
be even colder, the passengers typically turn up about two minutes
before
the bus.
Thanks for your thoughts.
Cheerio John
On 10 June 2010 20:25, Roland Olbricht roland.olbri...@gmx.de
wrote:
You may want to follow
British/German standard. There is a tag that identifies stops
uniquely,
sorry can't recall at the moment. The last time I saw it was
Siegburg/Bonn train station.
Do you mean the ref tag as on node 160621? I'd strongly advice
not to
follow
that way. The ref has also been used to list the lines stopping
there
and
should not be used for something else.
I've never seen any item that identifies bus stops uniquely in
Germany or
Britain and is visible to the ordinary passenger. It is also not
needed -
all
bus stops with the same name in the same town are usually very close
together
(just stops for different directions). But being unique would be
never
stated
as a formal constraint. Buses sometimes stop at two nearby stops
with the
same
name. Thus there is nothing comparable to the stop_code here in
Germany.
In the UK stops on either side of the road typically have the same
'name', a
different indicator sometimes imported into OSM as a 'local_ref' (or
naptan:indicator).
In London and some other places the 'indicator' is often a single
letter (or
pair of letters) which is used on local maps and at the top of the
pole and
is unique locally Notice the 'D' indicator on top of this bus stop:
http://www.flickr.com/photos/route79/2937392/
Here is a node in OSM which a 'Local_ref' code ('K' in this case)
http://www.openstreetmap.org/browse/node/469771254
And here is the same stop on an official TfL map used in bus
shelters in the
area.
http://www.tfl.gov.uk/tfl/gettingaround/maps/buses/pdf/londonbridge-2163.pdf
This stop is also in a relation with the stop across the road:
http://www.openstreetmap.org/browse/relation/203739
But stops can be part of larger relations for a transport
interchange, in
this case a railway station (although not all elements associated
with the
station are included in this example yet) including platforms,
other bus
stops etc.
http://www.openstreetmap.org/browse/relation/205097
Every UK bus stops also has a unique 'Naptan:AtcoCode' which is
used by
information systems but not by humans.
Here are some pages about the UK dataset and the import
http://wiki.openstreetmap.org/wiki/NaPTAN
For comparison, here is a typical German stop
http://www.openstreetmap.org/browse/node/638614538
In the UK we imported all the relevant data into a naptan:
namespace and
then copied elements with OSM tags into the main OSM space. This
could be a
good way of working in other countries.
Finally here is a proposal for tagging some of the more complex
aspects:
http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area
Regards,
Peter Miller
ITO World
www.itoworld.com
John, I would advice you to just set name to the stop_code if this
is the
thing displayed on the bus stops. It is very
Re: [Talk-transit] Bus stops in North America from GTFS data
On 11 Jun 2010, at 01:49, john whelan wrote:
Ottawa is different. The passengers complain if the bus is one
minute early or five minutes late. Quite unlike London in the UK
where I used to live. I think it stems from the minus 30c in winter
time, with wind chill it can be even colder, the passengers
typically turn up about two minutes before the bus.
Thanks for your thoughts.
Cheerio John
On 10 June 2010 20:25, Roland Olbricht roland.olbri...@gmx.de wrote:
You may want to follow
British/German standard. There is a tag that identifies stops
uniquely,
sorry can't recall at the moment. The last time I saw it was
Siegburg/Bonn train station.
Do you mean the ref tag as on node 160621? I'd strongly advice not
to follow
that way. The ref has also been used to list the lines stopping
there and
should not be used for something else.
I've never seen any item that identifies bus stops uniquely in
Germany or
Britain and is visible to the ordinary passenger. It is also not
needed - all
bus stops with the same name in the same town are usually very close
together
(just stops for different directions). But being unique would be
never stated
as a formal constraint. Buses sometimes stop at two nearby stops
with the same
name. Thus there is nothing comparable to the stop_code here in
Germany.
In the UK stops on either side of the road typically have the same
'name', a different indicator sometimes imported into OSM as a
'local_ref' (or naptan:indicator).
In London and some other places the 'indicator' is often a single
letter (or pair of letters) which is used on local maps and at the top
of the pole and is unique locally Notice the 'D' indicator on top of
this bus stop:
http://www.flickr.com/photos/route79/2937392/
Here is a node in OSM which a 'Local_ref' code ('K' in this case)
http://www.openstreetmap.org/browse/node/469771254
And here is the same stop on an official TfL map used in bus shelters
in the area.
http://www.tfl.gov.uk/tfl/gettingaround/maps/buses/pdf/londonbridge-2163.pdf
This stop is also in a relation with the stop across the road:
http://www.openstreetmap.org/browse/relation/203739
But stops can be part of larger relations for a transport interchange,
in this case a railway station (although not all elements associated
with the station are included in this example yet) including
platforms, other bus stops etc.
http://www.openstreetmap.org/browse/relation/205097
Every UK bus stops also has a unique 'Naptan:AtcoCode' which is used
by information systems but not by humans.
Here are some pages about the UK dataset and the import
http://wiki.openstreetmap.org/wiki/NaPTAN
For comparison, here is a typical German stop
http://www.openstreetmap.org/browse/node/638614538
In the UK we imported all the relevant data into a naptan: namespace
and then copied elements with OSM tags into the main OSM space. This
could be a good way of working in other countries.
Finally here is a proposal for tagging some of the more complex aspects:
http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area
Regards,
Peter Miller
ITO World
www.itoworld.com
John, I would advice you to just set name to the stop_code if this
is the
thing displayed on the bus stops. It is very different from the
northern
European system. But passenger (or traveller) information is the
primary goal
of the OSM data. Thus a useful information in the tag that is
expected to be
crucial (name) is probably the best solution for Ottawa.
Cheers,
Roland
___
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
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] RFC on interchanging data
On 24 Feb 2010, at 17:24, Claudius Henrichs wrote: Hello Roland, you hit the nail on the head: public_transport:stop_area relations are the way to go. At least I keep mapping stations/stops with interchange possibilities like that. Please do not forget about stop_area_group as well as these relations are used to denote interchanging possibilites between nearby stop_areas :) Here is a proposed scheme for interchanges that a few of us developed from Oxomoa's page with the main difference being that it is in the public wiki space so that other people can work on it (Oxoma's scheme remains in his private space where etiquette says ut should not be edited by others) http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area Should we put this one to a vote and work up something that we can agree on that is on the proper wiki? Regards, Peter Claudius Original-Nachricht Datum: Wed, 24 Feb 2010 18:09:52 +0100 Von: Roland Olbricht roland.olbri...@gmx.de An: Public transport/transit/shared taxi related topics talk-transit@openstreetmap.org Betreff: [Talk-transit] RFC on interchanging data Hello everybody, What is the consensus on how to map interchange data? I would like connect two (or more) bus stops and/or railway stations to indicate that you can preferably change vehicles there (e.g. the bus stop(s) that is/are intended to change into a nearby train station). This is often indicated by sharing the same name, but not always. I haven't found anything useful about this neither on http://wiki.openstreetmap.org/wiki/Public_Transport and its connected pages nor on http://wiki.openstreetmap.org/wiki/User:Oxomoa/ Public_transport_schema and I want to know which data model (or models) I hard-code into my software and use for the data I map. I think that membership within a relation public_transport=stop_area fits best for this purpose but I'm not sure whether I can interpret all existing stop areas in this way. Thus, I would be grateful for any comments. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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] bus route/relations done right
On 17 Nov 2009, at 12:57, Roland Olbricht wrote: Can I suggest we define some terms. A Line is all the journeys made using a particular reference (4, X13, Citi1 etc). [...] A Line Variant (also know as a Service Variant) is a unique stopping pattern for a bunch of Journeys within a Line. (ie inbound, outbound, inbound via the school, outbound but stopping at the station and not going to the end of the route etc). [...] I strongly suggest we don't add this data to OSM - it is too complex and not needed for mapping and should be kept in the schedules service. I strongly refuse that point of view. From the preceding discussion, I conclude that the paradigm of bus services varies very much between different countries. I don't know the situation in Great Britain, so I'm referring to the situation in Germany (in particular: Düsseldorf, Münster, Wuppertal), Switzerland, The Netherlands, Belgium and maybe other countries. In these places, most bus services have very few variants (in general two, one forth and one back) and timetables are very stable. For example, in Wuppertal more than 90 percent of all services have not changed even their timetable in the last 15 years. Thus, the timetable information has a similar complexity than the information about lines. The paradigm can be found under the name Integraler Taktfahrplan in German or Horaire cadencé in French. I have not found an English translation. Roughly, it would be Integrated fixed-interval timetables. On the other hand, there is no free timetable service in Germany or France. Thus, having the essential information (Where exist direct services? Which connections a designated and thus reliable for changing trains?) in OSM would be a great help. So I would suggest to encourage mappers to add timetable information whenever an integrated fixed-interval timetables exists. This might not apply to Great Britain, but I think we shouldn't take this as a reason to map Public Transport elsewhere worse than possible. I think I was making two separate points. 1) That a Line and a Line Variant are different concepts and we should use them consistently. 2) That in my opinion it would be sensible to stop at Lines and not integrate more detail. If we agree on 1) then we can allow people to make personal judgements about 2) for their areas. Regards, Peter Cheers, Roland ___ 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
[Talk-transit] Novam colour scheme question
On 11 Nov 2009, at 16:23, Ed Loach wrote: Looking at the bus stops I've verified, and in particular ones on roads where I've verified some but not others, would it be possible to have a different colour (I'm using Peter Miller scheme at present) for unverified stops with type CUS? I can't think of any easy way of verifying those other than hang around all day hoping someone will get on or off (or perhaps trying to get on at one and trying to get off at another). I was going to suggest that the 'Peter Miller' style was retired and that we use the Hull standard as a starting point - I have moved to use Chris's style personally. Anyone feel strongly about it? I would support Ed's suggestion - also that the phrase 'not physically present' is changed to 'customary' (which can be defined if necessary) to clarify the difference between a bus stop that does exist at all and no buses ever call at it (I have found some of those) and customary ones which are 'virtual' stops and do exist in schedules but don't have poles. Can I suggest Ed, that when you have the visualisation you need from Novam sorted out that you head to the busman's canteen at the local bus station and get some bus drivers to review the customary stops view and see if they spot any that aren't actually in use. It's amusing to find the ones where the bus drivers disagree with each other about whether customary stops do or do not exist - I had that strange experience once with a place my kids were needing to get to, and it turned out that the older drivers stopped and the younger ones didn't (not an entirely satisfactory situation really)! Regards, Peter Ed ___ 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] TTC - Toronto, Canada data available
On 4 Nov 2009, at 07:56, Sam Vekemans wrote: Hi all, if any of you are on the talk-ca list, you might have seen that the city of Toronto opened up their data, and TTC info is in there. Does anyone have a clear method/approach that worked for dealing with the data? Is it better to have scheduals embedded in the stop? a route relation? -is there a standard tagging method? -or is it better to keep the data out of OSM, but just have it as an external database layer (considering the complexity the high rate of change) Great stuff! I think the general opinion is as follows: Bus stops - yes please, lets have these in OSM asap so they can be matched up nicely with the roads. Ideally there should be a node of each point where one can wait for a bus (meaning that there should be two nodes when there are stops in either side of the road). Routes - People are adding these extensively, motivated by www.öpnvkarte.de that will then display them. Other people, particularly public transport professionals are concerned that the data will be hard to maintain in OSM and changes too often and that it would be better not to have in OSM. Personally I think it is inevitable that some route data will get put into OSM and that there are also benefits to having it there. The best response might be to experiment with automatic imports that keep OSM mapped to the current schedules for areas with free data. Schedules - Personally I would resist what I would see as the major 'mission creep' of trying to add detailed departure times etc to OSM. service timings change even more often and I don't believe that the data model is appropriate for holding the data, the tools are not good at entering the data and the data is unlikely to get undated. As a starter I would love to see a project to get all the bus stops we can from public sources into OSM. Regards, Peter Thanks, Sam -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ 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] NOVAM is back
On 27 Oct 2009, at 22:58, Shaun McDonald wrote: Looking good, I'm thinking of adding timetable_case=yes/no/empty to the list of required fields. Good stuff - I have been through my local area with a cleanup pass of and it has helped find a number of issues. I will do other parts of the town next. Can I suggest that NOVAM needs its own wiki page and that the link from the product should go that that page. Could you add a 'edit this feature in Potlatch' option from the Stops information pane? I guess a link to JOSM may also be wanted by others. I do thing we should rationalise the different view option into a 'basic' and a number of 'advanced' options. The basic option could ignore if there are shelters and routes etc, the advanced options can take more of these into account and colour code things appropriately. Part of me wonders if you could encode the colours into the URL using a bit pattern for the tag entries, so... colours=#6 #00FF00, #7 #FF, #E #808000 would mean that if the appropriate two tags were present (#6=binary 000110) then the colour would be #00FF00 except if three tags (#7=binary 00111) were present and then the colour would be #FF etc. One can then encode the most common options into a pull- down list but is does allow people to play with other variations. Regards, Peter Shaun On 27 Oct 2009, at 22:21, Christoph Böhme wrote: I've updated Novam. It now supports multiple colour schemes and also highlights errors in the tagging of stops. At the moment three colour schemes are defined: 1. The original Birmingham one 2. Chris Hill's colour scheme for Hull (with slightly different colours though) 3. Peter Miller's colour scheme which should work for most of the UK (please tell me if you rather not have the colour scheme named after you) These colour schemes should work but they might need some fine tuning. Additional colour schemes can easily be added. If you are interested in writing one have a look at [1]. The file lacks documentation but it should be clear from the three existing schemes how schemes are defined. Christoph [1] http://mappa-mercia.org/novam/scripts/Novam/Schemes.js Christoph Boehme christ...@b3e.net schrieb: Good Morning, this is just to let you know that NOVAM is working again. It can be found on http://mappa-mercia.org/novam . Please update any old links and booksmarks. Since I decided not to implement a merging functionality on the website I have removed most of the old user interface elements and made the NOVAM viewer the new interface. Please tell me if you miss any functionality from the old user interface. I will update the colour coding of the bus stops at the weekend. Cheers, Christoph ___ 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 ___ 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
[Talk-transit] NOVAM is back
On 22 Oct 2009, at 10:11, Christoph Boehme wrote: Good Morning, this is just to let you know that NOVAM is working again. It can be found on http://mappa-mercia.org/novam . Please update any old links and booksmarks. Since I decided not to implement a merging functionality on the website I have removed most of the old user interface elements and made the NOVAM viewer the new interface. Please tell me if you miss any functionality from the old user interface. I will update the colour coding of the bus stops at the weekend. Thanks Christoph. Much clearer. I understand that when you update the colours you will show:- 1) Unverified naptan import nodes (ie with verified=no) 2) bus stops in OSM which don't have any NaPTAN fields (ie ones without a naptan:AtcoCode field). 3) stops that don't have all the expected fields (please remove routeref field from this test) 4) and of course... complete and happy stops which have everything required! Can I suggest that you place stops with issues on top of ones without issues on the browser, so that stops with problems are not obscured by nearby ones which are ok. When you have that in place I will I suppose have to go and complete the review of stops in my town! Thanks again, Peter Cheers, Christoph ___ 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] [Spam] Re: NOVAM is back
On 22 Oct 2009, at 14:30, Christoph Boehme wrote: Peter Miller peter.mil...@itoworld.com wrote: Will be added too. All good ideas. A 'see this area of mapping in openstreetmap.org' would also be great. Do you mean in an editor or just on the OSM website? I meant just the plain old OSM website from which one could use edit if one wished. Having said that the MapJumper is possibly a better way of achieving this (although I don't yet understand exactly how it works). The 'help' link doesn't see to be much help btw (it just links back to the same page as far as I can see). Possibly a page of explanation would be good. There is no help available yet. Perhaps I better remove the link completely until some documentation has been compiled. I think that would be a good idea - however, help doesn't need to be more complex than saying what a 'complete set of tags' means really with a few links into the wiki. Alternatively, why not just direct the 'help' link to the wiki and then we can add whatever is appriopriate for the help to that page. Regards, Peter Cheers, Christoph Regards, Peter Shaun Thanks again, Peter Cheers, Christoph ___ 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 ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN case study
On 22 Oct 2009, at 15:12, Shaun McDonald wrote: On 22 Oct 2009, at 15:00, Peter Miller wrote: Every bus stop has an associated authority in NaPTAN - possibly we should import this as well to help spot errors in the boundaries. You don't need to import the authority into OSM too. The bug reporting system could take an osm node id, then lookup the live naptan data for differences etc and these could be included in the report, which would go to the authority that has been found in the live naptan data. The other advantage of this, is that if the naptan bus stop changes hands (for whatever reason) then it'll be going to the right group, rather than an out of date group from some old OSM data. To be cleat, to date we have only been given permission to take occasional updates from NaPTAN with agreement from Traveline - and we do not have agreement to 'sniff' the live data on a regular basis as I think you are suggesting. However... I would not be surprised if Traveline agreed to allow access to the live data in time given the motivation that is building within the community to get the data right in both systems. Even with the above restriction, we will of course be able to parse the released version of NaPTAN against the OSM versions of the same data and produce reports for OSM contributors, which could include details of stops that appear to be out of the appropriate authority, or where the NaTPAN and the OSM data have diverged and where one or other of the datasets may be wrong. Regards, Peter Shaun___ 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] open transit map?
On 29 Sep 2009, at 20:20, Bin Jiang wrote: HI, looks wonderful, but where can I down the transit data? Sorry for if its a naive question. The routes are encoded in OSM as relations. Here is an example bus route:- http://www.openstreetmap.org/browse/relation/190701 Regards, Peter Cheers. Bin Christoph Böhme wrote: Bin Jiang bin.ji...@hig.se schrieb: Hi, I wonder if any transit map is available like openstreetmap.org and opencyclemap.org. I tried opentransitmap.org without success:-) Try http://www.öpnvkarte.de/ Although, I am not sure how much of the world is covered. Cheers, Christoph Cheers. Bin -- -- Bin Jiang Division of Geomatics, KTH Research School Department of Technology and Built Environment University of Gävle, SE-801 76 Gävle, Sweden Phone: +46-26-64 8901Fax: +46-26-64 8828 Email: bin.ji...@hig.se Web: http://fromto.hig.se/~bjg/ European Associate Editor Computers, Environment and Urban Systems: An International Journal NordGISci: http://fromto.hig.se/~bjg/NordGISci/ ICA Commission: http://fromto.hig.se/~bjg/ica/ ___ 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
[Talk-transit] Announcement re new 'moderation' email list to develop effective responses to vandalism and mistakes
A new 'moderation' email list[1] has been created to help develop effective responses to vandalism and mistakes. To avoid spam subscriber's the first posts will be moderated so don't expect them to appear immediately. Subsequent posts will not be moderated. [1] http://lists.openstreetmap.org/listinfo/moderation Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Relations for stop areas in NaPTAN
On 28 Sep 2009, at 14:58, Frankie Roberto wrote: Jerry wrote: I've just noticed that the relations for stop places generated in the NaPTAN import do not have a type. I just happened to be browsing through some KeepRight issues and noticed a number of relation without type ones. I think the consensus is that these should become type=site. This can be made more specific by either using site=* (eg site=railway_station) and/or traditional tags like railway=station and amenity=bus_station. Firstly I suggest we stick with Stop Area and not use Stop Place. Stop Place is more correct from a CEN standards perspective but Stop Area is very much adopted. I think the site approach makes a lot of sense and it would be straightforward to migrate to this over time. Peter Miller wrote: I noticed yesterday that the public transport article[1] is still linking to 'User:Oxomoa/Public transport schema' article for tagging information even though this is a personal page and therefore not something that others should touch. http://wiki.openstreetmap.org/wiki/User:Tirkon seems to have moved the content from Public transport into Public Transport, which was a pre-existing page that linked to Oxomoa's proposal. I'm guessing that this is to better link it to the DE:Public Transport page. I can't remember what we decided about capitalisation conventions (I think we'd said it was worth following the Wikipedia- like Public transport style), so it might be worth reversing these redirects. The guidelines page recommends using Wikipedia convention. He also broke a number of redirects which are now double redirects. Can I suggest you 'propose' a move back and that you put your reasons on the talk page to avoid a wiki-war. It would have been polite for the person to have proposed the move in the first place of course. http://wiki.openstreetmap.org/wiki/Wiki_guidelines I have developed a Stop Area article[2] based on Oxomoa's proposal and which also included feedback from CEN. It is currently available as a 'proposed feature'. however it should in general echo current practice. Would it be appropriate to now move it into the main name- space and use it as the primary overview article for stations, bus stops etc? I've been trying to slowly copy some of ideas from your proposal (and other conventions in use) into the Public transport page, and the various mode pages (eg Railways), as well as creating tag- specific pages where appropriate (eg Tag:route=railway). I think this is probably a better approach than trying to have one uber- proposal. To be clear, it is only a proposal for Stop Areas, not for everything to do with public transport, but it could also sit in the relevant articles and fade away over time. I do however think it is useful to have a simple table giving the tags for an 'access' for each transport mode. The discussion sections would of course all be moved to the talk page so the article itself would shrink a lot. If so should we just do it or do a formal vote first. Given that it is actually now a summary of current practice I would recommend moving it without voting but would be happy to follow the majority view. Thoughts please! Agreed we don't need a vote. Community consensus, and working examples, are much more important. Possibly we move it from proposals to the main section and then consider what it's future will be. I would however suggest that we discourage any links to the 'old' proposals, including unified_stop_area and Oxomoa's proposal except for historical background. Possibly we need to get the Germans on board for this since they seem keen on linking to Oxomoa's proposal. Regards, Peter Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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
[Talk-transit] East Lothian Bus Stops lack any details on the ground
On 23 Sep 2009, at 19:32, Shaun McDonald wrote: Hi, Yesterday I was out checking a few bus stops in East Lothian (cycling from Musselburgh out along the coast to North Berwick). Pretty much all of them had no information other than a flag which said that buses stop here and that you are in East Lothian. There was one that had a timetable where there were 4 buses per day to the regional hospital in Edinburgh. Most of the bus stops did have a space for a timetable but there was nothing in there about it. Is this normal for more rural stops? Is it any wonder hardly any one uses the bus in the area when they have no idea of where they go? (Well that's probably diverging from the point). Yes, the level of information provision is very variable across the county - the nearest stop to my house has information dated August 2005! Possibly we should use FixMyStreet to report these to the authorities? I have been adding 'tabletable_case=yes' to indicate that there is somewhere to put timetable information, but I have not been indicating whether there is any information in it. Regards, Peter Taken a photos of a few in Edinburgh, will need to see how they marry up with the Naptan data as there is some references on the flag and the timetable signs. http://www.trackmyjourney.co.uk/track/t4xzYTfZ7tj94 Shaun___ 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] London Bridge
On 18 Sep 2009, at 15:40, Thomas Wood wrote: I've been pondering micro-mapping the carstop signs to mark where the front of the train stops. Indeed, I tried to collect this info for Wimbledon, but the GPS there was too poor also. Sounds good. How about the following:- A railway=stop node for the point on the track where the front of the train should stop. Using railway=platform (linear way) for each platform (parallel to the track) Then a platform=boarding_point node for each car-stop sign on the platform way with the carriage number - possibly multiple ones per platform We then have enough information for people to play trains! If the station has multiple levels then each element should have a layer tag and we will need to consider how one manages a single level (concourse) where one side has a level entrance to the outside world layer=0? and the other side is up a load of steps to the concourse and could be considered layer=1 I guess we just choose a set of layers we will use and then join them to the outside world with a 'footway' or with 'steps' For a lift we use a node with multiple layer numbers highway=lift? layer=0,1,2? I have been trying to capture most of this on the Stop Area proposal - not so much a proposal as a description of good practice:- http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area Regards, Peter 2009/9/18 Peter Childs pchi...@bcs.org: 2009/9/18 Frankie Roberto fran...@frankieroberto.com: 2009/9/18 Peter Childs pchi...@bcs.org Its very difficult as London Bridge is based on about 6 layers with random escalators, lifts and ramps connecting it up. I'm thinking the building should only cover parts with a roof on and hence really needs cutting up. Yeah, agree. Is there a marker I can put up to say where the trains actually stop and that you need to move down the platform. Ideally, there should a way per railway track, and a way per platform (you can map platforms as areas, but it seems to work better as linear ways). If there's a way that represents more than one track (eg two tracks running between island platforms, add tracks=2). Then, make a node on each track to represent where the trains stop. There can be more than one of these if there are a few stopping points (eg platform 1a, 1b). Tag this railway=stop. All of these stopping points, plus the platforms, plus the station building, should then all belong to the station's relation (http://www.openstreetmap.org/browse/relation/205097) - ideally add role=stop to the stop nodes. Ok I spouse I need stop markers for different number of carriages. What about the back of the train? Also I guess we are going to need a tag to say The last set of doors will not open as the platform is not long enough. Maybe we should have door marks, ie Rather than say the train stops here say where the doors should be; I've seen these marked on the platform in some parts of the world and parts of the Tube have automatic doors fixed to the platform! Peter. ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Should railway station relations include busstops?
On 10 Sep 2009, at 00:45, Thomas Wood wrote: NaPTAN provides relations for stations (or at least it should, I've yet to check), in most cases, this will contain the station node, and entrance nodes, and child relations eg, the stops outside of it. I've yet to import them, but I do have all the backreferences stored to do so. NaPTAN allows for a hierarchy of stop areas. In NaPTAN there should be a Stop Area for all the features directly associated with the railway station. There can then be other (un-related) stop areas associated with groups of bus stops around the station I believe that an additional Stop Area can then be used to bind all of the above into one. The rendered can then choose to do one blob for all the public transport features around the station, or one for station itself and to identify every feature individually. Stop Areas are not well used across the UK, some areas use them, some don't and where they are used the data can be a little suspect. Possibly we could aim to do a better job over time? Regards, Peter On 10/09/2009, Frankie Roberto fran...@frankieroberto.com wrote: Hi all, Last question of the night from me. I've been creating relations for railway stations (see http://wiki.openstreetmap.org/wiki/United_Kingdom_train_stations) and just noticed, when doing Marylebone ( http://www.openstreetmap.org/browse/relation/238413), that there's already a Naptan-created relation for the bus stop ( http://www.openstreetmap.org/browse/relation/199421). Should these two be merged? Or are bus stop areas and train stations conceptually distinct? Frankie P.S I note that the Naptan relation doesn't have a type=* tag. This should probably be type=site? -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com -- 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
[Talk-transit] Vertical Levels (Layers) versus Altitude for stations
In the absence of a vast building program of new monorails[1] as proposed by Bill Ricker, I am beginning to think about mapping some of the more complex transport interchanges here in the UK. I am currently adding platforms, walkways and steps to the simpler stations that I know and am now thinking about more complex ones. Bill also talked about the use of the layer tag on some stations on the monorail at Disney with the stations at layer 3 and the track at layer 2 and I think it would be useful to talk about how we can usefully use layer tags for complex interchanges. I checked out the IFOPT CEN standard[2] on the subject and found this useful section on Vertical Levels (Layers) versus Altitude (they call them levels, we call them layers btw) 1.4.6 Vertical Levels versus Altitude Transport interchanges are often complex buildings with many interconnected levels. The labelling and description of the levels is used in describing stops and directions in PT info systems and so needs to be part of the Fixed Object model. This LEVEL is a distinct concept from that of a vertical spatial coordinate in that it is a semantic label (for example Departures, Basement , Floor 1, etc). Altitude is in effect the z coordinate of a POINT. I think this useful for us and clarifies that if the station appears to be organised on two 'layers' (using OSM terminology) then it doesn't matter that in fact one of the layers incorporates an incline at one point so that part of 'layer' it is at a different altitude to another part. If of course if there is a slope which connects two different distinct layers of the station (something which could also occur) then we should consider that to be a path between the layers. The logic is that when we start mapping more complex 3D stations (and other structures) then we shouldn't get too stressed about altitude, but should instead divide the place up into human understandable layers. This is something that is often done anyway in diagrams that describe the layout of stations[3] and ships[4]. When we come to map this we are going to need an editor that can allow us to see only one level at a time, but there is a growing need for editors to allow one to focus on one aspect of the data only and avoid picking up or modifying features that are out-of-scope anyway so I am sure that will come. While being focused on a particular layer then any features added would be added at that layer. We would also need to consider slope, steps and lifts between layers and the situation where a lift only connects some layers but not all of them. A lift is currently represented as a single node because it is vertical. How does one indicate which layers it connects? How would one assign layers to a complex metro station where one can't guess the depth of each element - possibly one would have to count steps and measure the height of one of them to calculate a depth for each platform and therefore assign layers.. but that still does solve the problem for escalators So, possibly we can be kept occupied even without a massive monorail program. Fun stuff ;) Peter [1] http://lists.openstreetmap.org/pipermail/talk-transit/2009-September/000593.html [2] http://en.wikipedia.org/wiki/Identification_of_Fixed_Objects_In_Public_Transport [3] http://home.wangjianshuo.com/archives/20080105_shanghai_metro_century_avenue_station.htm [4] http://www.wildalaskacruises.com/capabilities.htm___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Vertical Levels (Layers) versus Altitude forstations
On 4 Sep 2009, at 09:25, Christoph Boehme wrote: Peter Miller peter.mil...@itoworld.com wrote: We would also need to consider slope, steps and lifts between layers and the situation where a lift only connects some layers but not all of them. A lift is currently represented as a single node because it is vertical. How does one indicate which layers it connects? We could create one elevator-node for each level the elevator connects to. These nodes are only connected to the ways on their level. This basically results in the elevator access points (aka doors) are mapped. To find out which elevator doors belong to the same elevator we can put all the nodes in a relation. Please note that this scheme would not only work for elevators but also for teleporters. Could we map levels/layers using relations, and then the elevator node could be associated with the relevant layers. We could tag the elevator node with 'layer=1,2,3,4' or whatever to identify which layers were accessible. Should each layer actually be a polygon with a name, ie 'name=basement' or 'name=Level 2' and possibly as 'highway=pedestrian' and 'areas=yes'? All other features (tracks, footways, toilets and shops etc) tagged with the same 'layer' tag that are within the area of the polygon would then be associated with it for routing purposes. Lets ensure that we keep the map as accessible as possible for newbies while also managing to capture this additional stuff. I would suggest that we try to devise a schema that can be used with today's editors but which will be easier with a 'focus' function that could be incorporated into a later version of Potlatch and JOSM etc. Regards, Peter Cheers, Christoph [1] http://lists.openstreetmap.org/pipermail/talk-transit/2009-September/000593.html [2] http://en.wikipedia.org/wiki/Identification_of_Fixed_Objects_In_Public_Transport [3] http://home.wangjianshuo.com/archives/20080105_shanghai_metro_century_avenue_station.htm [4] http://www.wildalaskacruises.com/capabilities.htm ___ 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] JOSM Plugin
On 24 Aug 2009, at 20:18, Péter Connell wrote: Wonder if we need some openjourneyplanner thing - obviously a massive task. ... but who owns bus timetables? The argument is raging as we speak This is a great blog post on the subject which shows how hard the agencies are being pushed at present:- http://news.cnet.com/8301-19882_3-10315749-250.html?part=rsssubj=newstag=2547-1_3-0-5 At ITO we are pushing transport authorities virtually every day to get hold of the data under a commercial agreement where we pay them, but even that is hard! I am sure that in time the deal will be that the information is available without charge. Imo, we can't expect to maintain accurate timetables without access to the official data. It just isn't practical and sustainable to track all the detail and all the changes over time without it. And of course, the range of services which are suddenly available to authorities who release their data is growing by the day. Regards, Peter *strokes beard* ___ 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
[Talk-transit] Tools for viewing and dealing with the NaPTAN data...
I now have lots of great bus stop data in Suffolk and I want to check it and sort out any issues. However I am getting a bit lost re which tools are available to help check and improve the NaPTAN data and NPTG data in OSM. Could someone add brief description and links to the wiki? They could be added as a new section on the main naptan page. http://wiki.openstreetmap.org/wiki/NaPTAN Regards, Peter Miller ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NaPTAN Merging Guidelines
On 18 Aug 2009, at 01:07, Bryce McKinlay wrote: Thank you very much for your efforts on this, Thomas, and everyone else involved - I've been waiting for the London import for a while, and it's fantastic to see this data in OSM! +1 I have one bug to report: Is it possible that special characters are being dropped from the stop names during the import? For example: node id=469789137 lat=51.5122005 lon=-0.1420652 version=1 changeset=2177128 user=NaPTAN uid=104459 visible=true timestamp=2009-08-17T13:40:06Z tag k=name v=Conduit Street Saville Row/ tag k=naptan:CommonName v=Conduit Street Saville Row/ ... TfL refers to this as Conduit Street / Saville Row, so it seems the / characters are going missing somewhere? The data in NaPTAN does not include the '/' actually, probably because of the work being done to standardise stop naming across the UK in NaPTAN. In particular to discourage stop naming of the form 'street/ cross street' and the use of some characters including /. In this case the slash has gone but the cross street naming remains. Also, I'm curious whether, in addition to the bus stop data, NaPTAN contains precise locations for Underground station exits, and if so, whether there is any plan to import these? OSM often contains only one node for stations that have multiple exits, and in some cases the node is ambiguously placed such that it isn't clear which street (or which side of the street) an exit is on. This level of precision does become significant when producing walking maps/directions... Yes there are entrances in NaPTAN. For example there are 8 entrances given for Oxford Street Underground station. There are also platforms information, but no indication about which platform they relate to. Can I suggest we complete the import of bus stops import into OSM first and then go back for another trawl through the data and get more detail? Peter Bryce On Mon, Aug 17, 2009 at 3:50 PM, Thomas Woodgrand.edgemas...@gmail.com wrote: I've only just realised that my previous message regarding the imports beginning only went to talk-gb and talk-gb-london. Greater London is now imported as changeset 2177128. I was planning to import Hull and Suffolk also this week. Now that we're importing the data, we really need to get our guidelines on how to merge and tidy the data sorted. I've pulled out the relevant pieces from the Birmingham wikipage out to http://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data It really needs to be tidied and beaten into a useful document before we let more people loose with the data. -- 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
On 7 Aug 2009, at 10:08, Ed Loach wrote: Thanks Roger, If they're PlusBus zones, then Clacton railway station lies outside the Clacton zone as it currently stands, and while Harwich International (formerly Harwich Parkeston Quay) is probably a boundary point for the Harwich zone (though the railway station as marked in OSM seems to be slightly further north, so it may be the bus stop at the front of the station), Harwich Town (and Dovercourt) stations are outside the Harwich zone. A quick web search suggests the Harwich zone should look a bit like http://www.nationalrail.co.uk/system/galleries/pics/plusbus_maps/HAR WICH.gif and the Clacton one http://www.nationalrail.co.uk/managed/promotions/prd64ecf0a0a0024005 ffb18c459bd0e/ticketValidityConditions/PLUSBUS%20zone%20map%20for%20 Clacton-on-Sea.pdf ( or shortened: http://is.gd/26fwi ) Would it be sensible to create a PlusBus page on the wiki, and link to it from the NaPTAN user in relation to the upload? The Wiki page can describe what the features are about and can also be used to list issues that need to be resolved. I am not offering to create the page so hopefully someone else will do that. (I am doing work on cleaning up other existing transit related wiki pages on when I have time). Regards, Peter Ed -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk- transit-boun...@openstreetmap.org] On Behalf Of Roger Slevin Sent: 07 August 2009 09:20 To: 'Public transport/transit/shared taxi related topics' Subject: Re: [Talk-transit] Naptan import Ed Useful feedback which I will take up with PlusBus - as they should have listed coastal boundary stops to avoid this situation. Best wishes Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Ed Loach Sent: 07 August 2009 08:59 To: talk-transit@openstreetmap.org Subject: [Talk-transit] Naptan import I see some areas have been imported near here, public_transport=pay_scale_area, for Harwich and Clacton. Is there a wiki page somewhere detailing what these are (I'll search after sending this)? In the case of Clacton, it looks like it was defined as a line from the coast, inland, then back to the coast, so the segment that closes the area cuts right through the middle of town. Should I adjust this segment to follow the coastline? Clacton: http://www.openstreetmap.org/browse/way/38387713 Similarly for Harwich, the northeast segment seems to almost cross the tip of the peninsula, and in so doing cuts off most of Harwich to mainly only include Dovercourt. Should I amend that segment to include Harwich? Harwich: http://www.openstreetmap.org/browse/way/38387691 Thanks Ed ___ 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 ___ 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] Is 'Transit' and 'Public Transport' the samething?
On 7 Aug 2009, at 17:07, Christoph Böhme wrote: Peter Miller peter.mil...@itoworld.com schrieb: Which leads to a question of terminology... Is 'transit' a synonym for 'public transport'? or not. If not then what is the difference? As a non-native speaker of english I find it easier to guess what 'public transport' means compared to 'transit'. In german 'transit' usually means passing through something (e.g. when going from the UK to Germany you transit Belgium and the Netherlands). That's a deal then. Actually we had already gone ahead and done most of the changes so I am glad you agreed with us! Regards, Peter Cheers, Christoph ___ 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
[Talk-transit] New 'Transit' page and proposed Stop Place model
I have create a new top level page for 'transit' and redirected 'public transport' to that page. Take a look here and tell me what you think, and do of course make it better! http://wiki.openstreetmap.org/wiki/Transit I am also proposing to write basic articles for each of the individual modes that I have identified (currently the 'main' articles referred to are mostly to redirects to a tag page which isn't sufficient). Do you think Tram should be included in Rail or be discussed separately? You will also notice that I am also plugging a proposal I am developing for a new consistent Stop Place model ( based on Oxoma's proposal) which you can read about here: http://wiki.openstreetmap.org/wiki/User:PeterIto/Stop_Place Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] New 'Transit' page and proposed Stop Place model
On 6 Aug 2009, at 14:07, Frankie Roberto wrote: On Thu, Aug 6, 2009 at 11:40 AM, Peter Miller peter.mil...@itoworld.com wrote: snip b) splitting the pages down into smaller components - eg railways, bus stops, train services, train stations, etc. Whilst it's good to have an overall conceptual model, I think most mappers will be more interested in understanding how to tag at a feature level. Umm.. I think it is important to have a page for the conceptual model and then when we are happy with it, we introduce it into the other articles in the context of that transport mode. A description of a Stop Place for a drag-lift will be pretty different from that of an airport, but I am keen that there is a consistency across modes from a programming and tagging perspective. I think I more-or-less agree. I'm mainly just keen that we keep the discussion embedded in the context of actual usage (with plenty of real-life examples) rather than being too abstract. Ok, I completely agree that someone who wants to model a railway station should have to look no further that the train page (or railway station page) and should gets lots of great examples of how to model stations (and nothing about drag-lifts!). However... I also want there to be a good robust general purpose model behind it (what I call the Stop Place) and that also needs a page that the developers look at when wondering how to model the world efficiently (including drag-lifts and Manchester Airport!). I think we should also remove the redirect from http://wiki.openstreetmap.org/wiki/Key:public_transport and turn that into a standard Key page (with the KeyDescription infobox) documenting existing and proposed usage of the key. Likewise, it'd be useful to have the relevant tag and key pages for all the other tags and keys that are in use or proposed. It is certainly not appropriate for it to redirect to a user page. For now I have redirected it to the Transit article until someone fancies adding some content, however I am not clear if we even want a key of that title, should we not standarise on Transit rather than public transport. The proposed use of the tag is something I would prefer to call stop_place anyway. I agree that whether we need the key or not is unclear. However, since there's at least some usages of it currently, I think it's worth documenting what the existing practice is at least (same for other tags with significant usage). fine by me This reminds me - I think it'd be worth encouraging people here to share links to OSM for public transport stops/routes/etc that they've mapped, for feedback and discussion. I did this a while back on the discussion page for the unified_stoparea proposal (see http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/unified_stoparea) In this spirit, here's what I've mostly done so far: Oxford Road train station (http://www.openstreetmap.org/browse/relation/78910 ) - mapped the platforms as areas (railway=platform, role=platform) - mapped all the tracks, and the stopping points (role=halt) with one of them marked as the 'main' one with railway=station and a name tag. - station building outline (building=yes, no role) - footbridge and steps (not part of the relation - wasn't sure whether they should be?) Have started to map the tram system in Manchester as two separate tracks (http://osm.org/go/evgo1FaS--) though this is complicated by the sharing of ways with the highway, and the current part-closure of the system for track replacement. Mapping UK tram system routes as relations (see http://wiki.openstreetmap.org/wiki/United_Kingdom_Trams) Mapping UK 'minor railway' routes as relations (see http://wiki.openstreetmap.org/wiki/WikiProject_United_Kingdom_Independent_and_minor_railways) I suggest we have a list of 'examples of good practice' associated with each page. the Tram page should like to good examples of Tram modelling and also all the tram related projects and email list around the world. Similarly the Train / Railway page would do the same for trains. I suggest the Stop Place page might give some examples of a few of each sort of Stop Place, including a real monster multi-modal interchange (JFK, Heathrow or Schipol). Regards, Peter Would welcome comments on any of those - and would love to see which bits of the map other people are working on! Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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] Railway route relations
On 4 Aug 2009, at 23:37, Frankie Roberto wrote: Hi all, I'm still keen to try and nail this public transport service vs infrastructure issue. I have create a new wiki-page 'Public transport schema 2' based on Oxomoa's proposal on the main wiki based on the last edit made before the big revert. I have added a bit of information about the relation you refer to in the 'infrastructure' section , but more is needed:- http://wiki.openstreetmap.org/wiki/Public_transport_schema_2 This is very much a proposal to discuss and develop which I see it as being the top-level transit description which links out to more detailed articles (some of which already exist) to create a coherent whole. Regards, Peter I think this mainly applies to railways, however, as I've mentioned before, I'm trying out a few of the ideas on the UK's much smaller list of tram networks. http://wiki.openstreetmap.org/wiki/United_Kingdom_Trams details where I've got to so far. The Tramlink in Croydon (London) is a good example of where the the infrastructure (the track network) is clearly different from the tram service patterns (routes 1 to 3). The routes are currently mapped with a relation tagged as type=route, route=tram. I've just created a relation for the network as a whole (see http://www.openstreetmap.org/browse/relation/189917) . For the type being, it's tagged as type=network, network=tram as well as public_transport=network from Sebastians proposal. Are there any other views on how this should be tagged? Perhaps the network shouldn't be tagged at all, under the relations aren't for categories principle? I'm also of the opinion that we should stick to using type=route, route=tram/railway for the train/tram service patterns, rather than the infrastructure. However, this appears to be the opposite of what's written in http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema Thoughts? Frankie On Wed, Jul 29, 2009 at 10:25 PM, Frankie Roberto fran...@frankieroberto.com wrote: On Wed, Jul 29, 2009 at 8:27 PM, Jochen Topf joc...@remote.org wrote: The first question is what does route=railway denote, the infrastructure or the service pattern? This has been solved in Sebastians proposal: http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Differentiation_between_railway_lines_and_railway_routes Thanks for the link, I hadn't seen this. I agree with Peter that we need to bring these various proposals together, form some kind of consensus, and document it fully on the main wiki pages (eg http://wiki.openstreetmap.org/wiki/Routes) Interestingly, if I understand it correctly, the division between route and line in Sebastian's proposal is exactly opposite to what I'd intuitively have guessed at from the words. eg, we have the West Coast Main Line (the infrastructure or rail corridor) and the route of the Flying Scotsman (the schedule service route). So if it was me, I think I'd name them the opposite way round. However, so long as we document them clearly (with examples), I guess it doesn't matter too much which words we use. As a first step, I think it'd be useful to look at some concrete examples, see how they're currently tagged in OSM, and suggest ways in which the various schemes would be applied. I've started doing this a bit with the UK's tram networks (http://wiki.openstreetmap.org/wiki/United_Kingdom_Trams ), which so far use route=tram to tag the service patterns of the trams (which seem to sometimes be called lines, and sometimes routes). -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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] Route relations types
On 5 Aug 2009, at 13:05, Frankie Roberto wrote: On Wed, Aug 5, 2009 at 12:38 PM, Roger Slevin ro...@slevin.plus.com wrote: Before anyone answers your question, please bear in mind that there is no clear definition of a “coach” ... and I have dealt with a feedback to traveline on this very point only this morning. A limited stop service between Cambridge and Oxford operated by vehicles which have “coach-style” seats and which the operator refers to as “coaches” runs a limited stop service between the two cities (the X5) – so we call this a coach. The complaint came from someone who had been unable to find this service as a “bus” because he saw a “coach” as being something which you had to prebook, and which expected a significant number of passengers to have luggage which went into luggage lockers under (or at the back of) the vehicle. Whilst I agree that there's no hard-and-fast distinction between buses and coaches, I think that using route=bus-coach is just going to confuse people! I'd suggest using either route=bus or route=coach, and simply going with whichever feels most correct (based upon what the route calls itself or how people generally refer to it). This doesn't resolve the potential ambiguities, but renderers and routing software would be advised to use a bit leeway when doing searches. I understood that one difference in the UK is if it was under 50km the operator could reclaim tax on their fuel. There is also evidently a 50 km rule about tachographs, where drivers operating longer routes need tachos, but ones on shorter routes (urban buses) don't. I think it is also useful to distinguish the sort of seating. I was on a coach last week, big leather seats and air-conditioning - very comfortable and reasonably quick. No toilet which surprised me, but it was only a 1 hour journey so I guess that is fair-enough. The experience of using a normal urban bus would have been very poor in comparison and I wouldn't have taken it. Personally I would vote for the distinction to be retained on the basis of the distance and type of vehicle. Regards, peter Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ 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] Railway route relations
On 5 Aug 2009, at 13:13, Richard Mann wrote: On Wed, Aug 5, 2009 at 1:12 AM, Cartinus carti...@xs4all.nl wrote: IMHO the solution is simple. Name it after what you are mapping. For vehicles: The route the cyclist follows is route=bicycle. The route bus 5 follows is route=bus. The route tram 13 follows is route=tram. The route the Eurostar follows is route=train. For infrastructure: The route of the M1 is route=road The route that is made up of the rail tracks of the East Coast Mainline is route=rail. Deprecating route= and replacing it with line= for most things where we currently use route= is a lot of work for no real gain. -- m.v.g., Cartinus ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit +1 Though I'd go for route=railway for infrastructure, since route=rail is currently being used by a lot of relations for which route=train would be better. Do check out this new wiki page: http://wiki.openstreetmap.org/wiki/Public_transport_schema_2 I have done some work on the top level modelling for transit information based on Oxoma's work. I am proposing that we use Lines, Line Variants and Routes for the actual services in a similar way to the original proposal. Lines are pretty much unchanged. Line Variants used to hold a stop list and also the route through the infrastructure. I have split this into Line Variants for the list of stops, and Routes for the path through the network (this approach saves work as it allows Routes to be reused on more than one Line Variant). It is also the modelling used by Transmodel which will be helpful when we start getting more EU schedule data. Routes are pretty much the same as cycle routes, ie a single path through the transport network. I have added a basic infrastructure route proposal, but have no strong feelings about what tags we use. With regard to updating what is already in OSM then I suggest we use write some tools to do the job. Frederik has already offered to some support for this (and he recently did some automatic cleanup on tiger data in the USA) using a similar rule-bases approach. Regards, Peter Richard ___ 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] Railway route relations
On 5 Aug 2009, at 14:41, Richard Mann wrote: Yes Frederik could tidy things up, but it's best not to change things arbitrarily (ie substituting line for route), because it just makes it harder to remember what is correct. The lack of presets for relations in Potlatch makes it doubly useful to minimise the complexity. I totally agree, however we are just setting out on a long journey to capture all the transit data for the world, so lets get the modelling clear now and not be held back by some tag-updating! As we are aware the various transit strands and proposals were initially created bottom-up in a rather random way (which is the nature of these projects). Oxomoa then did a good review of the tagging and identified a number of gaps and inconsistencies with the German community which started to bring it all together. We have also had some useful input from the professional transit community. I suggest that we put significant effort into the wiki and modelling at this point to get all the transit related pages to fit together in a consistent way to our liking and that this will pay big dividends in the future. Regards, Peter Richard ___ 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 Import
On 1 Aug 2009, at 22:51, Thomas Wood wrote: 2009/8/1 Christoph Böhme christ...@b3e.net: Thomas Wood grand.edgemas...@gmail.com schrieb: I think all outstanding coding issues have now been dealt with. There's one minor tagging issue to address - should the source tag be on the data or changesets. Since the source tag applies to the whole changeset it makes sense to tag only the changeset. However, I believe editors do not display changeset tags at the moment. This means changeset tags are basically not visible when you edit data. While it can be handy to see the source of an element when you edit it (e.g. I'm much less relucant to move NPE-sourced data if it does not fit with my tracks than surveyed data) this should not be a problem with the naptan-import. The naptan:-tags are a very obvious hint where the data is coming from. So, I'd vote for placing the source-tag at the changeset. Otherwise, a test upload of the Surrey data is visible here - http://api06.dev.openstreetmap.org/browse/changeset/394 Comments welcomed. Could it be that the tags are missing? All the nodes I have looked at are empty (http://api06.dev.openstreetmap.org/browse/node/416977, for example) Ooops, I linked the wrong changeset! http://api06.dev.openstreetmap.org/browse/changeset/389 was my intent. A couple of comments. Firstly, the locality field is an important part of the name in NaPTAN. The stop name can be constructed in a number of ways depending on how much precision is needed and what the geographic context is. For example, let's take this stop outside a pub called 'The Woodman' (which is in Ashteed). http://api06.dev.openstreetmap.org/browse/node/396115 If the context for the enquiry was Ashteed itself, then one could say 'The Woodman (Adj)'. If the context was wider and one still needed to be precise one would say: 'Ashteed, The Woodman (Adj)'. Localities themselves are not always unique so there is the possibility for a locality to have a qualifier in NaPTAN. The full description for a bus stop called 'Long Road' in Cambridge in Cambridgeshire (rather than the one in Gloucestershire) would be 'Cambridge (Cambs), Long Road (opp)'. If the context was east anglia then one could drop the qualifier and it would become 'Cambridge, Long Road (opp)'. If the context was Cambridge itself then one could use 'Long Road (opp)'. So... what to do. I suggest we need a naptan:locality field which should contain the naptan locality name or possibly also naptan:natgazid as a unique reference for the place (to accommodate multiple localities with the same name). I am not clear what we do, but we need to do something. Regards, Peter We're then ready to begin uploading to the main database. Cool :-) Cheers, Christoph ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
On 27 Jul 2009, at 22:14, Christoph Böhme wrote: Hi Roger Slevin ro...@slevin.plus.com schrieb: Locality Classification was added as a possible nice to have to the version 2 schema but it has not been populated, and no guidance has been created to indicate how this field should be used (save for a table of permitted values). There is no classification data in NPTG other than that which comes from the source - and that is only there because it could be ... I would not recommend its use as it is flaky, and offers nothing in respect of newly created locality entries in the Gazetteer. So, it looks like we will not have any classification information. Unless we just want to import the plain names this will complicate the import a bit as we have to somehow map the locations to OSM place- types. At the moment I am having three ideas how we could do this: Based on the parent relationship we could guess if a location might be a suburb or village. Many places have wikipedia entries (even villages). If we can manage to automatically look the entries up and extract the relevant information (population size) from the info box we could probably classify a lot of places. The landsat data might give us some hints about the size of places. We just need to find a way to retrieve this information automatically :-) Alternatively we could just invent a value for unclassified places and wait for people to classify the places. It seems that the NPTG data is less useful than it could have been because the the lack of classification data. We do of course also have access to locality names from other sources including NPE maps for places that are more than 50 years old and our eye-balls. Possibly we just provide NPTG data as a useful 'free' data overlay for creating localities in OSM in association with data from NPE but don't spend too long trying to do an automatic import of that data. You mention matching localities up with Wikipedia. I see no licensing issues with using data from Wikipieda as far as I am aware btw. Would be great to tie places up with Wikipedia and possibly also with woeids (http://developer.yahoo.com/geo/geoplanet/) but that could be something for later. Regards, Peter Do you have any other ideas? Cheers, Christoph ___ 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 import
On 28 Jul 2009, at 18:41, Christoph Böhme wrote: o...@edwardbetts.com schrieb: Christoph Böhme christ...@b3e.net wrote: Many places have wikipedia entries (even villages). If we can manage to automatically look the entries up and extract the relevant information (population size) from the info box we could probably classify a lot of places. I'm afraid we can't use population data, it is under Crown Copyright. I don't know much about the licencing but I find it slightly odd that Wikipedia can distribute its contents under a CC-BY-SA licene when it contains information that is under a more restrictive licence. How am I supposed to know that population numbers are not covered by the CC-BY-SA licence? I don't want to start a huge discussion here about the legal issues of using the population numbers. I'm just curious to learn why Crown Copyrighted data can be in Wikipedia. All information in Wikipedia must be sourced from elsewhere because it must be verifiable. (see http://en.wikipedia.org/wiki/Wikipedia:Verifiability) References should be to reputable sources, such as top newspapers etc. There are guidelines ensuring that copyright material is not used excessively (http://en.wikipedia.org/wiki/Wikipedia:Non-free_content) but in summary it seems that as long as an article is made of information taken from many sources and written for Wikipedia and is not cut and pasted from one source then it has been 'freed'. It is then possible to take information from Wikipedia and reuse it with acknowledgement as per the following: Permission to reproduce and modify text on Wikipedia has already been granted to anyone anywhere by the authors of individual articles as long as such reproduction and modification complies with licensing terms (see below and Wikipedia:Mirrors and forks for specific terms). Images may or may not permit reuse and modification; the conditions for reproduction of each image should be individually checked. The only exceptions are those cases in which editors have violated Wikipedia policy by uploading copyrighted material without authorization, or with copyright licensing terms which are incompatible with those Wikipedia authors have applied to the rest of Wikipedia content. While such material is present on the Wikipedia (before it is detected and removed), it will be a copyright violation to copy it. For permission to use it, one must contact the owner of the copyright of the text or illustration in question; often, but not always, this will be the original author. http://en.wikipedia.org/wiki/Wikipedia:Copyrights Regards, Peter Christoph -- Edward. ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Change of settings for talk-transit
Just to let you know that I have added Frankie Roberto as an admin for the list as per an earlier discussion. Thanks for helping out Frankie. I have also changed the setting for talk-transit so that replies go to the whole list by default which seemed to be what the majority who expressed a preference wanted. Regards, Peter ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Railway route relations
On 6 Jul 2009, at 21:24, Melchior Moos wrote: Hi, 2009/7/6 Brian Prangle bpran...@googlemail.com I've experimented with the section of the West Coast Mainline between B'ham New St and B'ham International: I've added a train (i.e service) relation with ref=WCML and also a railway (i.e physical) relation with ref =17.01 ( the SRS for the section of track) to see how it rendered in opnvkarte. I'd appreciate people's opinions now the render engine has caught up. Personally I don't like it and I think the physical stuff is better tagged on the ways; opnvkarte is a public transport map and should show services My interest in infrastructure relations is not very high, the only reason I'm rendering them is, that there were (or maybe are) some service routes that are tagged with route=railway. Rendering them enables people to see the fault. The main focus of öpnvkarte lies on the service relations. I think the problem is that we are using the term Route for at least two different things. Are there not reasons why one might what to create a relation for the West Coast Main Line 'infrastructure/ physical/track' or the East Suffolk Line 'infrastructure/physical/ track' or a particular SRS section 'infrastructure/physical/track' as distinct from path used by a particular rail operator or by a particular public transport service? Should we not provide a way of doing both even if both are not always populated? Why do we not proposed a different way of coding relations for the railways, SRS sections etc and ensure that these are not rendered on opnvkarte rather than dump the whole idea? Personally I see this being a very useful piece of information about the Peterborough to Ely line and like the way the relation overlays on the slippery map for more detail: http://www.openstreetmap.org/browse/relation/142758 (relation for Peter to Ely line) I have done something similar for the Cambridgeshire Guided Busway which I have found very useful http://www.openstreetmap.org/browse/relation/164711 Regards, Peter regards, Melchior ___ 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] [Talk-gb-westmidlands] NaPTAN and the new PTtagging schema
On 26 Jun 2009, at 17:51, Andy Robinson (blackadder-lists) wrote: Peter Miller wrote: Sent: 26 June 2009 4:41 PM To: Thomas Wood Cc: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org Subject: Re: [Talk-gb-westmidlands] [Talk-transit] NaPTAN and the new PTtagging schema Your suggestions below make a lot of sense. I would however very much encourage you to include customary stops because they do indeed 'exist' even though there is no physical pole. Consider a road that doesn't have a name plate but when you people who live on the street what it is called they tell you. Does the street have a name or does it not - I suggest we would agree that it does? If a tree falls in a wood and there is no one to hear it did it make a sound etc. Customary stops can be confirmed by looking for physical marks of vehicles stopping or people standing around on the grass, from information at the stop opposite or from asking bus drivers. I would suggest that for now we believe NaPTAN. These are easy to add in a final cleanup anyway, just by usage of the route. The problem with the NaPTan data is that there are loads of stops that are probably just not used at all, hence we leave them turned off (silent data). I agree that we could and probably should import customary stops but I don't think we should assume they are actual in-use stops and hence should leave them silent in the database until someone confirms and adds highway=bus_stop For other areas of the country I think its fine (with the exception of CUS stops) to go ahead straight away and add the highway=bus_stop where there are few existing mapped stops. Ideally a post to the local uses in the area would confirm either way what they would like to do. You seem to be putting out different messages in the two above paragraphs. Are you saying you support the import of CUS stops or not. Also are you suggesting that bus stops are set as 'real' (ie active) stops. Possibly Roger will have some views on how many unused stops there are likely to be in the dataset. Looking at the Oct08 dataset there were 365,000 bus stops and 42,020 of them were unused at the time however this doesn't necessarily mean that they don't exist, only that no buses currently use them - in some cases they could be stops for summer-only services. I suggest that we should include all bus stops in the dataset regardless of use. We should removed stops that don't physically exist if there is no sign of them on the ground. Customary stops might need a visit to the friendly local bus operator who probably has all the information in his head. Physically marked stops can be checked by cruising the bus routes. Beyond that the only bit of data I dislike from the original run is the unverified=yes tag. It would be better to change this to verified=no for future imports (and easy to swap in West Mids.) sounds good Otherwise my experience in Brum is generally good in that with the exception of location (which is 10m to 100m off at least 50% of the time) the NaPTAN data matches the data on the ground very well. The accuracy will vary across the county and will reflect the care taken by each authority. I would expect it to be better in most places but might be proved wrong! Having a map that shows the bus stops would seem to be a good step to getting it improved by doing a physical survey or asking bus drivers to comment. If the data is hidden in the maps and not exposed it will be harder to sort out. I vote for having the data introduced as fully visisbly data but possibly we do it county by county. I am happy to be an early recipient of data for Suffolk and I think Ed Loach is keen to see the Essex data. Regards, Peter I know Brian and others have documented a few oddities here: http://wiki.openstreetmap.org/wiki/NaPTAN_Error_Log Cheers Andy Traveline would strongly advocate for their inclusion so that OSM links seamlessly to their journey planners. Regards, Peter On 26 Jun 2009, at 16:21, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: On 24 Jun 2009, at 18:20, Thomas Wood wrote: 2009/6/24 Peter Miller peter.mil...@itoworld.com: Can I suggest that we treat this import and any final tagging as a separate issue on separate timeline from the NaPTAN import just so long as no important information in the NaPTAN DB is lost in the process. Can you clarify what you meant by this? Is it essentially that we don't care about the new tagging schema and get on with the import? Yes. I would suggest that to avoid trying to agree a new tagging arrangement in a hurry prior to the import and keep the two projects separate. Firstly we import the rest of NaPTAN as agreed in the original discussion, and then secondly we agree a harmonised tagging arrangement of some sort and convert all the data
Re: [Talk-transit] [Spam] Re: Multiple tracks
On 22 Jun 2009, at 12:53, Richard Mann wrote: On Roger's point about sidings - I'd map those as a separate track group, since they are the sorts of things people would expect to disappear at lower zooms. So north of Oxford station, I'd have the 4 down carriage sidings as one group, the four running lines as one group and the 4 up carriage sidings as a third group. Within each of those three groups, you could either do the individual tracks (as 1of4), or the tracks as a group (tracks=4). On loops, I'd probably exclude them from the running lines group, and use other tags (perhaps has_loops=yes) to tell me that there are extra tracks for a short-distance. You might also do has_loops:left and has_loops:right, but one-sided rendering is on the tricky side. So just south of Oxford at Kennington, you'd have the two running lines as tracks=2 (or 2xtracks=1of2) with has_loops=yes. If I had done the two tracks separately, the renderer would be entitled to expect me to have done the freight loops separately as well, so they can ignore has_loops=yes at high zooms, and just render the ways that have been drawn. Can I suggest that as a start you create the detailed track layout and then we can look at different grouping strategies and see which ones the Mapnik people and routing people will find useful. Whatever you do should work for rail and trams and I see no reason for there not to be generality with roads. Lets not worry too much about the wrapping until we have stuff to wrap. For your interest, here is an example road interchange which can be rendered as a dot if required, or used in driving instructions as 'turn left at the 'Whitehouse Junction'. http://www.openstreetmap.org/browse/relation/2470 Here is a dual-carriageway example - just bind all the parallel ways together and a renderer can then do a line down the middle at some point. http://www.openstreetmap.org/browse/relation/2490 Here is a railway station where all the elements (including tracks, sidings, platforms, buildings, car parking, taxi ranks and cycle racks) are all part of a relation. http://www.openstreetmap.org/browse/relation/2522 And here is a sample rail junction wrapped up using a relation:- http://www.openstreetmap.org/browse/relation/162263 This should make it very easy for a renderer. The general rule is 'if you can't fit in all the detail on the map and it is part of a relation then do a single dot or single line for the whole thing. Regards, Peter Richard On Mon, Jun 22, 2009 at 10:45 AM, Roger Slevin ro...@slevin.plus.com wrote: As someone who doesn't have the experience of mapping that you all do, but I do know something about public transport, I can see how the various concepts for single track and double track etc work along straightforward corridors (note these must be tracks (or maybe some other term) and not lines - as a line in public transport is something completely separate from the infrastructure) ... but what happens when operational details get more complicated ... at stations, or near and in depots and sidings? What happens for passing bays? Does a track have a directionality associated with it (even if it is only implied by a national convention of driving on the left/right... though that will give some issues on the German border where operations switch sides) - and what happens when multiple tracks are signalled for bi-directional working? I sense that there is a potential issue here between describing the physical infrastructure and describing its functional performance ... and I am not sure the boundary has been drawn correctly between the two. Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Peter Miller Sent: 22 June 2009 10:31 To: Jochen Topf Cc: osm Subject: Re: [Talk-transit] Multiple tracks On 22 Jun 2009, at 07:51, Jochen Topf wrote: On Sun, Jun 21, 2009 at 05:09:35PM +0100, Richard Mann wrote: No, simpler than that: tracks=1 = render a single line at all zooms tracks=2 = render a double line at all zooms tracks=X = render a multiple line with X tracks at all zooms tracks=1ofX = render a single line at high zooms, but render as if tracks=X at medium/low zooms But then you'd still draw several lines nearly on top of each other in medium zoom levels which doesn't look good, which was the problem we were trying to fix? Anyway, this is a rather specialized trick about rendering the number of tracks properly. But what if you want to render other attributes. Say one of your two tracks is an industrial railway, the other a normal passenger railway and you want to distinguish those types. On medium zoom levels, is this a two track thing and we loose the type distinction, or do we keep it? The dual_carriageway and Junction relations would appear to the a good way of doing such things
Re: [Talk-transit] Public transport workshop in Germany
On 1 Jun 2009, at 23:09, Sarah Hoffmann wrote: On Mon, Jun 01, 2009 at 08:05:30AM +0100, Peter Miller wrote: For railway stations it can be sure that there is exactly one symbol on the line of the railway neatly aligned to the middle of the way. With the new schema a lot of preprocessing and guess work will be required to get the same result when stop places contain multiple stopping places and/or access points. The current situation with bus stops is more messy. (Just see Birmigham which seems to entirely consist of bus stops.) While stop places in the new schema allow to clean this up a bit, again, the renderer only has the choice to either paint two many symbols (all access points or all stopping points) or badly guess where to put the single point. Which rendering view are you using? for the main Mapnik view on openstreetmap there are no bus stops until one zooms in to zoom 17 at which point there are certainly lots of bus stops (accesses). Yes, I had Mapnik in mind although the problem is a more general one. There are no bus stops for lower zoom level because they would completely clutter any map. Even at zoom level 17 it may be appropriate to render bus stops at the Stop Place level of detail (with one blob for two Accesses/bus stops on either sides of the road, or one blob for three Accesses/bus stands in a row on one side of the road). Rendering the Stop Place is only useful, if there is additional information available, e.g. the name. But how this can be displayed without overwhelming the user is an unsolved problem indeed. However, I was hoping of resolving the rendering of the lower zooms first. A Stop Place should have a name - I believe that is part of the definition of a Stop Place that it does have a recognised name. However it may sometimes just be appropriate to to put a single dot on the map for a Stop Place without a name and will be less cluttered that every Access. Actually, looking at Birmingham in the ÖPNVKarte http://www.öpnvkarte.de/?lat=52.47884lon=-1.89495zoom=17 I see that all bus stops in the inner city belong to the same stop place, namely city center. I know that this is very common in the UK (and very frustrating for the visitor, but that's another story). How would you fit that into the proposed model? A stopping place and access point for each bus_stop and then all of them into one stop place relation? Subdivide them by street? How do the regular users see them, as single bus stops or as quais of one and the same stop? To be clear. Birmingham City Centre is too big to be a Stop Place (where all points should be within a few minutes walk from each other). 'Birmingham City Centre' is actually a locality name in NaPTAN. Localities are used for named settlements or suburbs. Some authorities create a locality for the centre of large places. Thus, if above example is modelled as two stop places with oneway=yes and both stop places are put into a stop place group Waffenplatzstrasse (together with the two bus stops, which are incidentally directional as well) all necessary information for the renderer should be there. Is this within the intended use of stop places and stop place groups? The Wiki is not very clear on this point. I agree that a direction does seem to be needed, both for the Stopping Places and also possibly for the Accesses. It is not clear how one should code the direction - A one-way tag doesn't seem to encode all the necessary information. This would be more a directional information that encodes in which direction the vehicle will continue its journey from the stopping point. This would indeed suffice. Unfortunately, it brings us back to the still unresolved question of forward/backward tagging, which seems to go nowhere. In NaPTAN the Accesses (bus stops) have a bearing N, NE, E etc, in which the vehicle leaves the stop. Slightly tricky to interpret with the mapping data, but the NaPTAN dataset if road dataset neutral so can't reference any particular road data set (OS, OSM, Navteq). I would expect that Waffenplatzstrasse would consist of one Stop Place with two accesses and two Stopping Places. Is that sufficient or should each Access have its own Stop Place and these be grouped into a Stop Place Group? If one uses one Stop Place then how are the individual Accesses and Stopping Places associated with each other? The Accesses need names that indicate direction, such as 'Northbound', 'towards city centre', 'Sto A', 'Stand A', 'Bay A', Gate 13' etc. In the UK this information is encoded in the 'indicator' field and the Name for the Access (called Common Name) tends to be shared with the other Accesses in the Stop Place. Do you mean stopping place here? I'd expect this indicator to be unique for all accesses in a stop place. It is good practice (that is not always followed or appropriate) for all Acesses
Re: [Talk-transit] Public transport schema
On 2 Jun 2009, at 18:18, Thomas Wood wrote: 2009/6/2 Sebastian Schwarz y...@kahlfrost.de: Hi! Well, I have been en-route the last days and thus did not have time to respond to any of the numerous mails covering almost all aspects of the new proposal relating to public transport. But I see the discussion sort of loosing sight of the mappers. From my point of view, we should find a good compromise which primarily serves the mappers and not the CEN. So, the schema should not be as compliant as possible to the standards but as good as possible for the mappers - provided with a reasonable part of standard compliance, of course. We do not want to model Heathrow Airport (apart from that, airports have never been part of the proposal!) but we want to start with the bus station around the corner! But by it's nature as the foundation of how transportation stop areas are represented in OSM, then airports are important as a higher tier of transportation. By their nature, they'll often have several other modes of transport related to them, metro, mainline rail, bus and coach services, and they should still be seen by routing software as an interchange that could be possibly used. In time, we will want to map them in excessive detail, whilst we have the opportunity, this scheme should allow the scope for further expansion of other transportation types. Firstly, can I say again how much your proposal is appreciated. We have needed to do a thorough review of PT related tagging for consistency for some time and your work is a great starting point. Secondly, can I apologise for tearing into you document and I hope we haven't ruined you thesis but from a Wikipedia perspective this is how good articles get written. People build something, others build on it, some changes stick, some get challenged and removed, but the general direction is positive. Your work certainly isn't going to gather dust on some shelf but will be used with a vengeance very soon - I just want to make sure that we do the design work at this stage to ensure that it is robust before it gets extensively used. With reference to mappers, I really don't think we are making things much harder for the average mapper are we? Once we agree on terms and definitions that is. We have rationalised platforms and bus stops and ferry quays into Accesses. We have renamed Stop Areas as Stop Places. We have added Stopping Places and Stop Place Groups. We are proposing a new relation binding from Accesses to Stopping Places. I am proposing that we added Entrances and Boarding Points, but all these are optional extras to the modelling and not something that the average mapper needs to touch to start with. Regarding Heathrow Airport. The coach/bus station within the airport is the busiest in the UK (http://www.milesfaster.co.uk/information/heathrow-airport/heathrow-central-bus-coach-station.htm ) and we will of course map transport interchanges in absurd detail when we run out of other things to do! CEN: My experience is that one has to be careful when one doesn't follow standards or ignores them; the old rule, 'if you can't be good be careful' comes to mind. For sure, there is some nonsense in standards for geopolitical reasons, but transmodel is pretty clean and so is IFOPT. If you cut corners in relation to a CEN standard you can expect to come unstuck in some situation that you hadn't considered and then you will have to bodge it. For example by assuming that each stopping place has only one Access and one Access is only associated with one Stopping Place. I know that because I have been there and done it! What we have already is very good - we are not slavishly following CEN, but as far as I am concerned we follow it where appropriate and are now aware of the places where we are not following it and we are confident that we are doing it for a good reason and that it will work. The only section that has not been reviewed in relation to CEN is the section about Railway Routes, Railway Lines and Line Variants which again is close but we can still learn from CEN and clarify the language. Ok... Um Well... So I have now just looked at the current version of the document and noticed that you have reverted just about all my changes over the past few days. I find that rather unnecessary and I would like to have some clarification about why that was necessary or useful to do that without consultation. For sure some changes could be challenged, but all of them? No one else had challenged them on the list on the wiki since Saturday. Fyi, Here is the difference between the version just before I made my first changes and the current version (they are basically the same). http://wiki.openstreetmap.org/index.php?title=User:Oxomoa/Public_transport_schemadiff=280182oldid=278379 And here is the difference between the last version I touched and the
Re: [Talk-transit] [Talk-gb-westmidlands] Naptan alignment
On 31 Mar 2009, at 13:23, Andy Robinson (blackadder-lists) wrote: I've already started correcting data like this. I too have noted that some stops are not correctly positioned in relation to the road they are on. Where we only have a single trace along a road they could be correct but the ones I looked at last night where we have plenty of traces (main road) were in some cases either too far back or too close to the centreline of the road. I also fond some possible referencing errors for bus stop pairs on either side of the road but need to resurvey as a double check. As of my mapping session this morning I'm taking my bike right up to the stop and taking the photo from directly under the sign. That should help see what sort of positional errors exist in the data. The only problem is that I'm mapping Walsall and so need more imported data before I'll know ;-) Import looks good. A few points: 1) The bearing is useful to ensure that the stop is put on the correct side of the street) . Normally the stop will already be on the correct side using the lat-long, but if the stop in misplaced by poor GPS then we could place it on the wrong side. I did find one that was on the wrong side of the street in the OSM environment using the bearing from the official data. 2) Some Naptan records seem to be missing in OSM. In the case where there is already a bus stop in the right place is the Naptan record just being deleted in the review pass? If so then important data for maintenance is being lost. I would suggest that the two records are merged to ensure that there are NaPTAN codes for every stop. 3) I find it interesting that in some places OSM has bus stops that are not in NaPTAN, that might be because they have been removed recently or be an omission in NaPTAN. 4) I notice that sometimes the NaPTAN stop and the OSM one are some significant distance apart which begs the question about which one is right. Anyway, it looks like the detective work is now starts! Great work. Regards, Cheers Andy -Original Message- From: talk-gb-westmidlands-boun...@openstreetmap.org [mailto:talk-gb- westmidlands-boun...@openstreetmap.org] On Behalf Of Brian Prangle Sent: 31 March 2009 9:46 AM To: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org ; Thomas Wood Subject: [Talk-gb-westmidlands] Naptan alignment Thomas I've also looked at Google maps and their alignment is off too in exactly the same way ours is in areas I know well and have surveyed, so I guess it's down to the NaPTAN data. There are examples where I know the bus stops are in a row along the street (Corporation Street and Acocks Green Village for example) but NapTAN has one or two skewed from the line by several metres. Currently I favour correcting the NapTAN data to what we know on the ground, but until a consensus emerges I'm laying off the urge to correct it. Regards Brian ___ 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] [Talk-gb-westmidlands] NaPTAN data import
On 6 Mar 2009, at 13:17, Peter J Stoner wrote: There is a file StopPlubusZones.csv in the West Midlands NaPTAN which contains a list of 12107 bus stops. I have taken these to be all the stops within the West Midlands PlusBus zone. http://www.plusbus.info/stations/station.php?item=1811back= Ok, so if a plusbus zone it is a list of bus stops then it is probably a relation not a polygon. To be clear I don't think anyone is suggesting we should never import Plusbus zones, it is just a matter of if it is in the first pass and at the end of the day that is going to be up to the person writing the code! Great stuff, Peter -- 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] [Talk-gb-westmidlands] NaPTAN data import
On 6 Mar 2009, at 18:28, Andy Robinson (blackadder-lists) wrote: Gerrit - NaPTAN references nodes as being part of a StopArea, somewhat like our relation structure. The converter is already pulling them in according to the unified stop area spec. (Except for not having the stop-points on the road way, just beside, but thats just a moot point) In the EU a Stop Point is the place that the person waits for the vehicle, which is beside the road/track and the place where the vehicle stops in called a Stopping Point is on the road/track. Can we agree that a Stop in OSM is the same as a Stop Point and is therefore correctly positioned beside the track. What OSM is proposing to call a Halt is on the track and is the same as a Stopping Point. The unified Stop Area proposal is a great one to settle this one for good for all public transport modes. I do hope we can drop that as a 'moot point' soon! http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea Regards, Peter -- Regards, Thomas Wood (Edgemaster) Cheers Andy ___ 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 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 def74e78d2f74302bdf48ad40609a...@redsol Roger Slevin ro...@slevin.plus.com wrote: Thomas You comment that York doesn't appear to be aware of the stoparea principle ... this is widespread. There are no downstream
