Lass mich als Autor von PTNA antworten:
Das Argument könnte man bei so vielen Features wie lanes=, turn:lanes=, maxspeed:forward=, maxspeed:backward=, parking::= und vielen mehr anbringen.
Mach’ dir da keinen Kopf, spalte auf, wo es notwendig ist. Die verschiedenen Software (Renderer, Navis, …) müssen eh mit sowas umgehen können und die Länge und Anzahl sollte denen nichts weiter ausmachen.
So ist es, stop_positionen sind optional (so wie platforms auch), wenn aber mindestens eine stop_position in der Relation drin ist, so wird von PTNA erwartet, dass auch am Anfang und Ende der Route stop_positionen sein sollten: “alles oder nichts” könnte man sagen.
Für train, tram, … ist bei einigen Auswertungen von PTNA “–relaxed-begin-end-for=train,tram,light_rail” gesetzt, so dass für diese Fahrzeuge nicht gemeckert wird (Endstation eines Zuges im Kopfbahnhof, die Strecke geht bis zum Puffer, …). Allerdings muss die erste/letzte stop_position immer noch auf dem ersten/letzten Way liegen (Anzahl stop_position > 0, s.o.).
Für ‘bus’ halte ich das nicht für sinnvoll - Wege, wo keine Passagiere befördert werden gehören mMn nicht in die Relation (auch wenn sie noch so kurz sind).
PTNA wertet die Länge übrigens nicht aus - und ab welcher Länge sollte man meckern?
-
bei Route-Master wird nicht weiter geprüft
-
bei Route:
-
name = “… ref …: from => to”
-
name = “… ref …: from => via [=> via] => to”
PTNA stützt sich auf
und legt diese an einigen Stellen strenger aus (recommended/optional wird zu: “PTNA erwartet das”).
Dass PTNA an einigen Stellen strenger ist liegt daran, dass man mit dem “absolut Notwendigen” (=mandatory) im realen Leben in der Regel nicht weit kommt.
Wir hätten den heutigen Mobilfunkstandard nicht, wenn die Hersteller sich bei der ersten Version (GSM) nur an die ‘mandatory’ Features gehalten hätten.
Die ‘optionalen’ Features sind das Salz in der Suppe, vom ‘madatory’ wird man gerade mal satt, mehr aber auch nicht.
