Diese Haltestelle hat aber beidseitig WartehÀuschen so wie eingezeichnet. Bin da erst vorbeigekommen.
Das macht alles nur noch komplizierter, denn wo erfassen wir dann die Eigenschaften der Bushaltestelle? Etwa dreifach an stop_position, platform und bus_stop?
Entweder hĂ€tte man dann die neuen Tags auf die zusĂ€tzlichen Objekte beschrĂ€nken sollen, oder auch bei den anderen Objekten konsequent anwenden sollen. Wenn die Tags bei den anderen Objekten inkonsequent angewendet werden, erzielen sie keine Vereinheitlichung und stellen dort nur DatenmĂŒll dar, der keiner Anwendung hilft.
Ja. PTv2 erlaubt es, die neuen Tags nur bei den zusĂ€tzlichen Objekten anzuwenden. Das musste so sein, denn es durfte ja keine Situation entstehen, bei der man die Haltestellen wegen der Routen hĂ€tte umstellen mĂŒssen und die Routen wegen der Haltestellen. Dann hĂ€tte man die ganze Welt in einem Changeset auf PTv2 umstellen mĂŒssen.
Andererseits wollte man auf die Dauer eine Gesamtumstellung haben und erlaubte auch Doppeltagging. Diese Gesamtumstellung wird aber nicht vollstĂ€ndig passieren, da highway=bus_stop fĂŒr die Kartendarstellung praktisch nicht zu ersetzen ist. Da sowohl stop als auch platform einzeln optional sind und an keinem der beiden dransteht, ob es den anderen gibt, stehen die Kartenhersteller vor einem nur sehr schwer lösbaren Darstellungsproblem. Da auĂerdem noch zu einer Platform mehrere Stops gehören können und zu einem Stop mehrere Platforms, kann man ein einzelnes Symbol fĂŒr eine Haltestelle aus public_transport-Tags allenfalls nach Analyse aller beteiligten Relationen ermitteln. Deshalb muss highway=bus_stop bleiben.
Diese Situation ist etwas unangenehm. Sie wird aber massiv dadurch verschlechtert, dass viele Mapper denken, sie mĂŒssten jetzt ĂŒberall aus einem einfachen und völlig ausreichenden âhighway=bus_stop, name=Kalles RĂŒbenfeldâ auf der StraĂe zwei stop_positions, zwei Platformlinien und eine stop_area_Relation machen ohne auch nur ein bischen reale Information hinzuzufĂŒgen.
Wir sollten jetzt nicht PTv1 und PTv2 verdrehen, um die Probleme zu lösen. Das ist leider das, was im Moment in vielen Wikis und in der Praxis passiert (und das ist der Grund, warum ich mit ĂPV-Mapping aufgehört habe). Wir sollten es statt dessen sinnvoll und genau so wie es da steht anwenden und gleichzeitig gemeinsam an einem sorgfĂ€ltig durchdachten PTv3 mit praktisch brauchbaren Umstellungsregeln arbeiten.
Konkurrierende Standards sind kein Problem! Man wird dann sehen, was sich durchsetzt und benutzt wird. Wir können z.B. bei der Computerei Dateien mit ftp oder mit rsync oder mit sonstwas kopieren. Kein Problem!
Wenn aber die Erfinder von rsync einfach RFCs fĂŒr ftp umgeschrieben hĂ€tten um sich den rsync-Ideen anzunĂ€hern ⊠dann hĂ€tten wir ein Problem! Deshalb bin ich gegen die verbreiteten Bastelarbeiten an den Regeln fĂŒr highway=bus_stop, an PTv1-Routen und an dem ganzen PTv2-Kram.
Muss mich korrigieren: highway=bus_stop wir auch bei FlÀchen angezeigt⊠nur nicht bei Wegen
FlÀche:
http://www.openstreetmap.org/way/241589910#map=19/48.07168/11.88826
Weg:
http://www.openstreetmap.org/way/482999237#map=19/48.17200/11.80904
Ja⊠aber irgendwo sind wir hier mit widersprĂŒchlichen stellen im Wiki⊠zum einen highway=bus_stop ist gleich der public_transport=platform + bus=yes. highway=bus_stop soll gemappt werden ist sogar âImportantâ. Aber highway=bus_stop darf nur als node erfasst werden, public_transport=platform in jeder Form⊠das beiĂt sichâŠ
public_transport=stop_position mit highway=bus_stop ist ein Fehler
highway=bus_stop nicht als node ist ein Fehler
Und das highway=bus_stop auch bei FlĂ€chen angezeigt wird ist eine Feststellung, ich mappe sowas eh nicht⊠mehr als eine Node auf jeder Seite der StraĂe gibt es bei mir eh nicht.
Das zweite Beispiel von mir ist auch so vor Ort nicht vorhanden und wird demnÀchst geÀndert⊠ich suche nur nach dem besten Weg es abzuÀndern. Wenn es keine zufriedenstellende Lösung gibt wird es gegen eine einzelne Node ersetzt. Informationen gehen da nicht verloren da der Mapper der das gemappt hat anscheinend nicht vor Ort war.
Aber wenn du es besser weiss was wÀre ein praktisches Beispiel im OSM wie es zu mappen ist?
Wie eine Shelter mappen? Und wenn man extra diesen als FlÀche mappt?
MĂŒlleimer⊠usw. Infrastruktur⊠wie gehört dieses ganze detailmapping⊠ohne das es ĂŒberall Probleme macht⊠also Beste Praxis 
Jein.
Das bus=yes an platforms ist keine PTv2-Idee. Derartige *=yes - Tags gibt PTv2 nur bei Stops an.
Eine PTv2-Haltestellenangabe kann bis zu zwei Komponenten haben: die Stop-Komponente (Rolle âstopâ) und die Platform-Komponente (Rolle âplatformâ). Nodes mit highway=bus_stop sind stets eine dieser Komponenten. Welche es ist, hĂ€ngt davon ab, ob der Node Teil des Fahrwegs ist.
Nein
Ja
Das ist fĂŒr sehr viele Haltestellen eine gute Idee. FĂŒr gleich getaggte einander praktisch gegenĂŒberliegende kommt man sogar mit nur einem Node im Fahrweg aus. Und das ist voll und ganz PTv2-Mapping!
Wo steht das? Das man public_transport=stop_position soll/kann?
Auf diesen Seiten schonmal nichtâŠ
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop#Stop_position
http://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dstop_position
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Stop_position
Und nicht Idee Idee von PTV2⊠fakt ist das seit 2011 nicht viel in der Richtung an Neuerung gegeben hat⊠dieses PTV2 hĂ€tte man auch sein lassen könnenâŠ
Hallo,
Kannst du die Behauptung, es gebe WidersprĂŒche im Wiki bitte mit Links und Zitaten belegen? Andernfalls ist sie substanzlos.
Viele GrĂŒĂe
Michael
Wo fangen wir an⊠public_transport=stop_position
siehe Post #29
Wie kommt man da drauf hier highway=bus_stop anzubringen? Auf den 3 Seiten steht dazu nichts.
Seh ich das richtig?
Dann ist das hier falsch:
http://www.openstreetmap.org/node/393944491
Oder?
Denn highway=bus_stop ist so definiert:
(siehe: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop )
Belegt genug?
Unter âCompatibility with well known tagsâ steht bei âhighway=bus_stop on a way/street where buses are allowedâ âInterpreted asâ âpublic_transport=stop_position + bus=yesâ sowie âThis covers the stop position of a bus.â
Und natĂŒrlich darf man an eine stop position auch noch public_transport=stop_position schreiben auch wenn das redundant ist.
Der letzte Satz ist nur richtig soweit er sich auf die highway=bus_stop bezieht, die im ersten Satz genannt werden. Das sollte vielleicht deutlicher formuliert werden.
Da hast Du recht. Die Aussage unter bus=yes ist eindeutig falsch. âAccording to the public transport schema this replaces highway=bus_stop.â Das steht nirgendwo im public transport schema. Dort steht ausdrĂŒcklich das Gegenteil: âThis proposal does not replace, deprecate or obsolete the already existing and well known tags.â
Ja hier ist geregelt wie man mit -bestehenden- umgeht⊠oder zu verstehen sind. Da steht aber nicht das man highway=bus_stop von der platform auf die stop_position kopieren sollâŠ
Und bei PTV 1 hat man entweder links und recht der StraĂe eine Node erfasst oder eine Node fĂŒr alles auf die StraĂe aber nicht beides! Wenn man links und rechts erfasst hat, hat man wenn auf der StraĂe eine Node war diese entfernt. Das heiĂt wenn die StraĂeseiten erfasst sind kommt highway=bus_stop auf diese.
Dieser Satz diente aber wohl nur dazu, Widerstand beim Voting zu vermeiden, und war vermutlich keineswegs Ernst gemeint. Sonst hÀtte der Autor des Proposals nicht kurz nach erfolgreichem Voting in die Wiki-Seite von highway=platform eingetragen, dass dieses Tag durch public_transport=platform ersetzt wurde. (Siehe https://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dplatform&diff=next&oldid=628854 )
Dass man somit ĂŒber etwas abgestimmt hat, was dem eigentlichen Sinn des Proposals widersprach, dĂŒrfte auch ein Grund fĂŒr das erzeugte Chaos sein.
Das halte ich fĂŒr Quatsch.
Wenn man das Proposal entgegen seinem Text so interpretiert, dass die die alten Tags durch die neuen ersetzt werden sollen, dann wird es offensichtlich undurchfĂŒhrbar: Zu einer geĂ€nderten Haltestelle mĂŒssten alle ihre Routen geĂ€ndert werden und zu einer geĂ€nderten Route alle ihre Haltestellen. Die ganze Welt hĂ€tte also auf einen Schlag geĂ€ndert werden mĂŒssen. Und highway=platform hat mit PTv1 nichts zu tun da diese Objekte ĂŒberhaupt nicht in den PTv1-Routen auftauchen können. Abgesehen davon spielt es sowieso keine Rolle, denn wir haben ĂŒber den Text abgestimmt und nicht ĂŒber hypothetische Hintergedanken.
Es geht hier nicht um eine Umdeutung des Abstimmung, aber eine Rolle dĂŒrften solche Hintergedanken schon spielen.
Zum einen scheinen einige Festlegungen und Formulierungen des Proposals nur auf Basis solcher Hintergedanken logisch zu sein. Wenn der Autor solche Hintergedanken verfolgt hat, hat dies auch möglicherweise dazu beigetragen, dass die Dokumentation entspechend inkonsistent ist, was dann zu unterschiedlichen Interpretationen fĂŒhrt.
Selbst wenn das abgestimmte Proposal Tags deprecated hĂ€tte, muss dies natĂŒrlich bei der Umstellung nicht bedeuten, dass man diese als erstes entfernt, solange man sie noch fĂŒr alte Routen benötigt. NatĂŒrlich sollte das Proposal dann besser geeignete VorschlĂ€ge fĂŒr eine abgestufte Vorgehensweise enthalten.
Und mal eine ketzerische Frage: Woraus entnimmst du dem abgestimmten Text eigentlich, dass PTv1 Routen ĂŒberhaupt noch gĂŒltig sind? Das Proposal hat doch eine eine neue Festlegung darĂŒber getroffen, wie die Routen aussehen sollen.
Abgesehen davon wird ein Proposal nicht gleich undurchfĂŒhrbar, nur weil es mal ĂŒbergangsweise etwas kaputtmacht. Die meisten Proposals, die nicht nur etwas ergĂ€nzen, fĂŒhren zunĂ€chst mal in RealitĂ€t zu einer Verschlechterung.
Erstens war der Satz, dass die bekannten Tags nicht ersetzt werden, nicht auf PTv1 Tags limitiert.
Zweitens kann man highway=platform als die zur PTv1 nötige ErgÀnzung ansehen, um nicht ausgedehnte Platforms mappen können. Ob das nun in der Routenrelation aufgenommen wird oder nicht, spielt da keine Rolle. Wenn PTv2 beispielsweise definiert hÀtte, dass nur die Stops in die Route kommen, hÀtte public_transport=platform immer noch zum PTv2 Konzept gehört.