Einheitliche Regeln für die Erstellung von Haltestellen

Haltestellen zu Relationen zusammenzufassen halte ich für eine gute Idee…

Da muss ich leider zustimmen. Die Darstellung ist noch nicht besonders ausgereift, und es gibt auch noch zu wenig alternative Renderer. Ich würde mir auch gerne Karten selber rendern, aber ich finde das zur Zeit noch sehr umständlich. Außerdem lässt die Online-Navigation, und die Portierung in Karten für Navigeräte auch noch zu wünschen übrig. Allerdings brauchen wir für Navigation und änlichem auch genug Daten in der Datenbank. Wichtig ist auf jeden Fall, dass die Daten in der Datenbank so ausgelegt sind, dass sie sich für alle Zwecke eignen. Dann haben Entwickler von Renderern oder anderer Software auch eine vernünftige Grundlage, mit der sie arbeiten können. Edit: Die von Seb1982 aufgestellten Regeln könnten dann durchaus auch in eine Renderersoftware geschrieben werden. Dort wären die Regeln sinnvoller aufgehoben, als in der Datenbank.

Du musst nur zwei kleine Unterschiede zwischen den kommerziellen und OSM machen: 1. Die kommerziellen erheben ihre Daten nur für sich selbst und können daher klarer definieren wie sie Namen schreiben bzw. generell Daten erfassen und vor allem WAS sie erfassen wollen, OSM erhebt die Daten für alle und soll für möglichst viele Zwecke geeignet sein. Das ist zwar ein Problem, aber kein Unlösbares wie ich finde. OSM muss flexibel sein und das ist es nicht wenn es nur abgekürzte Namen enthält. 2. Die kommerziellen gibt es schon seit Jahrzehnten und hatten genug Zeit ihre eigenen Renderer entsprechend zu entwickeln. OSM gibt es erst seit 4 Jahren und muss sich erst noch entsprechend entwickeln. Es gibt genügend möglichkeiten wie die Renderer die Datenflut von OSM übersichtlich aufbereiten können. Diese Möglichkeiten müssen halt erst entwickelt werden, aber kommt Zeit kommt Rat. Die Daten in der Datenbank von OSM müssen möglichst vollständig sein, wenn alles nur abgekürzt wird blickt irgendwann keiner mehr durch und vor allem wird es Massiv Probleme beim suchen von Haltestellen oder Straßennamen geben. Denn im Zweifelsfall gibt der Ottonormalverbraucher immer den kompletten Namen an.

Hallo Markus,

mein Reden :slight_smile:

und genau hier werden sich wohl auch weiterhin die Geister scheiden. Wer heute neu zu Openstreetmap dazukommt, ist sich mit Sicherheit nicht über die Wurzeln des Projekts einerseits und den technischen Möglichen andererseits bewußt - OSM “ist” die Karte. Das war aber nicht immer so, und es mindert den Nutzen des Projekts, wenn man sich damit begnügt.

Im Gegenteil :slight_smile: - das zwingt die Leute dazu, aus der reinen Konsumhaltung (“ich will eine Karte bekommen, die genau meinem Geschmack und meinen Anforderungen entspricht”) herauszukommen und aktiv zu werden (“ich mache Verbesserungsvorschläge” / “ich mach selber eine Karte, die genau meinem Geschmack und meinen Anforderungen entspricht”).

Das die wenigsten selber rendern, ist klar und wird auch so bleiben (wobei - wenn ich Kosmos nutze oder mir eine OSM-Karte für meinen Garmin bastele, rendere ich im weitesten Sinne auch…). Alles andere ist eine Frage der “Vermarktung” der bisher konkurrenzlosen, OSM-basierten Lösungen, des Geschmacks (in gut erfassten Gebieten schlägt OSM die “Kommerziellen” um Längen) und der Frage, ob man schiefe Maßstäbe und das Ausblenden der Möglichkeiten, die in OSM stecken, akzeptiert. Ich bleibe dabei: Der eigentliche Wert von OSM steckt nicht in der SlippyMap, sondern der freien Verfügbarkeit der Daten, und in den Möglichkeiten, die sich daraus ergeben. Grüße florian

