Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 07:50, schrieb André Joost: Am 11.01.11 17:01, schrieb Michał Borsuk: You do get that information when you are at the spot. It is written on the timetable. If you are able to see, yes. But disabled (that is everyone who has to use public transport because he/she is not able to drive a car) not. A lot of the disabled are perfectly able to drive cars (which have been adjusted for that purpose). My father was severely disabled after an accident, and he did so. And on the time-table you wont find a hint *where* the right platform is. It is clearly printed at each bus stop, at least in Europe. In North America phone number is provided. A public transport router with audio output would do, if it has the data. We could work towards this aim. The visually impaired are a very small minority, and clearly OSM has different, more basic issues to deal with. We should focus on the mainstream first, to get OSM out of the beta version it is now. Greetings, -- 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am Tue, 11 Jan 2011 20:21:41 +0100 schrieb Michał Borsuk michal.bor...@gmail.com: On 11 January 2011 18:59, Dominik Mahrer (Teddy) te...@teddy.ch wrote: I began searching for alternatives and found Oxomoa, unified stoparea, stop place and others. All are created because the current schema is not able to represent all eventualities. It doesn't have to. It is an S-function, reaching 100% costs much more than reaching 99%. I pretty much came the same way Dominik did. I am also a public transport fanatic. And I like to map small details and it makes me joy to when a bus route crossing a roundabout uses one half of the roundabout in one direction and the other half in the other direction. Till now I had the impression that openstreetmap follows the philosophy Everybody maps as detailed as he likes. And for enthusiasts it is not only a question of efficency and costs but also of joy, and isn't it because of enthusiasts that openstreetmap exist? If not and if this detailed public transport mapping is not preferred in osm please tell me, then I will find my joy somewhere else. I am open to change my proposal. I am also open to approve a completely different schema. Michał, please feel free to tell me what to change to improve the proposal. To say this proposal has a bad learning curve may be correct, but it does not help further. In another topic. I am looking forward to that! Albin (Almich) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
1) We need to see a proposal that is explicitly scalable. No more than one page to describe how to map a basic bus or tram line in a way that is consistent with existing usage (ie if you look around you will see lots of examples to reinforce your understanding). 2) There is no clear case for a new public_transport key. If existing usage of existing tags works ok for basic situations, that should be enough. 3) It doesn't matter whether people use one relation per direction or two. Both are readily parsable. However, forward/backward must refer to the direction of the way, not the direction of the route, otherwise you are cutting across other uses of those roles. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 11:10, schrieb Albin Michlmayr: Am Tue, 11 Jan 2011 20:21:41 +0100 schrieb Michał Borsukmichal.bor...@gmail.com: On 11 January 2011 18:59, Dominik Mahrer (Teddy)te...@teddy.ch wrote: I began searching for alternatives and found Oxomoa, unified stoparea, stop place and others. All are created because the current schema is not able to represent all eventualities. It doesn't have to. It is an S-function, reaching 100% costs much more than reaching 99%. I pretty much came the same way Dominik did. I am also a public transport fanatic. So am I. And I like to map small details and it makes me joy to when a bus route crossing a roundabout uses one half of the roundabout in one direction and the other half in the other direction. Till now I had the impression that openstreetmap follows the philosophy Everybody maps as detailed as he likes. And for enthusiasts it is not only a question of efficency and costs but also of joy, and isn't it because of enthusiasts that openstreetmap exist? It's a Pareto-principle distribution: 80% of edits are done by 20% of contributors. Still, this does not mean that we can't have more contributors. And new guys are not going to map half a roundabout, at least not immediately. Personally I've done the same as you did, until I realized that my area (2500km²) will never get done if I am to be so slow. Thereafter I imported *all* the bus stops, added more lines, and miraculously more contributors appeared! So people were encouraged to join when they saw another person do something in their area. So the learning curve was important after all: they all copied from me, instead of discovering (like I did) how it should be done. And that's my main point: we need more of those small time contributors. If not and if this detailed public transport mapping is not preferred in osm please tell me, then I will find my joy somewhere else. This is a proposal, nobody is telling you to go. Or even to change your ways. Enjoy it as you did. I am just appealing to your common sense: the standard is not only for us, but for the community. The community is often *very* different than us. Most of them will never reach our levels of proficiency, but if they map a line or two, it's very good! And, I don't know where you people get the idea that I am any different than you. I've ridden public transport in many countries, both on the right and on the left side of the street, and on two continents. I map not only German lines, but also French, and local international (yes, we do have those!). Presently I don't have a car, but I have an almost free monthly ticket to my large public transport area. I've been to more places in that PT area (VerkehrsVerbund) than any local inhabitant in his whole life. What I clearly oppose is turning OSM PT mapping into our playground. I am an idealist, ready to defend the principle that OSM is a public service, not only our personal fun. I am not aiming to take the fun from us. All I want is to have an open door for new people. More on this should actually follow in the other thread I started, about principles to follow. Michał, please feel free to tell me what to change to improve the proposal. To say this proposal has a bad learning curve may be correct, but it does not help further. In another topic. I am looking forward to that! I've posted it yesterday. Can't cite the title, because I don't see my own posts. You're very welcome to argue with the five principles I posted there, and my comparison of the proposal in the light of the principles. Greetings, -- 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 11:16, schrieb Richard Mann: 1) We need to see a proposal that is explicitly scalable. No more than one page to describe how to map a basic bus or tram line in a way that is consistent with existing usage (ie if you look around you will see lots of examples to reinforce your understanding). 2) There is no clear case for a new public_transport key. If existing usage of existing tags works ok for basic situations, that should be enough. That seems to be a sensible proposal, but do we put it into the standard? If so, then the one-relation version should be accompanied by a comment on roles. 3) It doesn't matter whether people use one relation per direction or two. Both are readily parsable. However, forward/backward must refer to the direction of the way, not the direction of the route, otherwise you are cutting across other uses of those roles. So, who's volunteering to prepare yet another wiki page that would explain the situation? And, personal request hereby. If you provide examples how to map (also how not to map would be good), please do not only provide your own examples. -- 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 09:52, Michał Borsuk wrote: Am 12.01.2011 07:50, schrieb André Joost: Am 11.01.11 17:01, schrieb Michał Borsuk: You do get that information when you are at the spot. It is written on the timetable. If you are able to see, yes. But disabled (that is everyone who has to use public transport because he/she is not able to drive a car) not. The visually impaired are a very small minority, and clearly OSM has different, more basic issues to deal with. We should focus on the mainstream first, to get OSM out of the beta version it is now. It is not our primary aim to serve some kind of mainstream. It is to collect any geographical data that could be useful to somebody. And yes, somebody includes blind people, too. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Richard wrote: put unified_stoparea as an elaboration rather than an alternative; I hope it doesn't spark an edit war). It might. Unified_stoparea is flawed in that it isn't backwards compatible as it contradicts the documentation for highway=bus_stop (node beside way) to use it for the stopping position (rather than the platform). This is why the proposals that use public_transport tags are immediately better. Adding bus stop nodes is one of the simple things new mappers can do; more advanced users can add them to the appropriate relations later. Ed ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 12:59, schrieb ant: Hi Michał, Certainly it doesn't make sense to talk about bus stops when the road network isn't even finished yet. Totally agree. The point is, we are in the process of establishing a kind-of-standard about public transport network. There has been lots of struggle about this topic, and therefore it's quite an important process. Since I am working on a project that deals with navigation for the blind and visually impaired, I know how important these mapping standards (if you can call anything in OSM a standard at all) are. If we continue to stick to the old scheme, or any extremely simplistic scheme, we are simply missing the basis for future development in the area of blind people's navigation (and probably many other areas as well). Yes, we are - at the cost of (sorry to repeat the mantra) efficiency, compatibility with the existing software and easier learning curve. From our point of view (or mine, depends how you see it), the quality of the final product is a mathematical product of quite a few parameters (including the mantra above), NOT the quality of the data alone. I'm not saying everybody should do it now and everywhere. But the proposed public transport scheme is a solid basis to work with and one that is scalable enough to meet requirements we might not yet be thinking about. I've already provided my criticism to the proposed schema, so not to repeat myself, on another topic: I have been sort of thinking along the same lines as you are here (assistance to the users of public transport). I came to the conclusion that the easiest thing would be to take the bus stop code and combine it with the link to the local timetable online. For example, to cover entire area of Germany one would need to import stop codes as the stop_id tag, and then have a list of online timetables combined with geographical location those timetables cover. As some people (myself included) have already imported stop_id's, the last step - the mapping of public transport authorities to the geographical area, and providing a link to the online timetable is relatively banal. An overlay would then take the stop_id, combine it with the URL, and here opens your timetable website. I am writing this, because I have heard of NAPTAN, and I am sure a similar plan could be applied in the UK. My point is not to reinvent the wheel, no matter how much one likes programming. cheers also, ant michal -- 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On Wed, Jan 12, 2011 at 12:21 PM, Ed Loach e...@loach.me.uk wrote: Unified_stoparea is flawed in that it isn't backwards compatible as it contradicts the documentation for highway=bus_stop (node beside way) to use it for the stopping position (rather than the platform). This is why the proposals that use public_transport tags are immediately better. You have to make sense of all the main existing schemas already (since they are unlikely to disappear). The main requirement is understanding what they are and how to tell them apart, not to try to standardise them (and especially not to standardise by multiplying the number of tags several-fold). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Le 12/01/2011 11:10, Albin Michlmayr a écrit : I pretty much came the same way Dominik did. I am also a public transport fanatic. And I like to map small details and it makes me joy to when a bus route crossing a roundabout uses one half of the roundabout in one direction and the other half in the other direction. I like precision too. But on that point I think it's a mistake to cut roundabouts for routing. Included in a route, a roundabout has an entry point, a outgoing point and a oneway circulation. So it is very easy to comput the part of the roundabout used by the route without cuting it. A roundabout is to be considered as a cross, just a big cross. I have stopped cutting them when someone explained this easy comput. I think roundabouts would be cut only when part of them are bridges. -- FrViPofm ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On Wed, Jan 12, 2011 at 2:50 PM, ant antof...@gmail.com wrote: Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. Another mapper will come and turn it into a stop area and update the route relations. But if applications can cope with only having an unordered relation and bus stop pole nodes (or indeed just tram_stop centroids), then why clutter the map with lots more tags and info that the applications can perfectly well derive for themselves 99.9% of the time? You should only supply the extra info for the 0.1% of the time when it can't readily be derived. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 15:50, schrieb ant: Hi, Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. And that's what we're about to standarize. Another mapper will come and turn it into a stop area and update the route relations. Exactly. But this entire process needs a website, hence this discussion here. [...] People will develop standalone OSM routing applications for public transport and won't accept any dependency on external websites... No, they won't. It's too complicated, and too expensive to maintain. I can bet on it (sadly). Those who claim otherwise have not seen the real data, or they think that a bus starts from a terminus, ends at another terminus, and does it N times a day. It's not at all that easy. (Some people may want to simply copy Google Transit data, but again, Google Transit at present covers very small area.) Greetngs, -- 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 16:00, Richard Mann wrote: On Wed, Jan 12, 2011 at 2:50 PM, antantof...@gmail.com wrote: Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. Another mapper will come and turn it into a stop area and update the route relations. But if applications can cope with only having an unordered relation and bus stop pole nodes (or indeed just tram_stop centroids), then why clutter the map with lots more tags and info that the applications can perfectly well derive for themselves 99.9% of the time? You should only supply the extra info for the 0.1% of the time when it can't readily be derived. I don't know what applications you have in mind, but if they can do more than draw some lines on a map, this sounds like black magic to me. Consider an application that takes a start and an end address, maybe other options such as night lines only, and that shall calculate the shortest PT connection including number of stops etc. How would you accomplish that with the old tagging scheme? cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 16:30, schrieb ant: Consider an application that takes a start and an end address, maybe other options such as night lines only, and that shall calculate the shortest PT connection including number of stops etc. How would you accomplish that with the old tagging scheme? By introducing an abstract interface layer with your own objects, that is your own internal standard, into which all the messy present standards would be translated. This is easy. Then you play with *your* objects, your program is not directly dependent on the OSM PT standards. Any changes to the standards will require only a few lines of code to the abstract interface layer. BTW Data consistency is not as important as it used to be 15 years ago. We primarily have to make sure that no contradicting standards exists. Of course, this conversation still does make sense, because we want to have a clear standard for beginners, and for our own ease of use (and fun). Greetings, -- 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 16:40, Michał Borsuk wrote: Am 12.01.2011 16:30, schrieb ant: Consider an application that takes a start and an end address, maybe other options such as night lines only, and that shall calculate the shortest PT connection including number of stops etc. How would you accomplish that with the old tagging scheme? By introducing an abstract interface layer with your own objects, that is your own internal standard, into which all the messy present standards would be translated. This is easy. Then you play with *your* objects, your program is not directly dependent on the OSM PT standards. Any changes to the standards will require only a few lines of code to the abstract interface layer. There are some minimum requirements that the data should meet in order to make it easy. In particular, it should resemble the network structure of a PT network, i.e. bus and tram stops acting as nodes that connect bus and tram lines with each other. A node in this context means a place where i can change from one bus (tram) line to another without having to walk more than a few metres. In the proposed scheme a stop area is exactly this. So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On Wed, Jan 12, 2011 at 4:07 PM, ant antof...@gmail.com wrote: So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. Stop areas are about linking the stop (notionally on the footway) to the road. Or they are about linking platforms with the same name. You can do that as you go along. The stopping_position and stop_area relation are just clutter. If you know the latlons of two stop areas, you can work out how to get between them by running your pedestrian routing algorithm. Marking footways between stops (other than the ones you can assume are adjacent to any roads not marked with footway=no) is more useful than linking the stop areas into a group and implying there is free access between any stop area within it. Basically you use relations to link objects which have a geographical relationship - not just a geographical proximity. There's sense in adding group objects if data relates to the group (eg to a station and not to it's individual platforms), but I'd find a convenient node or area to hold the info, not put it on an unnecessary relation. And if the information is relatively simple (eg a name), I'd settle for putting it on all the nodes, rather than create an artificial single object to hold it. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Talk-transit Digest, Vol 23, Issue 3
Hi, I'm watching this discussion from beginning, and I want to give you some point to your consideration. OSM is map solution - I don't want to define what kind of solution (despite the content is developed by community). But OSM is a perfect base-platform for every geo-location based internet application. Not only trip planning but more. I agree with Michal: the ultimate goal of OSM is the mapping solution, but it mean also the data. But everyone of us have to separate this definition: to cartography data and thematic-related data, like transit. That's why we have Geoserver, OpenLayer, PostGIS and more. So, let's leave the OSM as a map, and don't mix the data. Use layer instead of copile everything in to Mapnik. For me, the problem lays in data management related issues like, data repository, lawfulness of data, data ownership etc. This issue arising specially for transit topics. Regards, Filip BTW, It's my first post on this group. I wanted to say Hello to community - currently from Dublin :) On 4 November 2010 20:43, talk-transit-requ...@openstreetmap.org wrote: 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. Re: public transport time tables (Micha? Borsuk) 2. Re: Talk-transit Digest, Vol 23, Issue 2 (Wojciech Kulesza) -- Message: 1 Date: Thu, 4 Nov 2010 21:37:43 +0100 From: Micha? Borsuk michal.bor...@gmail.com To: Public transport/transit/shared taxi related topics talk-transit@openstreetmap.org Subject: Re: [Talk-transit] public transport time tables Message-ID: aanlktik+ape+-v_cvx8=gml-mgj+joy37vv99bsnu...@mail.gmail.comgml-mgj%2bjoy37vv99bsnu...@mail.gmail.com Content-Type: text/plain; charset=utf-8 On 4 November 2010 21:25, Sander Deryckere sander...@gmail.com wrote: Sorry, I didn't want to attack you. You didn't attack me, I must have an aggression problem if you took it this way ;) Sorry if it sounded that way. I know it's not easy to make a map, but I see a map making as an other project, next to OSM. OK, then you simply should see that other project as next to OSM, the map-making project. It's all about the name and about who makes what. To be absolutely clear: I am not a street mapper, I map/maintain routes and stops on the existing map. So I'm on your side, but OSM is OSM, not a route-building application. That would be IMHO creeping featurism. The project seems already complicated to manage, let it stay slim. It's good that OSM has its own map, so mappers kan see their changes, but it's not OSM's core business. Is it not? OSM is more than data for maps, it also has to provide data for routing software, like maxspeeds, forbidden turns ... I think a timetable would be part of that. So there can be efficient routing software for public transport. I see it as an efficient lower layer for any the routing application out there. But again, is there a need for a new one? These are just my thoughts, I don't want to offend someone, I admire all people working on projects like this for free, be it map making, programming, mapping ... Neither do we want to offend, but just in case you were new: my advice take a look around. I've been here for a year, and I still consider myself somewhat of a newbie. The very early realization that I made was that OSM is not a wikipedia of maps, it's a *way more complicated* project than has existed (personal opinion disclaimer). I do share your optimisms about the possible uses, what is brewing here is something incredible. If somebody told me few years ago I'd be roaming the forests in my surroundings with my telephone, and be able to return home from any given point, I'd not be able to imagine how that'd work. But it does. regards, also, Sander -- Best regards, mit freundlichen Gr?ssen, meilleurs sentiments, Pozdrowienia, Micha? Borsuk -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20101104/29a0917c/attachment-0001.html -- Message: 2 Date: Thu, 4 Nov 2010 21:42:58 +0100 From: Wojciech Kulesza wkule...@gmail.com To: talk-transit@openstreetmap.org Subject: Re: [Talk-transit] Talk-transit Digest, Vol 23, Issue 2 Message-ID: aanlktimrhhcdyhsrw9=vu2pyxaugt1dlw5ykcypy9...@mail.gmail.com Content-Type: text/plain;
Re: [Talk-transit] [Tagging] Proposed Feature - 2nd RFC - Public Transport
2011/1/11 Dominik Mahrer (Teddy) te...@teddy.ch: Please visit again http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport thank you for the work on this. I have just 2 small comment on this: A station is an area dedicated to and particularly designed for passenger access to Public Transport, considerably bigger than a pair of bus stops or tram stops. I think that particularly designed is not an essential requirement. Whether a station is a station or not depends only on the function: if it works as a station it is a station. 2) I think the examples should have a bus=yes attached cheers, Martin ___ 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] Proposed Feature - 2nd RFC - Public Transport
On 01/12/2011 05:07 PM, ant wrote: A node in this context means a place where i can change from one bus (tram) line to another without having to walk more than a few metres.In the proposed scheme a stop area is exactly this. Sorry, but this is absolutely pointless. First of all, modern routing software can calculate a route finding the nodes from stops' coordinates (Hafas and Google Transit). It will consider two stops to be a node if a distance between them is lower than a certain constant. So those can be created dynamically, humans are not necessary. For speed, popular pairs of stops are stored in a static table. Secondly, if you insist on stop area, then you create a weak point for the routing program, because it would rely on human input creating those areas. One area missing, and the entire routing algorithm goes to hell, because the program would send you through another stop area. Such errors would be very visible, and the users would be disappointed. Who wants to be taken for a ride all over the town because of one missing stop area? I mean no offence, but please understand that this is the 21st century. Your suggestions are indeed correct, but are applicable to software standards that were there 10 or 15 years ago. Much more can be done now. Point: Leave it to the algorithm instead of asking humans to do it. So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. Programs such as Hafas are some years of age, and already they do it easier than you propose. They do it the way I described above: finding connections by distance between stops, and calculating the price to walk. A connection with a shorter walk is of course preferred, as is a connection without transfers. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 01/12/2011 06:34 PM, ant wrote: On 12.01.2011 17:27, Richard Mann wrote: I think there is some misunderstanding. I'm talking about the use of relations to group stop positions and platforms together that are considered a stop or station where one can change vehicles. Again, why enter it by hand (expensive!), when OSM already contains all the necessary data (stop coordinates, obstacles between them)? We do not need stop areas, at least not for that purpose. The transferability between stops can be calculated by a very simple script checking the distance (foot route) and obstacles between the two stops. The distance is then added to the cost of the route. (Cost: each transfer is a cost, travel time is a cost, walk as well, etc. The connection with the smallest cost is presented to the user). Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
