Hello, I cannot figure out in what order the members have to be in on JOSM in a bus route. Do they go in the order in which they come (as in, the way, the stops along that way, next way, stops along that way), or something else, and with that, what role do I give to the way? I assume I keep the default platform role for the stop? The return trip is slightly different. Do I make it it’s own route? Do I still tag it with roundtrip=yes? Even just sending me me to a website where this info is would be helpful. I don’t know why I am unable to find anything! Thank you! (Also, if I have missed anything else that is important, please let me know!)
Hola Flubber_01-49, bienvenido a la comunidad.
Hablo poco inglés, así que trataré de explicar claro para que el traductor te traduzca correctamente.
Antes de crear una relación para una ruta de transporte público, debes asegurarte existan en el mapa los puntos de detención (public_transport=stop_position, y las plataformas.
Cuando estén estos elementos en el mapa, creas una nueva reacción con los datos necesarios.
En los miembros de ésta relación, deben ir al inicio todas las paradas y sus plataformas, cada uno con su rol “stop” o “plataform” que corresponde. Deben llevar el orden que el autobús recorre.
Y después de éstos, las vías con el “rol vacío”, igualmente en orden que el autobús toma la ruta.
Te dejo el enlace en la wiki.
Key:Buses
No olvidar poner “stop_entry_only” y “stop_exit_only” al inicio y final de los puntos de detención.
Are you mapping it with the original public transport scheme or PTv2?
JOSM’s term for ‘original public transport scheme’ is ‘legacy’ though
PTv2 is a de facto term for a different way of mapping PT routes : https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726
For QA of public transport, I’ve implemented PTNA = public transport network analysis : https://ptna.openstreetmap.de
There is also OSMI = OSM Inspector : OSM Inspector | Geofabrik Tools which provides 2 views for public transport
2 Likes
I ask because I find that without operator data or riding the whole route end to end public_transport:version=2 routes can be particularly difficult to “build up” from a survey of local stops as they can change directions so many times. I often don’t know which direction to assign them to better than 50/50 unless I have managed to get a high-res picture of the timetable (if present). Busses near me also often only say the destination in the front so if you see one from the back still not know which sub-relation to add the road segment to.
Trains and trams are easier for PTv2 as they tend to be more direct and have fewer branching tracks.
For legacy/original/PTv1 tagging the treatment of unidirectional portions is different to the separate route relation method of the later standard so clarification of method is needed.
True, but as you mention
Timetables are on-the-ground truth.
PTv2 relations are hard to create and maintain. Here in Munich, an operator provides the service for about 3 years and then the bus route will be re-assigned (to another or same, negotiating budget, …).
So, besides short-term constructions (which, f.m.p.o.v., should not be mapped), they tend to be stable.
Some assoctations allow using their Web-Site data as input for OSM, some provide GTFS data - compatible with OSM licensing - see GTSF @ https://ptna.openstreetmap.de
Yeah, but the role ‘forward’ and ‘backward’ for ways in (PTv1) relations - if the bus uses the same way twice - and the fact that a single relation represents all variants as well as other unprecise definitions make it hard to do some useful QA. And QA should not be understimated.
1 Like
Apologies to OP as this tangent continues to grow a bit.
Yes. My point was more that the big sign only states the route ref not the direction in most cases. Round here the text for the direction on the timetable is much smaller than the text for the route ref so I’ve had times where I had a picture was still unable to assign to a specific destination due to minor blurryness.
The JOSM relation view actually does quite a good job of this with the connectivity chart at the right. It seems ok at tracking a bifurcated route and recognising when it reached the bidirectional bit again.
2 Likes
True again and simple if the bus has a single trip and its return trip only.
Buses in rural areas turn out to have lots of variant, bypassing a village/hamlet from time to time, …
In these cases and having all variants in a single relation, you will almost never see a continuous trip - even with ‘forward’ and ‘backward’.
Hello @Flubber_00. This is a screenshot of the 101 bus route from Resistencia, Chaco, Argentina as seen on JOSM. The bus routes here contain all the platforms and stop position first, and then the highways without any role. That way, it is possible to check that they form a continuous line on the relation editor. We add the stop_position with role stop and then the highway=bus_stop adding public_transport=platform and using the role platform.
We separate the forward and backward routes, and add them to a route_master relation.
The wiki says that for simple bus stops, stop positions are not necesary but I found out stop positions or at least a nearby node are necesary for OSMAnd to mark correctly alight and onboarding points.
Best regards.
Buenas noches.
Sí, ya también hice la prueba.
Para que OSMand te pueda dar ruta del punto A, al punto B utilizando transporte público, son necesarios los nodos en las vías marcadas como “stop” en “rol”.
De otra forma, OSMand toma una ruta sin puntos de detención como una ruta sin paradas, sino de un solo viaje.
Yo aún estoy aprendiendo. No se si OSMand pueda enrutar si no agrego “_only_entry” o “_only_exit”. Los agrego para que OSMInspector me la marque como ruta correcta.