DE talk:Proposed features/unified stoparea
Ich habe ein paar Fragen zu deinem Schema. Ich bin schon seit einiger Zeit auf der Suche nach Lösungen für meine detaillierten Haltestellen-Tagging-Probleme: Talk:Key:railway#Specialization_of_tram/subway-stop_tagging --E-Malte 10:51, 19 February 2009 (UTC)
- Sehr anschauliche Bilder. Was möchtest Du denn davon mit "meinem" Schema erklärt bekommen? ich sehe da prinzipiell keine Probleme. So grundsätzliche fragen wie "jeden Schienenstrang einzeln mappen oder nicht", sind außerhalb meines Schemas... --Gerrit 13:39, 19 February 2009 (UTC)
- Interessant wäre zu wissen, ob man für die Plattform eine Höhe (ground, low, high) angeben kann. Den Rest kann ich mir, denke ich, selbst zusammenwerkeln.
- Dann wüsste ich noch gerne den Unterschied zwischen railway=halt und railway=tram_stop. Bei mir in Düsseldorf wird beides für die gleichen Haltestellentypen verwendet. Vorstellen könnte ich mir tram_stop für ground- und low-Plattformen und halt für high-Plattformen. Wie denkst du dazu?--E-Malte 22:53, 19 February 2009 (UTC)
- Ich habe diese Begriffe so benutzt, wie sie (meines Wissens) momentan gebracht werden. "tram_stop" ist also nur für Straßenbahnen gebräuchlich, "halt" für andere Schienengebundene Fahrzeuge. Das korreliert sicher auch mit der Höhe des Bahnsteigs, wäre aber bei mir nicht der primäre Unterscheidungsgrund. Eine Tram/Straßenbahn teilt sich den Fahrweg über weite Strecken mit dem Auto/Bus-Verkehr. Also Schienen auf der geplasterten Fahrbahn. "tram_stop" könnte somit am gleichen Node existieren wie "bus_stop". Bei "halt" kann das nicht sein, dieser existiert nur auf reinen Schienenwegen. Wenn Dir die Unterscheidung nicht einleuchtet musst Du woanders nachhaken. :) --Gerrit 23:45, 19 February 2009 (UTC)
- Doch, die Unterscheidung leuchtet mir ein, danke! --E-Malte 09:55, 20 February 2009 (UTC)
- Nachtrag: Du kannst natürlich alle "üblichen" Tags (Breite, Höhe, Oberflächenbeschaffenheit, ...) dranmachen, die Dir sinnvoll erscheinen! --Gerrit 23:58, 19 February 2009 (UTC)
- Ich habe diese Begriffe so benutzt, wie sie (meines Wissens) momentan gebracht werden. "tram_stop" ist also nur für Straßenbahnen gebräuchlich, "halt" für andere Schienengebundene Fahrzeuge. Das korreliert sicher auch mit der Höhe des Bahnsteigs, wäre aber bei mir nicht der primäre Unterscheidungsgrund. Eine Tram/Straßenbahn teilt sich den Fahrweg über weite Strecken mit dem Auto/Bus-Verkehr. Also Schienen auf der geplasterten Fahrbahn. "tram_stop" könnte somit am gleichen Node existieren wie "bus_stop". Bei "halt" kann das nicht sein, dieser existiert nur auf reinen Schienenwegen. Wenn Dir die Unterscheidung nicht einleuchtet musst Du woanders nachhaken. :) --Gerrit 23:45, 19 February 2009 (UTC)
Und dann wäre da zusätzlich noch die Frage zu Bushaltestellen mit Einmündung, sowie als Plattform in der Mitte der Straße und am Straßenrand ohne Einmündung. Die letzten beiden entsprechen den Bahnhaltestellen in der Grafik im untersten Block, unten mitte und oben links. --E-Malte 10:51, 19 February 2009 (UTC)
- Mit Einmündung meinst Du "Busspur"? -> highway=service, darauf den highway=bus_stop und daneben als node oder way die highway=platform
- Hier muss man IMHO die Straße auftrennen und die Tram-Schiene loslösen. Wenn dort auch Busse halten, ebenfalls einen highway=service ablösen. Für tram findest Du [[1]] ein Beispiel.
- Das ist doch wenn ich Dich richt verstehe der häufigste Fall!? highway=bus_stop auf die Straße und daneben als node oder way die highway=platform --Gerrit 13:39, 19 February 2009 (UTC)
- Mit Einmündung meinte ich Haltebucht. Der Bus hält in einer Haltebucht bzw. neben der befahrenen Straße.
- Danke, für die Infos. --E-Malte 22:53, 19 February 2009 (UTC)
- Das meinte ich mit "Busspur" (fälschlich, denn Busspur ist ja eigentlich eher was anderes). Ich persönlich mappe einfache Haltebuchten als Node auf dem Way, aber wer es ganz genau möchte legt eben einen (sehr kurzen) highway=service an um dort den Node zu platzieren. --Gerrit 23:45, 19 February 2009 (UTC)
- Habe ich das richtig verstanden? highway=service auf den Node, wo die Haltebucht ist? Muss ich noch ein psv=yes hinzufügen? Und dann neben die Haltebucht den Node für die Bushaltestelle? --E-Malte 09:55, 20 February 2009 (UTC)
- Nein. Entweder auf die normale Straße nen Node mit highway=bus_stop ODER nen kleinen Extra-Weg mit highway=service malen (die Haltebucht) und DARAUF dann den Node mit highway=bus_stop --Gerrit 18:13, 20 February 2009 (UTC)
- Habe ich das richtig verstanden? highway=service auf den Node, wo die Haltebucht ist? Muss ich noch ein psv=yes hinzufügen? Und dann neben die Haltebucht den Node für die Bushaltestelle? --E-Malte 09:55, 20 February 2009 (UTC)
- Das meinte ich mit "Busspur" (fälschlich, denn Busspur ist ja eigentlich eher was anderes). Ich persönlich mappe einfache Haltebuchten als Node auf dem Way, aber wer es ganz genau möchte legt eben einen (sehr kurzen) highway=service an um dort den Node zu platzieren. --Gerrit 23:45, 19 February 2009 (UTC)
Noch eine neue Frage, eine Relation ist nur gedacht, für eine Haltestelle in eine Richtung, oder? Wenn mehrere Haltestellen existieren (Bus hin+zurück; Bahn quer), gibt es da auch eine Relation für? Zumindest entnehme ich das diesem hier: "Wenn sich dieses System weiter durchgesetzt haben sollte, kann man dem renderer beibringen, dass er in niedrigen Zoomstufen nur einen Namen und ein Symbol für die ganze Haltestelle anzeigt." --E-Malte 10:37, 20 February 2009 (UTC)
- Die Relation gilt für die gesamte Haltestelle, alles was den gleichen Namen trägt (also alle Richtungen!). Dadurch können an einigen Kreuzungen 4 bus_stop, 2 tram_stop und ebensoviele Plattformen in der Relation sein. An ZOBs häufig sogar mehr. Es war mal im Gespräch eine weitere Relation einzuführen um jeden Haltepunkt mit der zugehörigen Plattform zu verbinden, das finde ich aber zu aufwändig und wirklichen mehrwert gibt das IMHO auch nicht.
- Gut, danke! --E-Malte 21:28, 20 February 2009 (UTC)
Rendering
Hi,
eben habe ich gelesen, daß das schon gerendert wird. Bitte nimm doch dafür einen Absatz auf.
Außerdem habe ich gesagt, daß ganze ist nicht richtig verschlagwortet. Das bezieht sich auf den grünen Kasten. Die Felder sind dazu da, daß man sie ausfüllt :-)
--Lulu-Ann 15:58, 3 March 2009 (UTC)
- Hi der Kommentar zum Rendern steht am Ende des ersten Absatzes
- Da steht nur, wie es gerendert werden soll, nicht, daß es schon Renderer können. Ich hab dafür einen Absatz ergänzt. --Lulu-Ann 09:47, 4 March 2009 (UTC)
- Was die Verschlagwortung angeht, bin ich einfach nicht sicher, wie ich es eintragen soll. Es ist ja kein einzelner Tag, und z.B. die relation ist eine Tag-Kombination type=site;site=stop_area. Wenn Du da eine Idee hast, wäre ich Dir dankbar, wenn Du das ergänzen würdest. --Gerrit 22:00, 3 March 2009 (UTC)
- Hi, ich hab mal was ergänzt. Das Datum, wann Du den Request for Comments über die Mailingliste geschickt hast, müßtest Du aber bitte selbst eintragen. --Lulu-Ann 09:47, 4 March 2009 (UTC)
- Danke, mach ich. Auch für die englische Version. Dort auch gerne mitlesen/Fragen stellen. --Gerrit 15:00, 5 March 2009 (UTC)
- Hi, ich hab mal was ergänzt. Das Datum, wann Du den Request for Comments über die Mailingliste geschickt hast, müßtest Du aber bitte selbst eintragen. --Lulu-Ann 09:47, 4 March 2009 (UTC)
Weitere Verkehrsmittel
Haben wir alle öffentlichen Verkehrsmittel drin ? z.B. [hier] in Hamburg gehören Fähranleger und Bushaltestelle zusammen als Halt "Teufelsbrück". Mir fällt noch ein: Auffahrrampen für Autos auf Autoreisezüge, auch die gehören zu einer Haltestellenbezeichnung. Was ist mit Ski-Schleppliften oder Seilbahnen, die Anschluß an Buslinien haben? --Lulu-Ann 09:51, 4 March 2009 (UTC)
- Ich möchte ein zu breites Zielgebiet vermeiden. Dieses Proposal soll nur die Grundelemente festlegen, Dinge wie Auffahrtrampe können gerne woanders definiert werden (und dann in die relation mit aufgenommen werden. Prinzipiell könnte man natürlich auch Busstops UND Fährstops mit in die gleiche Relation packen. Bei ZOB/Bahnhof habe ich das bislang vermieden. --Gerrit 14:59, 5 March 2009 (UTC)
Unterscheidung Railway=halt, Railway=station
Ich halte das Weglassen dieser Unterscheidung nicht für sinnvoll. Ein großer, wichtiger Sackbahnhof wie Kiel würde mit seinen 6 Gleisen dann nur genauso groß ausfallen, wie ein Vorstadt-S-Bahnhof wie Letter mit 5 Gleisen, wo auf zweien davon nur Schnellzüge durchrauschen und eines nur in Ausnahmefällen noch für Personenverkehr benutzt wird. Ich denke die Unterscheidung sollte für den Renderer ersichtlich sein, damit hier die Zoomstufen unterschiedlich versorgt werden können. Ein ICE-Bahnhof ist was anderes als ein S-Bahn-Stop! --Lulu-Ann 10:04, 6 March 2009 (UTC)
- Die Unterscheidung kann man sicher brauchen, nur ist der einzelne "Haltepunkt" nicht der passende Platz dafür, weil es eine Eigenschaft des gesamten Gebildes ist (und an allen Haltepunkten der gleichen stop_area identisch sein müsste). So was sollte in die Relation, meinetwegen als stop_area=railway_halt, stop_area=railway_station oder so. --Tordanik 16:05, 6 March 2009 (UTC)
- Es werden ja mit Halt auch nicht alle Gleise getagt, sondern nur die Haltepunkte. Durchfahrtgleise spielen hier also keine Rolle. Die zweistufige Unterscheidung halt/station ist da mMn deutlich dürftiger. Ein "importance-Tag" an die stop_area-Relation mag eine gute Lösung sein, hat für mich jedoch keine hohe Priorität. Eine direkte Unterscheidung über den Typ der Relation (wie Tordanik vorschlägt) lehne ich ab, dann haben wir ja das gleich Kuddelmuddel wie jetzt. --Gerrit 21:43, 6 March 2009 (UTC)
- Nun ja, ich fände es aus "politischen" Gründen keine schlechte Idee, das Thema schon mal zu lösen. Ansonsten wird vielen das Proposal aus genau diesem Grund nicht gefallen. Wahrscheinlich ist zudem, dass es sich einbürgern würde, die bisherigen Tags auch innerhalb der relation-basierten Lösung beizubehalten, was ich nicht für wünschenswert hielte.
- Mein Denkanstoß (das Tag ist übrigens, zur Klarstellung, als Zusatztag gemeint) ist absichtlich so ausgelegt, dass lediglich die "Struktur" der Haltestelle reformiert würde, aber nicht die prinzipielle halt-stop-Unterscheidung. Durch die Anbringung an der Relation halte ich das für ein bisschen besser als bisher, wenn auch natürlich nicht ideal. Wenn jemand eine bessere Lösung hat, nur her damit. --Tordanik 08:04, 7 March 2009 (UTC)
- Ich fände einen neuen, neutralen tag "relevance", "importance" oder so besser, da er Verkehrsmittelunabhängig gilt. Es gibt ja auch etwa kombinierte TRAM/BUS Haltestellen, oder TRAM/U-BAHN/S-Bahn-Stationen eventuell. Würdest Du dann stop_area=tram_station, stop_area=railway_station, oder so nehmen? Das widerspricht mMn dem "unified" :) --Gerrit 12:00, 8 March 2009 (UTC)
- Wenn du eine verkehrsmittelübergreifende Definition für "relevance"/"importance" finden kannst und das nicht zu einem Nachfolger für smoothness=very_horrible mutiert (sprich: wenn die Frage nach einem geeigneten Wertebereich gelöst werden kann), geht das natürlich, und würde auch eine feinere Abstufung erlauben als die bisherige Unterscheidung. Würde ich jederzeit zustimmen.
- So ein Typ-Tag würde aber einem etwas anderen Zweck dienen. Man kann zwar versuchen, aus einem importance-Tag, womöglich weiteren Tags und sämtlichen Elementen der Relation genug Information zu sammeln, um Fragen wie "Welches Icon nehme ich" oder "Schreibe ich im Namefinder 'Bahnhof X' oder 'S-Bahn-Haltestelle X'" zu beantworten. Das ist aber ziemlich kompliziert (ich schätze, derartiges können übliche Renderer momentan nicht) und kann auch dazu führen, dass ein Objekt "falsch" kategorisiert wird -- die meisten Objekte kann man als Mensch intuitiv kategorisieren, wobei auch Dinge wie Name, Erscheinungsbild usw. mit einbezogen werden. Ich hätte wirklich keine Lust, Code für so etwas zu schreiben, zumal man da ja auch auf Mutmaßungen angewiesen ist. Ich schätze insofern, ein Autor einer nicht auf öffentliche Verkehrsmittel spezialisierten Anwendung wäre für ein einzelnes "Typ"-Tag, das Informationen zu Verkehrsmittel und (grob) Größe in so etwas wie "tram_halt" oder "railway_station" panscht, sehr dankbar.
- Man sollte nicht den Fehler machen, Programmierer und Mapper durch Nichtexistenz eines (natürlich verfälschend groben) "Was-ist-das"-Tags zu detaillierter Analyse zu zwingen, die für ihre Zwecke nicht notwendig ist -- das führt nur zu ausbleibender Akzeptanz und/oder Fehlbenutzung. Es hat schon seinen Grund, dass man einen Supermarkt an shop=supermarket erkennen kann und nicht über vending=* und die Gebäudefläche identifizieren muss. ;) --Tordanik 16:35, 7 March 2009 (UTC)
- Ich sehe nicht wirklich einen konkreten Anwendungsfall für das was Du vorschlägst. Auf der Karte erkenne ich was dort hält am Icon und die Wichtigkeit an der Größe der Anlage, Haltestops etc. Ob der Bahnhof Annehmlichkeiten wie Kiosk, Restaurant, Shopping etc bietet sehe ich z.B. direkt an den Elementen der Relation. Ich sehe eine Unterscheidung zwischen Halt und Station (oder jede andere sprachliche Unterscheidung) als ziemlich willkürlich und es wird dann immer jemand kommen und seinen Dorfbahnhof mit Unterstellhäusschen als Station mappen wollen. :)
- Wenn es eine halbwegs amtliche Einteilung gibt (Vom Staat, von der Bahn, ...) dann kann das gerne übernommen werden, aber als Zusatztag (bahn:category=5 oder so). Wenn Du mir eine weltweit gültige und halbwegs stabile Definition nennst, was eine Station und was ein Halt ist (oder wie auch immer man es nennt), dann bin ich überzeugt das so zu übernehmen, aber solange plädiere ich für ein Mappen der Tatsachen und überlasse dem Auswerter die jeweils gültige Interpretation.
- Was Dein Supermarkt-Beispiel angeht: Da gibt es doch auch keine Unterscheidung zwischen dem Spar oder Edeka um die Ecke und dem Walmart oder Real!?
- Also wenn ich das bisher richtig verstanden habe, soll in die Haltestellen-Relation eingetragen werden, welche Verkehrsmittel an der Haltestelle halten (eventuell auch noch die Anzahl derer). Wenn ich da falsch liege, bitte ich um Aufklärung. Ich halte das durchaus für sinnvoll für eine Klassifizierung. Es halt oder station zu nennen, wäre Ermessenssache, das stimmt. Aber kein Renderer ist an ein halt oder station gebunden, sondern kann auch die sonstigen "Tatsachen" mappen. --E-Malte 23:33, 7 March 2009 (UTC)
- Was an einer Station hält ergibt sich hauptsächlich aus den Route-Relationen, bei denen sie mit drin ist. An der relation selbst würde ich da nichts hinzufügen. Wenn zweideutig, kann man bei den platforms mit serves=* anzeigen, welche von diesen Verkehsmitteln von dieser Plattform aus bedient werden. --Gerrit 11:59, 8 March 2009 (UTC)
- Also wenn ich das bisher richtig verstanden habe, soll in die Haltestellen-Relation eingetragen werden, welche Verkehrsmittel an der Haltestelle halten (eventuell auch noch die Anzahl derer). Wenn ich da falsch liege, bitte ich um Aufklärung. Ich halte das durchaus für sinnvoll für eine Klassifizierung. Es halt oder station zu nennen, wäre Ermessenssache, das stimmt. Aber kein Renderer ist an ein halt oder station gebunden, sondern kann auch die sonstigen "Tatsachen" mappen. --E-Malte 23:33, 7 March 2009 (UTC)
- Und zum Supermarkt-Beispiel: Ich finde, dass es ein Unterschied ist, ob man einen Kiosk, einen Dorfladen, einen Supermarkt oder einen Großmarkt hat. Und es ist ein Unterschied, ob der Laden Essen, Elektronik oder Klamotten verkauft. --E-Malte 23:33, 7 March 2009 (UTC)
- Gerrit, du erkennst auf der Karte am Icon, was da hält. Schön, aber woher erkennt die Karte, welches Icon sie dorthin setzt -- und zwar nicht das an jedem einzelnen Haltepunkt, sondern für das Gesamtgebilde? Das Icon hängt deiner Ansicht nach offenbar von den Verkehrsmitteln ab, sonst könnte man an ihnen ja nicht erkennen, was dort hält. Die Verkehrsmittel stehen aber nicht als Tag an der Relation, zumindest lese ich davon nichts in dem Proposal. Sie müssen also aus den Tags der Mitglieder der Relation ermittelt werden [an diesem Punkt hat sich die Sache für viele Renderer schon erledigt]. Wenn ich dann weiß, was für Verkehrsmittel dort halten, stellt sich -- wenn es mehrere sind -- immer noch die Frage nach der passenden Darstellung. Entweder zeichnet man mehrere Icons [kann auch wieder nicht jeder Renderer], oder man versucht, über Kriterien wie Verkehrsmittel mit den meisten Haltepunkten, "höchstrangiges" Verkehrsmittel oder Kombinationen daraus den Gesamttyp zu bestimmen [kann erst recht kein Renderer]. Es sind also für einen Renderer ziemlich komplexe Fähigkeiten nötig, nur um optisch zwischen einem Bahnhof und einer Bushaltestelle unterscheiden zu können. Bei "Größe" oder "Wichtigkeit" liegt der Fall eigentlich ähnlich. --Tordanik 09:42, 8 March 2009 (UTC)
- Ich stimme Dir zu, die Komplexität wird etwas zum Renderer verschoben. Des geht einher mit dem Mantra, das wir nicht für den Renderer taggen. Wenn ich solche Hilfen gleich beim taggen vornehme, muss ich das ja für alle möglichen Anwendungen machen. Stattdessen sollten ihm nur die wichtigen Infos gegeben werden, ob und was er damit macht ist seine Sache. Um bei Deinem Beispiel zu bleiben: Der Renderer guckt nach, welche Routen (bus, tram, train, ...) durch die stop_area laufen und stellt dann etwa in niedrigen Stufen das Icon der höchstwertigen Verkehrsart dar (welche das ist sollte irgendwo zentral definiert werden), bei mittleren Zoomstufen, werden vielleicht alle Icons im Zentrum der stop_area angezeigt und in der höchsten zoomstufe sieht man über jedem haltepunkt ein Icon für das dort haltende Verkehrsmittel. Dein Vorschlag läuft darauf hinaus, dem renderer mehr oder weniger explizit zu sagen was er doch bitte in bestimmten Zoomstufen zu rendern habe. Natürlich ist das für den renderer sehr viel einfacher, aber wenn Du das für alle möglichen Anwendungen machst, wird es chaos. Zusätzliche Tags zur Renderhilfe (wie das leider immernoch benutzte osmarender=yes), damit diese es übergangsweise leichter haben sind etwas ganz anderes, das kann man natürlich optional machen, aber sowas soll nicht Teil dieses Kernproposals sein. --Gerrit 11:59, 8 March 2009 (UTC)
- Können wir so was wie Godwin's Law mit "Taggen für den Renderer" einführen? ;) Es geht hier nicht um Schwächen einzelner Renderer, sondern um eine generell erhöhte Komplexität, die in allen zukünftigen Renderern eingebaut werden müsste. Es geht auch nicht nur um Renderer, sondern alles, was POI in Kategorien einsortiert, eine Beschreibung des Typs in einem Suchergebnis anzeigt o.ä. Mein Vorschlag läuft daraus hinaus, etwas, das Menschen intuitiv können (ein Objekt unter Einbeziehung von allen möglichen Faktoren -- Größe, Alter, Nutzung, Bauweise, Name, lokale und überregionale Bedeutung, Betreiber, ... -- in eine Schublade zu stecken) dem Computer, der dazu einen komplizierten Algorithmus bräuchte und bisweilen vom erwarteten Ergebnis abweichen wird, abzunehmen.
- Ich bleibe bei meiner Ansicht, dass Detailinformationen, die nur für einen kleineren Nutzerkreis interessant sind, nicht die allgemeine Einordnung ersatzlos streichen, sondern zusätzlich angebracht werden sollten. Und bei der Einschätzung, dass sich ein Vorschlag, der die "entweder in allen Einzelheiten oder gar nicht"-Route wählt, schlicht nicht durchsetzen wird. --Tordanik 14:06, 8 March 2009 (UTC)
- Ich mag das ewige zitieren des Tagges für den renderer auch nicht. Insofern sorry für die Verwendung. :) Ich habe nichts gegen Zusatztags, die die Bedeutung einer Haltestelle explizit herausstellt. Ich möchte diese nur nicht als per se Ausschlaggebend und festen Bestandteil in das Proposal einführen um es nicht zu komplex werden zu lassen. Kannst Du vielleicht ein einfaches Kennzeichnungssystem entwickeln und kurz beschreiben? Wenn Du mit 1-2 Sätzen auskommst, packe ich es direkt bei Weitere Details/Optionales mit dazu, ansonsten mach doch ein eigenes Proposal auf, zu dem ich dann verlinke. --Gerrit 16:04, 8 March 2009 (UTC)
- Überspitzte, dafür aber hoffentlich verständlichere Version des Supermarkt-Beispiels: Wenn jemand sämtliche Regale eines Supermarktes samt Inhalt eintragen und in eine Relation packen will, na meinetwegen. Wenn er dann aber shop=supermarket zugunsten des unified shop abschaffen will, der von mir erwartet, dass ich das Icon für meinen Shop (in meinem Renderer, der sich für Regale nicht interessiert) aus den Inhalten und der Anzahl der Regale in der Relation ermittle, statt über ein einzelnes Tag, dann finde ich das nicht mehr sehr überzeugend -- obwohl sämtliche objektive Information ja eigentlich vorläge. Ich würde in diesem Fall begrüßen, wenn man an die shop-Relation zumindest etwas wie shop_type=supermarket schreiben könnte. --Tordanik 09:42, 8 March 2009 (UTC)
- Naja, ein etwas passenderer Vergleich wäre hier, wenn man die Anzahl der Kassen verwendet anstelle der Regale. Ganz ehrlich: Das fände ich gar nicht schlecht. Natürlich wird so bald niemand Kassen oder Regale einzeichnen, aber ein shop=convenience mit level=* oder eine Einstufung Anhand der Gebäudegrundrissgröße fände ich tatsächlich sinnvoller als shop=tante_emma, shop=small_super_market, shop=discounter, shop=normal_supermarket, shop=big_supermarket_but_only_food, shop=big_supermarket, etc. Immerhin erfüllen alle diese Läden den absolut selben Zweck, nur in unterschiedlichem Maße. Ich würde auch nicht unterschiedliche Tags für Parkplätze einführen, je nachdem ob man schräg einparkt, gerade, seitlich, ... ;-) --Gerrit 11:59, 8 March 2009 (UTC)
- shop=convenience mit level=* trifft es wieder nicht, weil es algorithmisch viel einfacher ist. Mehrere Tags am selben Objekt sind überhaupt kein Problem und gegen eine solche Beschreibung hätte ich auch bei den Bahnhöfen nichts. --Tordanik 14:06, 8 March 2009 (UTC)
Eingang oder Haltepunkt?
Wie soll bei U-Bahn-Haltestellen verfahren werden? Sollen außer den Haltepunkten auch die Eingänge eingezeichnet werden? Manchmal sind die Haltepunkte unterirdisch gar nicht genau positionierbar oder sie liegen unter einem Kartenelement, daß ein Rendern an dieser Stelle unmöglich macht. --Lulu-Ann 10:58, 6 March 2009 (UTC)
- Meine Meinung: Ja, sie sollen eingezeichnet werden. Dazu nehme man railway=subway_entrance und packe es mit in die Relation des U-Bahnhofs. Natürlich kann man trotzdem auch die anderen Sachen zeichnen, so gut man es halt messen kann. --Tordanik 16:09, 6 March 2009 (UTC)
- Sehe ich genau so. --Gerrit 21:44, 6 March 2009 (UTC)
Aufnahme der Platformen in die routen relationen
Ich verstehe nicht, wieso die Plattformen nicht in die routen-Relationen aufgenommen werden sollen. Meines Erachtens sind diese wesentlich wichtiger als die Stop-Positionen, da man sonst nicht erkennen kann, auf welcher Seite des Stop-Punktes man auf sein Verkehrsmittel warten muss. Die Stop-Positionen ergeben sich ohnehin falls die Plattformen in der Relation sind durch Projektion der Plattformen auf den Linienweg und sind somit eigentlich redundant. --Nimix 09:39, 28 June 2009 (UTC)
- Dem schließe ich mich an: Die Platformen müssen auch unbedingt für die Blinden-Navis zuzuordnen sein! --Lulu-Ann 00:04, 29 June 2009 (UTC)
- Schließe mich aus ähnlichen Gründen an. Bei größeren Haltestellen (ZOB,...) ist eine genaue Zuordnung der Platform zur Bus/Bahnlinie für die Navigation wichtig. --Black_Ivory_1986 13:10, 03 Jan 2010
- Ich benutze User:Oxomoa/ÖPNV-Schema da gehört die Plattform im Unterschied zur Beschreibung hier mit zur Haltestelle und das ist ja auch logisch, weil man steigt ja z.B. bei der Bahn nicht auf freier Strecke aus, nur weil da vielleicht jemand mal irgendwann einen (Bedarfs)Haltepunkt festgelegt hat. Selbst bei den Abstellgleisen für die berliner S-bahn ist noch eine kleine Treppe an der Fahrertür als Plattform vorhanden. --Fabi2 18:19, 25 February 2010 (UTC)
Wo den bus_stop hinsetzen? (erledigt)
So wie ich das verstanden habe, soll der bus_stop immer auf dem dazugehörigen Weg sein und es soll nur einen davon geben. Was mache ich jetzt, wenn eine Bushaltestelle auf dem Hin- und Rückweg auf verschiedenen Straßen angefahren wird? Beispiel (Mapnik): Dort wird die Bushaltestelle Busbrookshöhe in der einen Richtung auf der Straße Busbrookhöhe bedient und in der anderen Richtung durch den Berner Heerweg. Nach dem alten System war es eindeutig: Dort wurde einfach bei beiden Bushalten jeweils ein bus_stop hinzugefügt. Nach dem neuen System scheint mir der bus_stop leicht willkürlich gewählt zu werden (siehe auch Anmerkung von Nimix).--plaicy 10:28, 8 July 2009 (UTC)
- Natürlich muß es zwei Bus-Stops geben, wenn sie nicht genau gegenüber sind. --Lulu-Ann 13:58, 9 July 2009 (UTC)
- Okay, habe ich wohl das Mindestens überlesen. Wenn ich das jetzt ganz richtig verstanden habe, muss ich jeweils an den Weg eine Service-Straße bauen und darauf den bus_stop setzen: Das ist dann der Punkt, wo der Bus wirklich hält (wenn es eine Bus-Halte-Bucht-gibt). Wenn man die Halte-Bucht weglässt (so genau kann man gar nicht messen), kommt der Punkt einfach direkt an die entsprechende Stelle auf den Weg. Daneben kommt dann ein Punkt mit highway=platform wo das Haltestellenschild steht.--plaicy 15:22, 9 July 2009 (UTC)
- Ja, Platform kann auch ein Way sein, wenn man einen längeren Busteig hat. --Lulu-Ann 09:50, 12 July 2009 (UTC)
- Okay, habe ich wohl das Mindestens überlesen. Wenn ich das jetzt ganz richtig verstanden habe, muss ich jeweils an den Weg eine Service-Straße bauen und darauf den bus_stop setzen: Das ist dann der Punkt, wo der Bus wirklich hält (wenn es eine Bus-Halte-Bucht-gibt). Wenn man die Halte-Bucht weglässt (so genau kann man gar nicht messen), kommt der Punkt einfach direkt an die entsprechende Stelle auf den Weg. Daneben kommt dann ein Punkt mit highway=platform wo das Haltestellenschild steht.--plaicy 15:22, 9 July 2009 (UTC)
- Und wo genau setze ich den [bus_stop] hin? Gegenüber dem Schild auf der Plattform oder da wo der Bus wirklich hält (dies kann vom Schild ja ca. 10 m entfernt in Fahrtrichtung liegen)?--Josef73 19:17, 9 August 2010 (BST)
- Geht man nach den bei Zügen benutzten Schema, steht dort das H-Schild am Gleis (=Haltepunkt) immer an der Fahrzeugspitze, dem ensprechend ist dann bei Bussen die stop_position auf Höhe des Fahrersitzes. Der bus_stop ist, wenn als als Linie eingetragen, der Bereich der Haltestelle und wenn als Punkt eingetragen, der Ort, wo das Haltestellenschild steht. --Fabi2 19:26, 21 August 2010 (BST)
- Bisher wird der Standort des H-Schildes (Zeichen 224) eingezeichnet. An dieser Stelle sind meist die Informationen über die Abfahrt der Busse zu finden. Nun soll die Stelle eingezeichnet werden, wo der Bus hält. Dies ist aber eher subjektiv, da es laut StVO nicht festgelegt ist wo der Bus halten soll. Es ist festgelegt: "Durch das Zeichen werden Haltestellen für Straßenbahnen und für Linienbusse gekennzeichnet." Und desweiteren "Fahrzeugführer dürfen bis zu 15 m vor und hinter dem Zeichen nicht parken.Erläuterung: Das Zeichen kennzeichnet eine Haltestelle des Linienverkehrs und für Schulbusse." Auszug aus der StVO. Und ein Vergleich mit den Zügen hingt etwas. Hier ist festgelegt wo die Haltetafel Ne 5 steht :"Kennzeichnung des Halteplatzes der Zugspitze bei planmäßig haltenden Zügen" Auszug aus dem Signalbuch Ril 301.--Josef73 21:04, 23 August 2010 (BST)
- Geht man nach den bei Zügen benutzten Schema, steht dort das H-Schild am Gleis (=Haltepunkt) immer an der Fahrzeugspitze, dem ensprechend ist dann bei Bussen die stop_position auf Höhe des Fahrersitzes. Der bus_stop ist, wenn als als Linie eingetragen, der Bereich der Haltestelle und wenn als Punkt eingetragen, der Ort, wo das Haltestellenschild steht. --Fabi2 19:26, 21 August 2010 (BST)
- Natürlich muß es zwei Bus-Stops geben, wenn sie nicht genau gegenüber sind. --Lulu-Ann 13:58, 9 July 2009 (UTC)