Huch, dieses Thread hatte ich wohl übersehen. Gleiches Thema wie bei mir: Einheitliches Vorgehen. Könnten wir die Debatte darüber vielleicht auch der Diskussionsseite dieser Wiki hier weiterführen, also zumindest die jeweiligen Ergebnisse dort festhalten: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Nahverkehr Es scheint auch die eine oder andere Mailingliste zu geben, die sich mit dem Thema beschäftigt. Aufruf an eventuelle Teilnehmer: Speist bitte Ergebnisse von dort auch auf der Wiki ein, denn letztere haben aus meiner Sicht die höhere Reichweite, insbesondere bei neuen OSMlern. So, und jetzt werde ich erstmal die Artikel oben in Ruhe lesen :wink: PS: Was die Unübersichtlichkeit der jetzigen Karten betrifft: Das Instrument, um dem zu begegnen, gibt es doch schon längst: Overlays. Zur Zeit stellen die Renderer vielleicht noch ein bisschen viel dar, aber irgendwann wird es die Basiskarte geben und entsprechende Overlays. So machen es Mitbewerberprodukte auch, und sowas findest man auch bei OSM schon. Da muss man nur noch ein bisschen Geduld haben. Gute Beispiele sind eben die ganzen “störenden” Kneipennamen und so weiter. Die lassen sich wunderbar in ein Alk-Overlay packen :wink: PPS: Einige der anderen Punkte werden sicher von den Relationen erschlagen, wenn man sie sauber anwendet. Aber letzters erfordert eben ein bisschen koordiniertes Vorgehen, deshalb nochmal der Hinweis auf die Wiki oben, in der am Ende alle How-To´s stehen sollten. PPPS: Seb, hattest Du nun eine Wiki angelegt, wie angekündigt? Ich hatte nichts passendes finden können, bevor ich “meine” angelegt hatte. Ggf. sollten wie die zusammenfassen oder verlinken, sofern es “Deine” auch gibt.

zu Regel 1: Bin dagegen - jede Seite erfassen ist sinnvoller. zu Regel 2: Abkürzungen sind IMHO auch eine gute Idee. zu Regel 3: Ich würde generell den Namen der Haltestelle differenzieren: (H) NAME / (S) NAME / (DB) NAME - somit ist in der Suche des Navis direkt ersichtlich ob es sich bei dem POI um den Straßennamen oder die Haltestelle handelt. Auch sollte man diskutieren wie ein Taxibus eingetragen wird. Bei uns fahren zu bestimmten Uhrzeiten kaum Busse. Sie werden größtenteils durch Taxibusse ersetzt. Diese fahren das Streckennetz der Buslinie ab - jedoch haben sie auch noch zusätzliche Haltestellen. Wie sollte man da verfahren? Sollte die Rufnummer für diese Busse hinterlegt werden?

In Berlin bieten einige Nachtbusse für einen bestimmtes Gebiet einen Haustürservice an. Wie taggt man diese Gebiete? Die Rufnummer der Busse kann man ja Problemlos mit phone=nummer taggen. http://wiki.openstreetmap.org/wiki/Key:phone

Regel 1: Bei Bussen mache ich jetzt auch immer alle Punkte. Der Renderer muss sich das selber sortieren. Wichtig ist dabei natürlich, dass alle Haltestellenpunkte den gleichen Namen haben, sonst ist nicht zu erkennen, dass es sich um ein und dieselbe Haltestelle im Netzplan handelt. Regel 2: Abkürzungen - nein, also ich bin auch dagegen. Die Algorithmen, das passend abzukürzen, sind nicht allzu schwierig und können vom Renderer durchaus bewältigt werden. Das hatte ich vor etlichen Monaten schon mal irgendwo angeregt auf den Kosmos-Seiten, glaube ich. Da ging es um die Abkürzung von Straßennamen, wenn die Straßen sehr kurz sind. Gleiche Bausstelle sozusagen. Alles, was man braucht, ist je ein Template für jede Sprache, das die Regeln vorgibt. Lässt sich wunderbar per Wiki erschlagen, so wie es bei der Potlatch-Übersetzung gehandhabt wird. Taxibusse sind sicher nichts ungewöhnliches. Hier in Köln gibt es z.B. auch den sog. Rufbus, der z.T. auch eigene Haltestellen hat. Dürfte ein ähnliches Prinzip sein. Aber was unterscheidet solche Busse wirklich von den anderen? Die angefahrenen Haltepunkte kommen in eine Relation, die Wege kann man da vielleicht weglassen (könnte man bei Bussen möglicherweise sowieso, würde ich aber nicht), Telefonnummer rein und fertig. Wie TEL schon geschrieben hat. Das mit dem Haustürservice ist natürlich schwierig, aber auch diese Busse dürften den einen oder anderen festen Halte- oder Anlaufpunkt haben. Wer sich so ein Ding ruft, weiß ja dann, dass es den Haustürservice u.U. gibt. Das weiß man ja von Taxis aus, und da werden auch nur die Taxistände getaggt :wink:

