[Talk-transit] Multiple ref=* on route=train
Hi! The local rail transport company has a timetable where each departure has its own ref. So a train goes from A to B in the morning, and that has a ref 8005. Then it goes the same route an hour later, and that is 8007. Anyway, during the day, the same route is done 21 times, and tags on my relation look like this: https://www.openstreetmap.org/relation/7251329 Does this make sense? Do other companies have the same way of putting refs on their departures? How do you deal with it? Thanks, Janko ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Long bus routes
On Mon, Aug 5, 2019, 13:20 Dave F via Talk-transit < talk-transit@openstreetmap.org> wrote: > > > On 02/08/2019 14:35, Janko Mihelić wrote: > > I think they should be mapped as relations with only stations in the > relation. > > How would you perform real-time tracking? > An app would route from one station to the other, and show status as if you were driving. There could be a tag that would say if the route goes through motorways, tolled roads, ferries and so on. That would help the app determine what would be the route. Route times could be written in the tags. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Long bus routes
A user in Europe started adding long bus lines some time ago. These routes are crossing several countries and mostly drive along motorways. Here is a piece of motorway between Berlin and Dresden: https://www.openstreetmap.org/way/313980637 it has two road routes, and 13 Flixbus bus routes. I think this can't be sustainable. If all bus companies started adding these routes, we could have a hundred or more relations on motorway ways. Are there any recommendations about routes like this on the wiki? I think they should be mapped as relations with only stations in the relation. What are your thoughts? Janko Mihelić ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
čet, 2. srp 2015. 16:32 Roger Slevin ro...@slevin.plus.com je napisao: I think you are falling into the trap of trying to cover too many things in one relationship. A stoparea to me as a public transport person is (defined functionally) a cluster of stoppoints at which it is possible to interchange between services – and as such it is also a collection of stops for which a single stop name can be shared (in the UK we then have a separate “indicator” to allow you to make the naming of each stoppoint unique within the stoparea. IMHO there is no sense in using a stop_area_group relation (You probably meant stop_area_group instead of stop_area) to show where you can interchange between services. That is already obvious if they are near each other, isn't it? Any two stops that are within ~100m from each other can be seen as an stop_area_group. You don't have to make a relation to tell you that. I see no reason to group objects in stop_area_groups, unless maybe if there is a name or ref that only makes sense to give to a collection of stops, and they all have different names. But if you are talking about a station, we have the tag public_transport=station. Janko Mihelić ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone near each other means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref. After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed. čet, 2. srp 2015. u 00:54 Jo winfi...@gmail.com napisao je: I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though. But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together? Jo 2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com: To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing. But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries. Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt. sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com napisao je: What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another. I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose. It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (5 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops. What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time. Polyglot 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com: I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme. What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street. Jo 2015-07-01 11:43 GMT+02:00 Richard Mann richard.mann.westoxf...@gmail.com: Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers. Richard On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com wrote: 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com: 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com: In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole. A platform can be a pole, or a shelter, or a dock, or a boarding platform for a train... It is meant to abstract differences between different means of transport. That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation. Anyway
Re: [Talk-transit] different interpretations of v2 PT scheme
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing. But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries. Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt. sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com napisao je: What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another. I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose. It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (5 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops. What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time. Polyglot 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com: I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme. What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street. Jo 2015-07-01 11:43 GMT+02:00 Richard Mann richard.mann.westoxf...@gmail.com: Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers. Richard On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com wrote: 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com: 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com: In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole. A platform can be a pole, or a shelter, or a dock, or a boarding platform for a train... It is meant to abstract differences between different means of transport. That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation. Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider for processing. At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for
Re: [Talk-transit] Stop according to new PT scheme not rendered?
It only takes one great public transport map with routing, and the new scheme will come to life. Who cares about Openstreetmap default map. Who cares about the public transport layer on Openstreetmap which doesn't even have tram lines rendered. We need outside help with this :) Janko 2014-08-12 0:55 GMT+02:00 Jo winfi...@gmail.com: Now that the new way of rendering with Carto instead of Mapnik is finally becoming reality, it becomes clear that highway=bus_stop will never (or at least not during my lifetime) be replaced by public_transport=platform/bus=yes. I started to double tag all the new stops I'm adding and the ones I'm updating. Some people claim that public_transport=platform/bus=yes is longer and less efficient than highway=bus_stop, but of course highway=bus_stop public_transport=platform bus=yes is even less so, but I stopped caring about that. Pity, Polyglot 2013-12-11 21:41 GMT+01:00 Richard Mann richard.mann.westoxf...@gmail.com : tag-transform is an osmosis plugin. It happens before conversion to the postgres database, so you can use any tags that exist in the wild On Wed, Dec 11, 2013 at 8:07 PM, Jo winfi...@gmail.com wrote: For a long time, public_transport was not transfered to the DB used for the rendering of Mapnik. At that time it didn't make sense to update stylesheets. Jo 2013/12/11 Mike N nice...@att.net On 12/11/2013 11:07 AM, fly wrote: If you keep on adding both schemes simultaneously you will not notice the problem and there will be no reason for developers to adjust the software. One of the problems in this situation is the map rendering developers have not taken an interest in the new scheme. If someone has submitted a 'pull request' that included the new tagging scheme but it was ignored, that is a different story. OSM is frequently described as a do-ocracy - in which finished and coded solutions win out over what is needed. And it's quite possible that we public transport mappers have been collecting and entering the information but have never gotten into CSS Map stylesheets, or whatever is the technology behind the renderers. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping intercity bus routes
I don't think we need a new tag. There would be a lot of gray area, where do coaches end and buses start? The line isn't clear. What would help is we should map the operator tag and then the renderers should show the route or not based on the operator. Or different operators could be rendered with different colors. I think this is more a render problem than a mapping problem. Janko 2014-05-25 0:30 GMT+02:00 Teemu Ikonen tpiko...@gmail.com: Hi, The current public transport schema bundles local bus transit routes together with intercity buses (coaches), both routes are tagged with route=bus. Since buses and coaches rarely are part of the same network, this makes things rather confusing for users of transit maps like Öpnvkarte. If I want to go to another part of town, I'll need the routes of the local (bus) transit network and intercity services are distraction, but if I'm going to another city, the opposite is true. Looking at main bus stations in European cities, one sees that not many intercity routes are mapped. Given the current potential for confusion with local transit, this is probably a good thing, but it also means that OSM is missing a significant part of the public transport network. The obvious fix would be to create a new public transport type in addition to bus, train, tram, etc. Since British English seems to be the standard in OSM, the new type should be called 'coach'. In practice, this type would be used in public_transport=stop_position nodes with a coach=yes tag and in routes with route=coach. Coach routes should have tags similar to bus routes (name, network, etc.). Transit maps should render coach routes with a unique color to distinguish them from other networks. Are there any downsides to this idea? How would one go about proposing coach routes as a standard, documented feature? Should a new proposal be made, or can the active public transport proposal at http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport be amended? Best, Teemu ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Close stations having the same name
Naming them different than they are named on the ground is mapping for the renderer. Just add train=yes, bus=yes or tram=yes, and that should be enough. A good renderer will put a little train/bus/tram icon below the name of the station. 2013/12/18 Jo winfi...@gmail.com Here the platforms for buses near to a railway station have names like: Gent Sint-Pietersstation Perron 3 Mechelen Nekkerspoel Perron 1 Wavre Quai 5 (Perron/Quai means platform in Dutch/French) Whereas the name of the railway station itself would be: Gent Sint-Pieters Mechelen Nekkerspoel I think it's better to indicate they are related by a hierarchy of stop_area relations. Jo 2013/12/18 Copro Grammes coprogram...@yahoo.fr Hi, Close to a main railway station, there are often other stations (underground, bus, tram, etc.) which have the same name (e.g. Somewhere Station). I wonder what is the best value for the key 'name' of these stations? There are examples where the transport type is added in the name: e.g. Gare de Lyon (métro 14) in Paris [1], or Hauptbahnhof (U-Bahn) in Frankfurt [2]. Don't you think it is better to tag all these stations with their real name (Somewhere Station)? It isn't ambiguous since other tags than name allow to distinguish these stations [3]. And it gives to users/applications the real name, not a name for renderer. Cheers, Zigeuner [1] http://www.openstreetmap.org/export#map=18/48.84385/2.37467 [2] http://www.openstreetmap.org/export#map=18/50.10769/8.66386 [3] E.g. Gare de l'Est railway and underground stations can be distinguish by some renderers even though they are both tagged railway=station and name=Gare de l'Est: http://tile.openstreetmap.fr/?zoom=16lat=48.87451lon=2.359layers=B000FF ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Close stations having the same name
2013/12/19 Erik Johansson e...@kth.se ... if you see it in a routing data base it's almost impossible to know which is which unless you name them differently. How is it impossible? If it has bus=yes, it's a bus station. If it has train=yes it's a train station. Where's the problem? Janko ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Close stations having the same name
2013/12/19 Shaun McDonald sh...@shaunmcdonald.me.uk What about search and routing engines returning the expected result for exact sign of the name of the local station? As a traveller it’s annoying to be told to go to x station, only to get there and find it’s the underground or some other variant that you are actually after and could have got there more directly. A bad router will tell you go to station nameOfStation. A good router will tell you go to train/bus/tram/underground station nameOfStation. It's very easy to do that. And it's much nicer than some name a mapper has made up. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Tagging of railway station
I like the area approach. If you were on a platform, or in the station building, or on the tracks, each time you are in the railway station (or is it on the station when you are outside, and in the station when you are in the building?). So if there is an app that tells you where you are at the moment, area would help the app be more precise. If there was a public transport routing app, it could determine which station you are on, and immediately show you departure and arrival times. Janko 2013/12/18 Copro Grammes coprogram...@yahoo.fr Thank you for your answers. I was also inclined to add railway=station tag to a node rather than to an area. But some French mappers advocate for the 'area' solution, contrary to the former version of the wiki, and I've begun to hesitate between both the approaches. So I was hoping this debate could be settled, but currently this is clearly not the case... Doesn't this matter interest anybody else ? Or doesn't anybody else have an opinion about this question ? This problem is not know (see place=*). We even already have an solution: role label. The role label could be interesting, but how can we use it ? Did you mean we could create a label relation [1] ? Or did you mean we should add a node with the role label to the stop_area relation which would be tagged railway=station (but the stop_area could also contain a bus station, a subway station, etc.) ? For new created objects I only use the new scheme but I do not delete the older tags if already tagged but only add the new ones. So I think it means you add the public_transport=station tag to the same node/area which was already tagged railway=station (as Roland did), doesn'it ? Cheers, Zigeuner [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Extract Public Transport Information from a OSM file of city
Overpass is really easy to use, I made a query to give me all bus routes in three clicks: http://overpass-turbo.eu/s/Vu Querys can directly download an .osm file to your computer, and there you can further do what you want with it. Janko ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for a new transport tag
Dana četvrtak, 1. ožujka 2012., korisnik Tom Brownthecap...@gmail.com je napisao: Regarding your original proposal with Mo-Fr 08:00-23:00 t30: Instead of putting the count of trips in a time period how about giving the average headway? When exact times are not provided timetables and riders often refer to how often the bus/train comes. You could represent this with strings such as T=20m T=1h T=45s, maybe even T=1m45s. http://en.wikipedia.org/wiki/Frequency#Definitions_and_units Maybe we could use mine t10 (or h10 for trips per hour and d10 for trips per day) and 10m, 10h for time between trips. They are essentially the same thing. https://developers.google.com/transit/gtfs/reference#frequencies_fields was added to GTFS just over 5 years ago. Wow, I don't know how i missed that. Was there talk about exporting osm transit data to GTFS? I think that would make creating GTFS feeds much easier with all the stops, shapes, line names and such.. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Proposal for a new transport tag
Hello, The problem with rendering transit lines right now is that the busy lines are rendered the same as the lines that go a few times a day. Those differences between lines should be seen right away, but we don't have that information in the database right now. I agree that the best solution would be to have the whole timetable for different transit lines, but this is often not possible and very hard to maintain. Transiki https://github.com/SteveC/transiki gave us some hope that this could be manageable, but unfortunately the project was shut down. I propose a temporary middle solution. Every bus route relation could have a tag similar to the opening_hourshttp://wiki.openstreetmap.org/wiki/Key:opening_hourstag. This way we could know if a line is only active on weekends, or if it is a night line. Or maybe it only runs in the morning and in the evening. We could upgrade this tag, and put a number of trips in each time period. This can be an estimate, a trip more or less a day is not much. It would look like this: Only ferquency: *transport_frequency*=t5 this means that a bus route has 5 trips a day. Only days: *transport_frequency*=Sa-Su this bus route only goes on weekends Only time: *transport_frequency*=00:00-04:00 Night line A little more information: *transport_frequency***=Mo-Fr 08:00-23:00 t30; Sa 08:00-22:00 t25 30 trips a day from Monday till Friday, first trip at 8 in the morning, last at 10 in the evening. Similar for Saturday. And so on. I added a t in front of the number of trips so it is easier to see, maybe it is not needed. Or maybe this could be done in a completely different way. This tag could be added in the route masterhttp://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_masteror in the route direction/varianthttp://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant. Renderers could draw the lines dashed if they are not very frequent, or black if they are night lines. Even rough public transport routers could be made using this information. What do you guys think? (Should I have put this in the wiki first?) Janko Mihelić http://www.openstreetmap.org/user/Janjko ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for a new transport tag
Dana srijeda, 29. veljače 2012., korisnik Bryce McKinlaybmckin...@gmail.com je napisao: If its just having a service frequency hint for renderers that is required, then I'd suggest keeping it very simple. For example, transport_frequency=frequent, With my tag, it would be transport_frequency=t50, and if it changes to 45, it's not too bad. transport_frequency=occasional,no_weekend_service or similar. transport_frequency=Mo-Fr t10 I think its short and easy to understand, gives more precise information, but isnt very connected with the official schedule. So if the schedule changes a bit, it isn't that bad. Bryce If we only wanted to rely on official sources, we shouldn't use opening_hours either. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] routing on osm using public transport ?
If you need just the route shapes, I suggest using openrouteservice.org and choosing bicycle. It can go anywhere. You can take on foot but it will go on footpaths and you will need more via points. Here is an example of a routehttp://openrouteservice.org/index.php?start=16.9560725,52.4096701end=16.9549348,52.4103792via=16.9545036,52.4093393%20pref=Bicyclelang=denoMotorways=falsenoTollways=false . Janko 2011/11/4 Barbeau, Sean barb...@cutr.usf.edu Qlex, For 1), I'd suggest you check out OpenTripPlanner, which has a multimodal routing engine that includes transit: http://www.opentripplanner.org OTP requires GTFS data for transit, so this would be needed to create routes for public transportation. It has a RESTful API that you can query once you get an instance running: http://www.opentripplanner.org/apidoc/ You might also want to check out GO-Sync ( http://code.google.com/p/gtfs-osm-sync/), which is an open-source desktop app our group developed to help synchronize GTFS data with OSM. This tool is currently mainly for bus stops, though, and not the relations for routes on OSM streets. We've stayed away from trying to automatically sync route relations on roads since as you say this is complex and requires significant manual inspection to ensure the data is coded correctly. Relations for bus stops and their memberships in routes, though, is handled in GO-Sync. GO-Sync is an open-source project so feel free to use the code if you'd like as a starting point for adding route relations with roads, if this is something you'd like to tackle. Sean Sean J. Barbeau, M.S. Comp.Sci. Research Associate Center for Urban Transportation Research University of South Florida 4202 E. Fowler Avenue, CUT100 | Tampa, FL 33620-5375 813.974.7208 2D barcode | 813.974.5168 (fax) | barb...@cutr.usf.edu USF Location-Aware Information Systems Lab - http://www.locationaware.usf.edu/ -Original Message- From: talk-transit-requ...@openstreetmap.org [mailto: talk-transit-requ...@openstreetmap.org] Sent: Friday, November 04, 2011 8:01 AM To: talk-transit@openstreetmap.org Subject: Talk-transit Digest, Vol 34, Issue 1 Send Talk-transit mailing list submissions to talk-transit@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-transit or, via email, send a message with subject or body 'help' to talk-transit-requ...@openstreetmap.org You can reach the person managing the list at talk-transit-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-transit digest... Today's Topics: 1. routing on osm using public transport ? (Wojciech Kulesza) -- Message: 1 Date: Thu, 3 Nov 2011 21:07:05 +0100 From: Wojciech Kulesza wkule...@gmail.com To: talk-transit@openstreetmap.org Subject: [Talk-transit] routing on osm using public transport ? Message-ID: CAB9LHzEPjAXKMWSqYhtXpWvS+s0nBJw3h8Gyx6xqGnM=oos...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, we're aiming at creating shapes of various bus routes. For this purpose, we use various osm routing engines (including cloudmade) to draw the paths that buses use. Due to limitation that such routing is using car for calculations, we're finding it hard to overcome a difficulty of how to route in places that are for public transport only, as bus stations etc. Good example is this station: http://www.openstreetmap.org/?lat=52.409641lon=16.955182zoom=18layers=M I tried to add a key psv=yes or perhaps should we use access=designated cloudmade only updates their data once a week so it is of crucial importance to find out what's the best approach. Several questions that i find important: 1) is there a router with API that would allow public transport as mode of transport ? 2) how should places like bus station be tagged in order to allow car as mode of transport i noticed that once station has access=no bus=yes and then routing request provides an answer with routing starting from nearest available normal street. other settings provide no result. Do you have any suggestions on what's the best approach ? Manual creation of route relations has disadvantages, due to frequent changes that result from construction and other changes. therefore, we would be then able to create a possibly-open source software to allow better and quicker updates of route relations (coming from stops location and automatic creation of shapes from osm routing). Any comments most welcome. Maybe we could discuss this on osm irc channel as well. Regards, Qlex -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-transit/attachments/2003/40214d91/attachment-0001.html
Re: [Talk-transit] commuter rail
I think that tag is not usable. There can be a train that goes from town to town, making it an ordinary train line. Then when it comes to a big city, it stops on every station, making it a commuter train line. How do you tag that? I know there aren't a lot of these trains, but I think the tag isn't consistent. How many circles around a route does it make a commuter line? Two in a day? Four? A real solution would be to import all timetables to a service like the one SteveC is trying to make (transikihttp://blog.transiki.org/why-transiki), and then colour the more frequent lines with a different colour. Janko 2011/10/4 dan...@web.de Hello list! In the German speaking forum we have been discussing about tagging commuter or suburban rail: http://forum.openstreetmap.**org/viewtopic.php?id=13907http://forum.openstreetmap.org/viewtopic.php?id=13907 I really think it is a necessary tag to distinguish it from different rail transport systems. Today, I created a proposal: http://wiki.openstreetmap.org/**wiki/Proposed_features/**CommuterRailhttp://wiki.openstreetmap.org/wiki/Proposed_features/CommuterRail Just give it a look and tell me what you think! Thanks, Daniel __**_ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-transithttp://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
