Den Frust kann ich verstehen - ich würde aber in einem solchen Fall immer den direkten Kontakt mit demjenigen User suchen, der die Daten geändert hat. Der OSM-Mapper von ITO ist da Gold wert. Vielleicht hat der Kollege / die Kollegin ja noch ein besseres Schema, und bei manchen meiner eigenen Eingaben bin ich froh, wenn sie später von Dritten korrigiert werden. So ein neuer Regelsatz kann da leicht noch mehr Frust erzeugen.
Sehe ich kritisch. Zwar ist das Problem nicht zu bestreiten, aber ich würde es lieber durch einen eigenen tag, zB short_name oder durch Modifikationen der Renderer lösen.
Auch das würde ich nicht machen. Die Angabe, welches Verkehrsmittel eine Haltestelle bedient, ist redundant, wenn sie im Namen und im dafür vorgesehenen tag auftaucht. Der name-tag sollte IMHO keinesfalls für andere Zwecke als zur Erfassung des “richtigen” Namens genutzt werden. Insbesondere finde ich es nicht sinnvoll, die Namenssetzung zu reglementieren, um Render-Problemen zu begegnen. Eines der Probleme bei OSM ist es wohl, sich vom gewohnten Bild des “idealen” Papier-Stadtplans zu lösen. Der Gewinn von OSM ist doch, dass die Daten verfügbar sind, um sie selber auszuwerten oder eigene Darstellungen zu basteln. Grüße florian
Ich muss zottel und flschm da voll zustimmen! zu 1: Wie bereits erwähnt liegen die Haltestellen oft weit auseinander. Ein Renderer kann theoretisch diese Punkte zur Darstellung zusammenfassen, und mittig anzeigen. In der Datenbank sollte aber die genaue Position eingetragen sein. Ich persönlich weiß ganz gerne vorher, ob ich vorne oder hinten in die Bahn einsteigen sollte, um beim umsteigen möglichst kurze Wege zu haben. Und oft muss man vor Ort nach der entsprechenden Haltestelle suchen, wenn viele Verkehrswege aufeinandertreffen. Bei der Suche nach der für meinen Weg richtigen Haltestelle hab ich schon so manchen Bus verpasst… zu 2: Ich bin, wie auch meine Vorschreiber, der Meinung, dass in das Name-Tag immer der volle offizielle Name gehört. Abkürzungen können die Renderer automatisch generieren. Außerdem wäre auch ein short_name-Tag denkbar. zu 3: Bezieht sich ja im Prinzip auf Punkt 2… Meine Meinung: Nur den vollen offiziellen Namen in das name-Tag eintragen. Oft gehört ein S oder U bereits zum Namen der Station. Ansonsten wird vielerorts bereits daran gearbeitet diese Netze zu Relationen zusammenzufassen, was dann auch das Netzsystem deutlich macht. Wie das ganze dann dargestellt wird ist Sache des Renderers. Mit “A+S Eidelstedt” könnte ich überigens garnix anfangen… Ist A+S nicht ne Firma? Was soll A denn heißen? Das Umstellen und Abkürzen von Namen halte ich besonders für Navigationssoftware für sehr kritisch. Wenn ich nach korrektem Namen suche (z.B.: Wilhelm-Leuschner-Platz), und in der Datenbank steht nur ein abgekürzter Name, dann wird es schwer zum passenden Ergebnis zu kommen. Außerdem gibt es da noch viele andere Anwendungsmöglichkeiten. Es kann auch Karten geben, wo Haltestellen anklickbar dargestellt werden, und in einem Popup tauchen dann weitere Infos zur Station auf. Und dort würden mich Abkürzungen sehr stören. Zu saharadesertfox: Wie jetzt? Bhf. oder Bf.? Seb1982 kürzt im Beispiel mit Bf. ab.
Die Wiki gibt doch da schon relativ eindeutig vor wie es gemacht wird. Wir sollten uns auch daran halten! Also neben der Straße auf der jeweiligen Seite entsprechen der Richtung. So steht es in der Wiki, so wird es am häufigsten gemacht. Also solltest auch Du es so machen, finde ich.
Ich denke man sollte die offiziellen Namen benutzen, so wie sie auch an den Schildern der Haltepunkte stehen. Allerdings halte ich eine Diskussion darüber, ob man nun Bahnhof/Hbf oder sonstiges, dazuschreibt, oder weg lässt für sinnvoll. Wenn die Station aber beispielsweise offiziell “Osnabrück Hauptbahnhof” heißt sollte sie auch so genannt sein in der Karte. Undzwar ausgeschrieben.
Was man mal überdenken könnte, wäre Haltestellen, die räumlich auseinanderliegen aber im Streckennetz als eine Haltestelle gelten, in einer Relation zusammenzufassen. Damit ließe sich beliebigen Renderern auch über einen oder mehrere label-Nodes als Mitglieder der Relation mitteilen, wo der Name der Haltestelle erscheinen soll. Da kann dann der Mapper entscheiden, wo der Name am sinnvollsten positioniert ist. So etwas sehe ich nicht als taggen für Renderer, sondern als Anweisungen für Renderer.
Hallo Florian, Deine Gedanken zu “Haltestellen” teile ich. Deine Meta-Gedanken hingegen nicht:
Der Gewinn von OSM ist dass die Daten frei sind und eine freie Weltkarte entsteht. Dass die aktuelle Darstellung alles andere als “hübsch” und befriedigend ist, ist ein ernstzunehmendes Handicap. Und nein, die Daten werden von den wenigsten selbst ausgewertet oder dargestellt - die meisten sind auf die Ergebnisse von “Mapnik und Co” angewiesen. Und da hinken wir im Vergleich mit den “Kommerziellen” noch weit hinterher… (und mit denen werden wir gemessen) Gruss, Markus
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.
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 - 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 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 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
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 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.
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
Und oft muss man vor Ort nach der entsprechenden Haltestelle suchen, wenn viele Verkehrswege aufeinandertreffen. Bei der Suche nach der für meinen Weg richtigen Haltestelle hab ich schon so manchen Bus verpasst… zu 2: Ich bin, wie auch meine Vorschreiber, der Meinung, dass in das Name-Tag immer der volle offizielle Name gehört. Abkürzungen können die Renderer automatisch generieren. Außerdem wäre auch ein short_name-Tag denkbar. zu 3: Bezieht sich ja im Prinzip auf Punkt 2… Meine Meinung: Nur den vollen offiziellen Namen in das name-Tag eintragen. Oft gehört ein S oder U bereits zum Namen der Station. Ansonsten wird vielerorts bereits daran gearbeitet diese Netze zu Relationen zusammenzufassen, was dann auch das Netzsystem deutlich macht. Wie das ganze dann dargestellt wird ist Sache des Renderers. Mit “A+S Eidelstedt” könnte ich überigens garnix anfangen… Ist A+S nicht ne Firma? 