Einheitliche Regeln für die Erstellung von Haltestellen

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.

Und noch ein Gedanke dazu: Ich stimme dem zu, daß der Name viel zu oft herhalten muß und mit unterschiedlichsten Informationen überfrachtet ist. Allerdings glaube ich nicht, daß die Lösung für das Problem Regeln für Namensformatierung und Namensbestandteile sind. Das hat keine Aussicht, sich durchzusetzen und löst das eigentliche Problem nicht. Vielmehr bin ich der Ansicht, daß in den Namen nur die offizielle Bezeichnung gehört. Ohne Klassifizierung, Zusätze oder Anmerkungen. Also Name ist einfach z.B. “Hanseplatz” ohne “Bahnhof”, ohne “U-Bahnhof”, ohne “U5” und ohne " - historischer Verladebahnhof". Für Einordnung, Klassifzierung und Anmerkungen gibt es andere Tags bzw. sollten weitere Tags definiert werden. Die technische Begründung ist die: Es ist einfach, eine hübsch aufbereitete Bezeichnung aus dem Namen und anderen Tags zusammenzusetzen. Z.B. aus name=“Hanseplatz”, railway=subway_entrance, subway=“U5”, description=“historischer Verladebahnhof” kann man sich je nach Bedarf jede lange oder kurze Fassung zusammenbauen. Dagegen ist es fast unmöglich, aus einem kreativ zusammengestellten Langnamen noch irgendwas Sinnvolles für eine Karte oder andere Anwendung herauszuziehen. Die einzigen technischen Alternativen sind: Nixtun und Karte zumüllen, willkürlich irgendwo abschneiden oder überlange Bezeichnungen ganz weglassen. Von daher auch mein Plädoyer: Nur offizielle, (kurzgefaßte) Namen in name.

Ein Bahnsteig ist ein Bahnsteig. Aber er ist eher ein Fußweg als ein Schienenweg und könnte perfekt als highway=railway_platform oder sonstwas beschrieben werden. Die Frage “gehört ein Bahnsteig zum highway- oder railway-Key?” hat nichts mit der Frage zu tun, ob du einen Bahnsteig von anderen Plattformen unterscheiden kannst, insofern treffen auch deine Vergleiche mit der Unterscheidung zwischen Straßentypen etc. nicht. Es geht rein akademisch um die Frage, ob es logisch ist, dass Bahnsteig als “railway” klassifiziert werden soll, wenn er nicht mehr benutzt wird zum railway=disused mutiert und von einem sonst ausschließlich auf highway arbeitenden Routing berücksichtigt wird - oder ob er nicht einfach doch ein highway mit Sonderfunktion ist.

Nun, wenn ich das richtig verstanden habe, erwartet das Proposal in diesem Fall in der Tat von dir, dass du selber filterst (sprich: für jeden highway=platform alle stop_area-Relationen, in denen er enthalten ist, auf Member mit Tag railway=halt durchsuchst). Offenbar wird davon ausgegangen, dass ein üblicher Nutzer die Bahn-/Bussteige ohnehin identisch rendert/sonstwie behandelt (und z.B. nur das Gesamtgebilde, die Halts o.ä. mit Icons, anderen Farben, Beschriftung o.ä. unterscheidet). Das ist nicht vom Prinzip her daneben, es gibt durchaus auch anderswo Informationen, die man nur aus dem Zusammenspiel von Objekten erhalten kann. Nur handelt es sich dabei üblicherweise um seltene Fälle. Die Frage ist halt, ob die Annahme, dass dein Bedürfnis ein solcher ist, gerechtfertigt ist. Vermutlich liegt die Lösung nahe, dies zu verneinen, und einfach einen eigenen Tag dafür zu nehmen.

1.) Kannst du vergessen, da manche Haltestellen ewig weit auseinander liegen und es dort auch keinen Punkt gibt wo beide sichtbar sind. Auch gibt es gelegentlich Haltestellen, die nur auf einer Seite vorhanden sind. 2.) Wenn man Haltestellennamen abkürzt, können diese nicht mehr gefunden werden. Oder hab ich etwa mal kurz die Abkürzung parat, wenn ich in einer hunderte km entfernten Stadt bin? Die Idee mit “short_name” finde ich aber nicht schlecht.

