@kreuzschnabel placement=transition wäre für den Querschritt zwar anwendbar, aber zumindest in der Form, wie es proposed ist, nicht hinreichend, um den Querschritt als rein virtuell zu kennzeichnen. Entweder brauchen wir da noch ein zusätzliches Tag oder placement=transition muss auf rein virtuelle Wege beschränkt werden. Letzteres würde ich für durchaus sinnvoll halten.

Gemäß Proposal kann ein mit placement=transition getaggter Way auch einen realen Anteil enthalten, der sogar absolut dominerend sein kann. Das Problem ist, dass man aus der Geometrie des Weges den realen und virtuellen Anteil nicht mehr bestimmen kann, da die Hypothenuse keinesweg ein rechtwinkliges Dreieck aus virtuellem und realem Anteil eindeutig definiert. Meines Erachtens ist placement=transition damit eine absolute Fehlkonstruktion, da es praktisch nur die Information liefert, dass die Platzierung unbekannt ist.

Man sollte sich nicht nur auf die Betrachtung von Autobahnen beschränken, sondern z.B. auch innerstädtische Kreuzungen mit separaten Abbiegefahrbahnen mit berücksichtigen. Nur so bekommen wir insgesamt eine konsistente Lösung.

Die Nachteile von Methode III entfallen, wenn man den überschrägen „Querschritt“ weglässt und es in Kauf nimmt, dass der abbiegende Way bis zum ersten Node der Rampe über die Sperrfläche verläuft.

Einerseits halte ich das für eine ganz schlechte Idee. Was passiert, wenn es gar keine Sperrfläche gibt? Dann läuft der Weg außerhalb der Fahrbahn. Wenn wir dann noch Fahrbahnflächen erfassen, liegt der Weg somit auch außerhalb der erfassten Fläche und wir bekommen ein Zuordnungsproblem.

Andererseits hätte dies den Vorteil, dass ein anderer unerwähnter Nachteil von Methode III vermieden wird: Der Verzweigungspunkt liegt zu früh, so dass auch das Tagging von Spureigenschaften zu früh endet bzw. dasjenige des Folgeweges zu früh startet. Bei einer baulich getrennten Fahrbahn mit zwei Spuren ist das wohl kein großes Problem, bei breiten Straßen ohne bauliche Trennung wird das Problem größer, da der Querschritt bei gleichbleibendem Winkel auch in Straßenlängsrichtung länger wird. Im innerstadischen Bereich wird dies besonders problematisch, da dort Änderungen auf viel kürzeren Längen erfolgen.

Mein Vorschlag wäre daher wie Methode III zu verfahren, jedoch den Querschritt rechtwinklig durchzuführen, und durch geignetes Tagging zu kennzeichnen, dass diese erste Kante des abzweigenden Weges rein virtuell ist. Dann können Router dies bei Winkelberechnungen geeignet berücksichtigen und eine Datenvorverarbeitung des Renderers kann ,flache Winkel soweit nötig, ergänzen. Wenn die Straße auf Basisis der Spuranzahl in realer Breite gerendert wird, sollte letzteres nicht nötig sein.

If you want to make explcit where the vehicle stops, a public_transport=stop_position can be added on the highway. For the first and last stops, the way should be split there, as it’s the beginning or end of the route.

But these stop_position nodes are not all that important, so no real need to map them for every stop. Also no reason why the stop details should be repeated on them and no real need to add them to the route relations. It’s enough to add them to stop_area relations.

There can be multiple stop positions per platform. If the route contains platform nodes only the correct stop position can not be determined. We would have to use the stop_area, which is containing a single stop and single platform, as member of the route instead. This doesn’t seem to be convenient. Alternatively, we can place a seperate platform node per stop position, but this would change the definition of public_transport=platform, including changing the meaning of existing data. Therefore, we must not use public_transport=platform in this case.

If we want to have less impact of route relations of ways, a better approach would be to make smaller segment relations and use those in the relations describing the itineraries.

This is essentially the second approch, which I have proposed above.

