I tend to agree with you as far as creating child relations for the routes goes. It was an experiment of mine. There is no support for it in the editors, nor the renderers, so I'll probably let it go. It seems like a more maintainable way to do things, to me, but I'm standing alone in this. An other way of doing it, might be 'proto-relations' and 'routeparts', which get converted to the route relations by a script.
Concerning those 4-digit numbers of the lines. They can be found on those displays which are meant for the drivers (only in the bigger terminals). By naming the routes De Lijn xxxx, all the bus routes of De Lijn get sorted together in the relations subwindow. You complain about people starting new routes, when a route already exists, well this was already happening. (395 is one that I found yesterday). Naming them in an unambiguous way and sorting them all together, will avoid people creating route relations more than once. I don't agree concerning the route per direction of a bus line. This is the best way to unambiguously indicate where the buses are travelling. I just added line 179 between Etterbeek and Leuven (Fast bus that only runs on Fridays and Sundays between VUB and Hamont). The two directions of this line are almost completely separate (since it travels over Bvd. Général Jacques then E40, then the ring of Leuven). By creating a route per direction, one obtains a long sequence of consecutive segments. By combining the 2 directions, this is not possible. We are not simply creating a graphical map, we have to think of being able to use this data for routing eventually. Even when today this is not possible yet. Jo 2010/11/13 Gerard Vanderveken <g...@ghia.eu> > I think you are making it all too complicated. > > For most bus routes only 1 relation is sufficient. > There is no reason for doubling all routes by default. > > Also making relations members of other relations is a mistake. > The data of OSM is flat and not layered. > See also Members of a route: > http://wiki.openstreetmap.org/wiki/Relation:route#Members > These are only ways (routes) and stops (points). > > Also the renderers do not take into account these child relations: > > http://www.openstreetmap.org/?lat=50.8752&lon=4.6983&zoom=14&layers=M&relation=1269869 > Even not the demo project for public transport routes.. > > http://3liz.fr/public/osmtransport/index.php?country=Belgium&location=Overijse > - drag map to Leuven - click + buslines - click null > > Also when you request info of a street or stop, you see immediate which > routes are passing and you do not need to click all relations to see if > they contain other routes. > > We should only map the permanent location of a route. > Temporary deviations are not needed. If a traveler goes to the stop, he > will retrieve an info board of De Lijn saying that the halt is > suspended/replaced. > > For alternatives and variations there is an alternative tag. > For shorter routes, it is up to the traveler, to inform him on the times > when the bus services the required stops. > > For the time being, there are no good possibilities to incorporate shedules > etc in OSM. > Making some preparations to facilitate this is futile, because this > surpasses the normal mapping properties. Probably the needed data and/or > its form will also be determined by the application that will make them > available. > You could for example starting by using the opening hours tag and thus > indicating for a bus stop all the times when a bus passes. > Then you envisage a lot of problems: the stop can be serviced by > several lines, there are normal days and school days, night bus, ... > To have all this in one tag or several tags, makes always a big list of > data, which will be to entered very punctual to be usable. > And the question is of any application, will be able to make good use of > it and not require another format. > > To support this manually is impossible. To import it, you need clearence. > To show it, you need applications. > None of them are for the moment envisaged, so a link to the webaddress > of the routes its dienstregeling will be at the time being the best to > offer eg: > http://reisinfo.delijn.be/dienstregelingen/ > Also the amount of data is also substantial, which may not be desired to > incorporate it yet at this time. > > Also the last days, the names of the relations are changed with > internal numbers of De Lijn. > This may confuse the user who will not retrieve the numbers as used on > the bus, road maps, stop signs, etc by De Lijn. > The name should be clear so that a user can easy retrieve ithe presence > of a route. (Else he could start to map again the line and afterwards > discover that his work was in vain) > Furthermore, I believe these data are not public available and retrieved > from an illegal database file, where we have no copyright to. > > So, I recommend: > - to use only one relation per route > - delete the doubles (backward routes). > - delete child relations and add their streets and stops to the main > relation > - use the displayed route numbering (=ref) in the name of the route. > - delete data were we have no copyright for. > > > > > > > > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-be >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