Ein Bahnsteig ist Teil der Infrastruktur Bahnhof. Hat rein ganrnichts mir Schiene ja nein zu tun. Ich zitiere hier die aus der Definition “Der Bahnsteig ist als Teil des Bahnhofsgeländes Privateigentum des Bahnhofsbetreibers.” Damit klar Railway oder was auch immer der zukünftige Oberbegriff für die Infrastruktur der Bahn sein wird. Muss ich da jetzt noch eine Doktorarbeit darüber einreichen? :roll_eyes: Aber ich mache mir den Spaß und wühle mal alle Fachbücher durch. Vielleicht findet sich unerwartet doch noch etwas gegenteiliges… Irgendwelches Bahnsteigrouting fällt ohnhin flach. Das mag bei einfachen Bahnsteigen klappen. Aber fagen wir jetzt beispielsweise bei Kopfbahnhöfen an, virtuelle Wege über den Querbahnsteig zu ziehen, um die Leute am besten noch bis zur Tür des Zuges zu routen? Meinst du nicht das dies ein wenig drüber ist? Routing zum Eingang des Bahnhofes ok. Alles andere Zeigt der Plan. Bahnsteig 2 liegt da und ist vor Ort ausgeschildert. Und bevor irgendein Depp in die Baugrube latscht, soll er die Schilder beachten.

Also kurz, eine Railway Map kannst du dir klemmen, weil in Zukunft wegen Bodennebel alles zusammengschmissen werden muss und davon abhängt, ob die Mapper den kleinen Unterschied erfassen oder nicht. Ohne Unterschied kein Filtern, alles muss per Hand geprüft werden. Während die Wanderer gerne auch eindeutig amenity=horse_shit einführen dürfen. Finde ich töfte für eine freie Weltkarte.

hi ! ich habe mir zwar nicht alles durchgelesen - aber in der mailingliste-de läuft nich eine ähnliche diskussion. siehe hierzu auch http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea In Lübeck sind schon einige Bushaltestellen entsprechend von itschytoo umgearbeitet. Gruß Jan :slight_smile:

Du gehst davon aus, das “railway” ein Oberbegriff für die Infrastruktur der Bahn ist und argumentierst mit Eigentumsrechten etc. Ich finde, dass “railway”, “waterway”, “highway” u.ä. Oberbegriffe für Fortbewegungsnetze mit bestimmten Charakeristika sind, die sich um den Eigentümer, Betreiber oder sonst was nicht scheren. Vergib mir, dass ich ein anderes mentales Modell habe als du. Aber verrate mir noch: Gehören nicht noch viele weitere Einrichtungsgegenstände in Bahnhöfen zur Infrastruktur der Bahn? Privateigentum des Bahnhofsbetreibers sind sie jedenfalls. Sollten wir die dann als railway=vending_machine, railway=bench, railway=Blumenkübel (hat da echt noch keiner ein Tag erfunden?) und so weiter kennzeichnen? Oder muss ich die für meine RailwayAndStationMap erst mühsam mit Relationen oder geografischer Nähe aus der Masse fischen?

Bahnhofsunterführungen, aber auch Bahnsteige in kleinstädtischen oder ländlichen Regionen werden oft selbstverständlich von der Bevölkerung als Teil des Fußwegenetzes genutzt – und sind in der Tat oft gut begehbare, geradlinige Verbindungen. Das ist die Art des Routings, die ich gerne hätte, und die kann auch ohne Probleme funktionieren. Den Zug find ich schon noch selber.

Hier möchte ich nur anmerken, dass ich das Proposal in diesem Punkt nicht verteidigt, sondern nur seine Denkweise nachvollzogen habe.

Find ich gut. Bei Bushaltestellen gibts auch deutlich weniger mögliche Kritikpunkte am Proposal. Liegt sicher auch daran, dass es noch weniger (teil)etablierte Verfahren gab, so dass keiner seine bus_route=platform in Gefahr sehen muss. :wink:

Na wie willst du das denn sonst abgrenzen? Ich habe bis dato keine einzige Definition gefunden, welche einen Bahnsteig aus dem Gelände der Bahn heraus dividiert. Bahnsteig=Footway ist eine Erfindung die ich einzig hier zum ersten mal gelesen habe. Ich beschäftige mich doch nicht erst seit vorgestern damit.

