[OSM-talk-be] Busroutes
Gerard Vanderveken
Ghia at ghia.eu
Sat Nov 13 13:38:02 UTC 2010
Jo wrote:
> 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.
That is exactly my point.
These 4 digit numbers are not commonly available or destinated to the
public and should therefore not to be used.
At a certain road, the routes are uniquely distinguished by their 1 or 3
digit number as showed on the bus and the stops.
Only the commonly knowed numbers should be used !
>
> 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.
If you make a route with a different forward and backward segment, it is
inherent that you can not make one list where all street segments follow
each other from begin to the end.
Most logical approach is to order the segments from beginning to the
join in the forward sense.
Then list the backward segments from the split to the join and then
continue with the rest of the route.
Such a combined list is suitable for routing, because a route consists
of segments with no (=both) direction and depending on the sense, all
forward or all backward segments.
If the routeplanner discards the unwanted forward or backward segments
from such a list, they have an ordered list of all the ways in that
route from beginning to end.
I'm not convinced that you need two relations for your example.
See eg De Lijn 630 Haasrode Brabanthal - Wijgmaal Remy (v100), where the
route has a different path at the ring.
http://www.openstreetmap.org/?lat=50.88293&lon=4.71149&zoom=16&layers=M&relation=955963
It looks perfect to me and I don't see what is wrong with that (apart
for some missing crossing at the Diestsesteenweg).
Making two relations will also confuse people as to where additions or
modifications should be made.
Also the reversed naming may add to this confusion eg Leuven - Wavre <=>
Wavre - Leuven (there is no such line, only the route followed backward).
If you ask people for the name of the bus line that they use to travel
from midway to either Leuven or Wavre, in both cases people say: I took
the Leuven - Wavre to go to Leuven (or Wavre).
It will also be double work to maintain them.
>
>
> 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 <Ghia at ghia.eu <mailto:Ghia at 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
> <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
> <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 at openstreetmap.org <mailto:Talk-be at openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-be
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Talk-be mailing list
>Talk-be at openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20101113/81ea610a/attachment.htm>
More information about the Talk-be
mailing list