Hallo Moritz. OSM ist leider gelegentlich eine Sammlung von halbgaren Ideen. ;-)

stop_area war einzig dazu gedacht, PTv2-Elemente (stop_position und platform) zusammenfassen, welche dieselben Referenzwerte (ref, uic_ref, uic_name, name) besitzen. Dies als wundervolles 'high-concept', um Redundanzen zu minimieren. Leider im Alltag unbrauchbar, da ich zumindest beim Editieren auf Klarnamen angewiesen bin und mit der OSM-ID der Objekte selber nichts anfangen kann. Und auch QA-Tools wie PTNA holen sich aus den ÖV-Relationen die Angaben von den Objekten und nicht von allfälligen Elternrelationen.

Inzwischen werden daher (wenig beachtet) auch 'Kraut & Rüben' erfasst, und Relationen wie wikipedia-Kategorien verwendet, obwohl dies dies als 'do-not' [2] deklariert ist.

platform_edge ist ein railway-Element (und als solches nie automatisch ein PT-Element), und erfüllt als eigenständiges Objekt keinen Zweck, sondern dient dazu ein platform-Objekt besser zu beschreiben. Grade im Beispiel hier, wo die platform bereits ein multipolygon ist, hättest du dir etwas Arbeit sparen und den Umriss an den Eckpunkten auftrennen können, dann hättest du automatisch zwei Kanten erhalten. platform_edge ist dann auch logisch korrekt Teil des Perron-Multipolygons, der wiederum Teil der stop_area ist (sofern er im Personenverkehr verwendet wird). Reiner Güterverkehr ist nie public_transport – wenn man dies erfassen möchte, dann müsste man korrekterweise mit einer (railway-)site-Relation arbeiten. Das Problem ist, dass "schlaue" Editoren wie iD, solche Unterscheidungen nicht beherrschen, überall dieselben tag-Vorschläge machen und auf diese Weise fehlerhaftes Tagging salonfähig machen.

Ich hoffe, dass meine Erklärung die Zusammenhänge klarer macht. 

Liebe Grüsse, Dani

[2] https://wiki.openstreetmap.org/wiki/DE:Relationen/Relationen_sind_keine_Kategorien