Das sagt doch keiner. Hier geht es um ein Grundelement, einen Bahnsteig, nicht um Kübel oder Automaten. Wie Gleispläne usw. aussehen weißt du, oder soll ich einen als Beispiel zeigen? Ich will doch keine Blumenkübel ect. rausfischen und einen Einrichtungsplan für die Dicke von RTL zum umräumen erstellen. Grundelemente die nunmal auf einem Bahngelände stehen und dazu gehören. Das sind Empfangsgebäude die auch gerne einen Hausbahnsteig haben, Stellwerke, Bahnsteige, Gleise Weichen, Signale usw. Damit ich daraus eine entsprechende Karte genereieren kann, muss das klar abgerenzt sein. Von mir aus alles in einer Relation oder wie auch immer. Rein als highway=platform kann ich nicht abgrenzen. Wenn schon anderer Key dann eindeutig mit Zusatz Bahn oder an die Bahnhofrelation gehängt. Ansonsten haut mir die API sämtliche highway=platform aus dem Gebiet vor die Füße, die müsste man bei jedem Update per Hand selektieren und jede Bus- und Tramhaltestelle aus den Daten tilgen. Das ist so als hätte man nur highway=road und die gewünschten Autobahnen für die Autobahnkarte muss man sich per Hand heraussuchen.

Unter-/Überführungen kannst du schonmal streichen. Die gehören zwar auch auf entpsrechende Pläne, aber da kann man einen Kompromiss machen. Die dienen in der Tat oft als Durchgang durch den Bahnkörper bzw. als Brücke über das Bahngelände, haben dann auch eine Zugangsmöglichkeit zu Bahnsteigen. Es gibt aber auch viele die einfach Sackgasse sind und nur dem Zugang zum Bahnsteig dienen. Da geht es im Tunnel und auf dem Bahnsteig nicht weiter, außer man ist lebensmüde und kürzt übers Gleis ab. Bahnsteige und Selbstverständlich. Hier kürzt man auch gerne wie selbstverständlich übers Gleis ab. Trotzdem verboten und ich würde diese Art der Abkürzung nie empfehlen. Ich kenne nun deine Lokalen Vorbilder nicht. Nur im Zweifelsfall wäre ich immer dagegen einen Gruppe Wanderer zur Rush Hour über einen vollen Regionalbahnsteig zu lotsen. Das gibt schnell Szenen wie zur Loveparade. :smiley: Auch wenn das für manche Selbstverständlich ist. Solange da nicht offiziell ein Fußweg durchgeht, ist es ein Bahnsteig, der Reisenden den Übergang zum Verkehrsmittel oder vom Verkehrsmittel zum Ort gewähren soll. Durchgehende Unter- /Überführungen sind meist auch offizielle Fußwege. In meiner alten Heimat gibt z.B. auch beides nebeneinander. Ein reiner Fußgängertunnel und eine Sackgasse die nur zu den Aufgängen der Bahnsteige führt.

Soweit klar, nur wenn noch weitere solche Ideen kommen dann ist eine richtige Railmap auf OSM Basis schlicht unmöglich. Für klare Daten braucht es Filtermöglichkeiten. Mit railway=platform konnte ich da bisher gut leben. Das war eindeutig und kaum Fehleranfällig. Die Information war über den Tag beim Mappen standardmäßig da. In Zukunft muss ich darauf hoffen, dass der Mapper von sich aus service=rail dranschreibt oder das über die Relation kenntlich macht. Vergisst er das oder verzichtet auf die Relation, muss ich jedes highway=platform aus der API ziehen und Bus- und Tramhaltestellen per Hand löschen. Eine automatisch aktuallisierende Karte kann man so natürlich vergessen, die Daten müssen immer kontrolliert werden. Über den Aufwand reden wir besser garnicht. Ich habe damals nicht umsonst einen Thread zum Thema aufgemacht. Man sollte sich da noch im Vorfeld eines Proposals mal ausgetauscht haben, vor allem bei so einer komplexen Kiste. Scheint wohl nicht zu klappen. Es kam einzig der Hinweis auf Internationalität zu achten. Habe ich berücksichtigt und bin am prüfen. Nur vergeht mir da ehrlich gesagt die Lust, wenn in der Zwischenzeit die Grundlage dafür verunstaltet wird.