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
