I'm mostly experimenting to figure out what can work. My initial though was a relation per route/stop pair, but that means a lot of relations. Then I was thinking: it would be nice to have an idea about the approximate time to get to the next stop, which led to what I did now. Taking that idea a bit further, why stop at only the next stop, if you can describe the whole itinerary?
I do think we need a plugin to make handling the information easier. I think it can easily be added to PT_Assistant if we manage to find someone who can code in JAVA. What I like about doing it this way, is that it becomes possible to determine what will be the final stop for the particular bus that passes at that stop at that time. This is something we didn't have yet. The other thing that is nice is that we now have a basis to sort the stops in the route relations on. (atm PT_Assistant has functionality to sort them along the highways, if they are sorted correctly). For someone entering the data, it's enough to enter the departures times for the first stop. If the times between the stops are not known yet, the roles remain empty at first. Or we could put sequence numbers in there. About that, I do notice some have the same minute, it would be nice to have a way to sort the stops based on the times though. If someone entered the times at a stop somewhere in the middle of the itinerary a tool can help adapt the times afterwards. I'm going to try and apply this to this 'route from hell' (47 itinerary variations!) : https://b2cservices.delijn.be/rise-api-pdf/pdf/dienstregelingen/entiteit/4/lijnnummer/201/richting/10/lijnnummerpubliek/20a/dienstregeling_20a.pdf?gebundeldeLijnen=false&typeDag=true&alleHaltes=all&alleRichtingen=false&datum=06-11-2018×tamp=1541278207591 That PDF only describes what itineraries it takes on weekdays outside of school holidays... Jo Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>: > Polyglot: > I think that having a timetable relation for each stop is less complicated > than having one per route. There are several advantages to this: > 1) People can easily add a single relation at a time, rather than having > to do the entire line at one time. This could make it much easier to, for > example, have a StreetComplete quest asking "What are the arrival times of > bus X at this bus stop?" iD could also have a field at bus stops with > "arrivals for each parent bus route" that would allow people to seamlessly > create timetable relations. It also makes more features possible in the > future, such as additional tags to each timetable. > 2) The system is easier for newbies to learn to use. > > The disadvantage is that there are now a ton of relations per bus / train > / subway route. Creating these could made easier by a new JOSM plugin. > Also, if someone wanted to delete all timetable relations that are part of > a route, they could simply use this overpass query to download the data > into JOSM and then delete all of the timetable relations: > https://overpass-turbo.eu/s/Dlf > > If people really prefer a single timetable relation for each route, then I > will go with that. > > Julien: > Why not have a "delay"="<amount of time between arrival and departure at > this platform>" tag instead of separate arrivals/departures tags? > > Thanks, > Leif Rasmussen > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