Es wär schon wichtig zu sehen welches Gebiet dieser Haustürservice umfasst, und ob es einen gibt. Denn sonst kann man vorher nicht entscheiden, ob ein anderes Verkehrsmittel (Taxi) nicht sinnvoller wär. Wenn man das erst an der Station erfährt, und dort kein Taxistand ist, dann ist man mitten in der Nacht ziemlich verloren. Edit: In der BVG-Karte sind diese Gebiete überigens farblich hinterlegt.

Achso. Aber dann kann man entsprechende Bereiche ja auch in den OSM-Karten hervorheben (boundaries). Die Fragen sind nur, wie man an die Info rankommt und wie man sei aus “Kundensicht” wieder aus OSM raus bekommt. Man könnte natürlich auch alle Straßen im Bereich zu einer Relation zusammenfassen, aber das hat einige Nachteile :wink: Besser wäre wohl ein Ansatz wie bei den Postleitzahlen, aber da hat sich meines Wissens auch noch nichts endgültiges ergeben, oder?

Danke für den Tipp - kannte ich noch nicht. Habe ich direkt in meiner Region so hinterlegt. Muß nur noch schauen wie es sich mit dem Nachtexpress verhält.

Viele Punkte in diesem Thread haben mich auch sehr interessiert und teilweise gestört. Ich habe daraufhin ein vereinheitlichtes tagging-Schema entworfen. Vereinheitlicht sowohl was die Gültigkeit für die unterschiedlichen Verkehrsträger anbetrifft, als auch in dem Sinne, dass alle Vertreter der bisher konkurrierenden Systeme innerhalb eines Verkehrsträgers (stop neben oder auf dem Weg, jede Haltestelle eintragen oder nur eine pro Kreuzung). Bitte seht Euch mal http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea an und arbeitet dort mit an dem Vorschlag…

Ach, das lustige Haltepunkt und Bahnhof Würfeln. Der Punkt ist suboptimal. Die Betriebsstellenbezeichnung oder Einstufung ist eine Festlegung des Eigentümers. Bei der Bahn wäre das die DB. Dein Schema würde im Endeffekt massig Bahnhöfe zu einfachen Haltepunkten machen. Bzw. darf ich raten was es ist. Kurz wir schreiben der DB die Betriebsstelle vor. Es gibt auch Bahnhöfe mit einen Bahnsteig und demzufolge nur einem entsprechendem Node. Selbst wenn da einmal am Tag eine Ferkeltaxe vorbei kommt, draußen steht noch immer Bahnhof auf dem Schild. Das bringt uns zum Einheitsbrei highway=platform. Für Tram und Bus mag das stimmen. Da ist das ganze meist Teil des Fußweges oder als solches ausgelegt. Ich kenne die Argumentation mit den quer verlaufenden Fußwegen und den privaten Abkürzungen… Bahnsteige waren aber schon immer Bahnsteige und sind in der Regel Privatgelände, teilweise auch zu bestimmten Zeiten geschlossen oder garnicht Frei zugänglich, vor allem aber dazu bestimmt, den Zugang zur Bahn zu ermöglichen. Wenn ich die Daten auswerte interessiert mich dann irgendeine subjektive Einschätzung nicht. Ich möchte wissen ob das nun ein Bhf oder ein Hp ist. Das muss klar ersichtlich sein und sich auch von anderen Verkehrsträgern abheben. Wenn ich mir z.B. Gleispläne oder Netzkarten der Bahn aus den Daten ziehen möchte, will ich natürlich weder die Bushaltestelle, noch die Straßenbahnhaltestelle in der Auswahl haben. Ich bin grudsätzlich für jegliche Vereinheitlichung. Aber ohne das man unterschiedliche Dinge in einen Topf wirft.

Und was spricht dagegen in die Haltepunkt-Relation eine Eigenschaft zu stellen, der Art Typ=Bahnhof oder Typ=Haltepunkt?

z.B. das hier: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Wieso solche Sachen unnötig in eine Relation auslagern, wenn die Eigenschaft doch direkt dem Objekt/Node zugehörig ist? zu den Vorschlägen des Threadstarters: 1.) - keine Verortungsvereinfachungen (Abstrahierungen) in die DB, das ist eine Aufgabe für z.B. den Renderer 2.) - keine Namensvereinfachungen (Abkürzungen) per “name”-Tag in die DB, das ist eine Aufgabe für z.B. den Renderer oder ein alternatives Tag Gruß, Sven