I fail to see how such ‘hinting to itineraries’ could be validated automatically.

I would disagree on automatic validation being impossible. The relation could no longer be verified separately, but the other involved relations can be easily determined automatically, and validation can be done based on the determined complete set of relations.

In case of my first approch, the following automatic validations seem to be possible:

• Routability of each itinerary based on sole use of the ways in the master route relation
• Uniqueness of the routing result
• No unused ways in the master route, which aren’t used by any itinerary

In case of my second approch, automatic validation seem to be quite straightforward. Even if we allow to omit the segment as member where unique, the route can be automatically determined, and we can validate for existence and uniqueness automatically .

I can imagine two different approches to reduce the impact of highway/railway maintanance on PT datastructures and vice versa. Both approches a based on removing the ways from the the route relations of directions and variants. This makes these relations quite different to traditional route relations. Therfore, I call these relations tour relations here.

1. The ways used by any direction or variant are added as members to the master route relation like it were a PTv1 route. The tour relations contain a sorted list of the stops. A map can be easily rendered using the master route relations. Applications like passenger routing can be based on the tour relations, because the exact route (ways) is not really required for this application.

   Applications requiring the exact route of a variant are likely rare. In this case data consumers need to autoroute based on the stop sequence from the tour relation and the limited set of ways from the master relation. A simple standardized routing algorithm has to be used in order to make the autorouting result well defined. The autorouting algorithm shall ignore tags, but respect forward/backward roles of the ways. We will need editor support or at least a QA tool to check that autorouting is possible and has a definite, correct result. In case the result is incorrect some via nodes can be added to the tour relation to fix the routing. We might also allow to use via ways where applicable.

   Stops shall contain nodes on the way (stop positions). Otherwise autorouting would become more complicated and error prone.

2. The ways are put into unsorted route segments. The route segments shall have a from and a to member specifying the start and end node of the route segment. This enables checking the completeness of the segment, and it helps to identify and find the segment. The route shall be splitted at stop positions, or in special cases at named via nodes, which have to be added to the tour relations. Due to stop positions being named, the editor can generate a display name of the segment based derived from the names the from and to nodes. Splitting the route at nodes, which are also included in the tour relation, the editor can find segments fitting to the tour automatically, and offer them to be added as members of the tour.

   We might even decide not to add the segments, except where it is ambiguous. In this case data consumers have to look-up the segments. Maybe an extension of the Overpass API can help to do this.

   We might also let the editor add the segments to the tour relation automatically if unambiguous.

   We might allow segments to have forked ends with multiple from or to members, but use should be limited to multiple stop positions of the same station. Otherwise generating a display name for the segment would be complicated. Using forked segments can reduce the number of segment relations significatly, but it adds some complexity for data consumers to remove unused branches.

A tool like the PT_Assistant might help the PT-expert to repair the damages, but it doesn’t solve the core issue. How should editors, like iD, handle PT-relations for the normal users? In case the editor protects the PT-relations it prevents maintainance of the highway/railway. In case it doesn’t protect, the PT-experts get much work to repair the resulting damages. Are they really willing to do this work permanently?

We do need to get better editor support for PT, but not only for JOSM but also for iD. Excluding the majority of users from being able to map PT is quite bad for the data quality. We won’t get reasonable editor support as long as we haven’t defined and decided on a better PT data model. I can’t imagine resonable Editor support in iD for the current PTv2. Cloning JOSM’s relation editor into iD doesn’t make sense, because it is enabling advanced users to map PT, but not the normal user. Therefore, it would be useless for the typical iD user.

There are some valid thoughts included, but PTv2 has a much more important issue. It’s a nightmare for the maintainance of the highway/railways where many routes or variants exists, at least without accepting massive PT destruction. This is due to the highway/railway ways being member of very many PT route relations, and this maintainance would often to be done by user with litte or no knowledge of PT mapping.

Any solution for this issue, which I can imagine, seems to become too complex to handle for data consumers without making heavy use of stop positions. Therefore, it doesn’t seem to be a good idea to drop stop positions or to make them less accessible from the route relation.