Es geht nicht um Kategorisierung, sondern wie du schon sagst, um die Eigenschaften des Objekts. Das gesamte Objekt ist ja die Relation stop_area. Es ist doch sinniger statt jedem Steig, Automaten und Schild zu schreiben es gehört zum Bahnhof/Haltepunkt, diese Information in die Relation zu schreiben, die alles zusammenfasst.

Eigentlich nichts. Aber das wird im Proposal mit keiner Silbe erwähnt und scheint auch so nicht vorgesehen zu sein. Stattdessen folgendes “Es wird daher insbesondere bei Bahnen nicht mehr zwischen Bahnhöfen mit railway=halt und railway=station unterschieden. Die Bedeutung eines Bahnhofes ergibt sich direkt aus der Anzahl seiner Haltepunkte und/oder Plattformen.” Was der selbe Qautsch wie einst mit der Definition über die Anzahl der Weichen o.ä. ist. Mit der Relation gehe ich ja gerne mit. Wobei für mich eine ganze Betriebsstelle in eine Relation gehört, jedenfalls solange wie es kein intelligenten Areas gibt, die alles im inneren automatisch zusammenfassen. Wenn wir schon ins Detail Bahnsteig gehen, kann man das Potential nutzen und das ganze richtig Kartographieren. Ansonsten würde eine Linie mit Punkt reichen. Nur an den Bahnhöfen willkürlich aufteilen und an den Bahnsteigen vorbeiführen, ist so ein inkonsequenter Zwitter aus Realität und Absraktion. Dort steht nur etwas von Service an Platform. Das würde im grunde auch die Verkehrsträger trennen. Nur warum nicht gleich durchweg railway=platform lassen und stattdessen in zukunft highway=platform + service=railway? Kann man sich sparen da am Bahnsteig ohnehin nur Züge halten. Es gibt die wenigen Sonderfälle wie Karlsruhe oder die Citybahn in Chemnitz, wo Trams auch das Schinenenetz nutzen. Wobei man schon wieder streiten kann. Dort wird unter Straßen- und Stadtbahn unterschieden, die Tram ist dem Fall nicht wirklich Tram. Vereinheitlichen muss ja nicht unbedingt ÖPNV komplett auf eines reduzieren bedeuten. Wichtig ist nur die einheitliche Umsetzung um die Nutzung und Auswertung zu erleichern, das geht auch ohne zwanghaftes vermischen.

Wenn ein Bahnhof z.B. mehrere Gleise, Bahnsteige, Wartehäuschen, Fahrkartenautomaten etc. hat, dann ist es sogar sehr sinnvoll, die Unterscheidung Bahnhof/Haltepunkt in der diesen Bahnhof zusammenfassenden Relation zu treffen, da es eine Eigenschaft der ganzen Anlage ist, und nicht eine Eigenschaft jedes Einzelelements. Es geht ja gerade nicht darum, dass man eine “Kategorienrelation” für “Bahnhöfe Deutschlands” oder “Haltestellen Deutschlands” macht, jeder bekommt seine eigene (z.B. eine Relation für den Ostbahnhof Beispielort mit allem “Zubehör” drin) und die eben geeignete beschreibende Tags.

Worauf genau beziehst du dich?

Diesem Punkt muss ich zustimmen, es sollte eine Möglichkeit gegeben werden, diese Information explizit anzugeben. Ich finde zwar nicht unbedingt, dass das Aufgabe des Proposals ist (es ist nicht wirklich so, dass “station” und “halt” bisher eindeutig im Sinne der deutschen Betriebsstellenbezeichnung verwendet worden wären, auch, weil es keine Möglichkeit gab, einfach nur “hier halten Züge” einzutragen), aber es ist ohnehin sinnvoll und würde dem Vorschlag einige Kritik ersparen.

Zum einen erfordert das Proposal service=railway fast nie, nur dann, wenn dort tatsächlich unklar wäre, welcher Verkehrsträger von der Plattform bedient wird – meist wäre also gar keine Ersparnis zu erzielen. Zum anderen muss man sonst noch waterway=platform und ähnliches einführen. Man kann natürlich unterschiedlicher Ansicht sein, aber ich finde, dass eine Plattform kein Waterway ist und auch eigentlich nicht zum Schienennetz gehört, sondern zum Wegenetz. Sozusagen das letzte Stück “highway”, bevor man auf das Netz des “railway”-Keys umsteigt. Ich halte aber trotzdem für ok, railway=platform als Plattform mit eingebauter services-Information zu sehen, nicht zuletzt deshalb, weil es den Tag schon gibt. Den services-Key bräuchte man denn nur in den wenigen unklaren Fällen überhaupt.

Lies nochmal durch. Da steht “Es ist in jedem Zusammenhang highway=platform zu verwenden, da es sich am ehesten um einen geteerten Weg handelt railway=platform sollte übergangsweise von Renderern etc. ebenso behandelt werden wie highway=platform’. Auf lange Sicht sollte aber auf highway=platform vereinheitlicht werden”. Mal von den zuletzt vor 20 Jahren geteerten und heute beim Bau unüblichen Bahnsteigen abgesehen… :smiley: ist das genau das Gegenteil. Ich verstehe hier das generell Bahnsteige, Bussteige etc. auf highway=platform umgestellt werden sollen. Da gehts dann nur mit einer Unterscheidung per Zusatz Service. So muss ich dann aus railway=platform zwei Werte machen highway=platform + service=railway. Ansonsten kann ich das nicht einfach aus der DB Filtern. Das geht nur mit Abgleich über zugehörige Relationen, die mir die Art der Haltestelle sagt, soweit überthaupt eine Relation vorhanden. highway=platform allein geht mir am relationslosen Haltepunkt durch die Lappen. Und der Bahnsteig gehört i.d.R. eben nicht zum öffentlichen Wegenetz. Er ist Teil die Infrastruktur und dort ist der Eigentümer oder Pächter zuständig. Bei der Hamburger Hochbahn darfst du z.B. auf deren Gelände nichtmal Fotografieren, weiß nicht ob das noch so ist. Eben weil es Privatgelände und kein öffentlicher Raum ist.

Der Bahnsteig gehört eigentlich schon zum Wegenetz. Nicht zum öffentlichen, aber ein highway=service ist ja auch ein highway, wenn er access=private hat. Man bewegt sich dort so fort, wie man es auf dem Wegenetz tut, und nicht so, wie man es auf dem Schienennetz tut. Ansonsten denke ich, dass ich es durchaus verstanden habe. Bahnsteige, Bussteige etc. sollen auf highway=platform umgestellt werden. Im Normalfall wird kein services rangeschrieben, da nach Ansicht des Proposal-Erstellers sich ein Bahnsteig von einem Bussteig nicht durch eine Eigenschaft des Objekts selbst unterscheidet, sondern dadurch, was davor hält. Und das kann man ja über die Relation bekommen.

Selbst wenn ich Arme und Beine einziehe und mich rollend darüber bewege. Das ist vollkommen unerheblich. Bahnsteig ist Bahnsteig und nicht Fußweg. Fußweg gibts nur bei Bus/Tram. Da bräuchten wir auch keine Unterscheidung zwischen Autobahnen etc., alles Straßen und der ref reicht ja. Oder taggen wir jetzt Gatebrücken auf Flughäfen auch als highway=platform? Wäre ja nur konsequent. Das ist ebenso der Haltepunkt des Flugzeuges und die letzte Meile zum Flugzeug. Verblüffende Gemeinsamkeit, ich laufe darauf zum Flugzeug. Unterscheidung, es hält ein Flugzeug und kein Bus davor. Da wäre mir fast etwas entgangen. Was mache ich, wenn ich mit dem Bus vom Gate zur Gangway gefahren werde und über die Gangway in das Flugzeug einsteige? Jetzt wird es aber knifflich. highway=platform Service=bus;airplane? :smiley:

Ok, nochmal. Ich habe einen Haltepunkt mit Bushaltestelle vor der Tür. Beides highway=platform. Ich möchte mir aus einem Gebiet aber das Gleisbild und die Infrastruktur der Bahn herausfiltern. Alles rundherum, inkl. Bushaltestelle soll raus. Muss ich mir mangels eindeutigen Filtermerkmals sämtliche gleichlautenden ÖPVN Objekte herunterladen und händisch löschen, dabei hoffen das auch der kleinste Haltepunkt vielleicht eine Relation mit eindeutigem Merkmal trägt oder wie unterscheide ich das ohne in zukunft dutzende Relationen gegenprüfen und aufwendig händisch filtern zu müssen, wenn ein eindeutiges Merkmal fehlt? Um zu wissen was davor hält, muss das Objekt dies auch aussagen. highway=platform sagt mir nur trocken das dort etwas hält, nicht was. Das kann ich mir nur visuell zusammenreimen, wenn das Objekt z.B. optisch an einem Gleis liegt und somit wohl einen Bahnsteig darstellt. Oder eben technisch, indem ich ggf. vorhandene verknüpfungen aufwendig gegenchecke.