Vorschlag zur Nutzung von access:permit für Bahnsteige und Wege in Haltestellen

Ich sehe router-seitig zwischen deinen Punkten keinen Unterschied. access=permit passt nicht so wirklich auf die Situation. Ich denke, das was access=permit beschreibt gibt es in Deutschland nicht. Permit ist am ehesten mit Genehmigung zu übersetzen und gedacht für Situationen, wo du bspw. eine Genehmigung brauchst, um auf einen Gipfel/in einer Gegend zu wandern. In den amerikanischen State/National Parks ist das üblich.

access=customers ist an sich genau für den Zweck gedacht. An sich darf da jeder hin, er muss nur in einer wirtschaftlichen Beziehung stehen.

Im angesprochenen Fall hat die Situation eher einen wirtschaftlichen Charakter als den Charakter einer Genehmigung.

Allgemein zur Problemstellung, macht es aber keinen Unterschied. Der Router muss irgendwie wissen, dass du den Weg nutzen darfst. Das muss man ihm sagen, sprich vom Nutzer erfragen.

6 Likes

Ein Fahrschein ist aber keine Genehmigung sondern ein Nachweis, dass du in einer wirtschaftlichen Beziehung mit dem Betreiber stehst. Du kannst nie vor dem Fahrkartenautomaten stehen und der sagt dir, heute haben ich schon 1000 Tickets verkauft, versuch es morgen nochmal. Die Situation ist: Jeder der zahlt, darf auf den Bahnsteig, und wenn sich die Leute da stapeln, dann stapeln sie sich halt. Das ist bei einem permit anders.

5 Likes

customer passt aber auch nicht.

Hab’ mal getestet: OSRM und Valhalla machen das in der Tat so.

Straße Sundern ist customers bis kurz hinter dem Hof (von Süd kommend).

1 Like

Du wiederholst Dich.

Mit Deiner oben geschilderten Interpretation von customers und permit stellst Du das bisherige Verständnis der Begriffe auf den Kopf. Bei >90.000 Verwendungen von permit und > 1,35 Mio. customers wirst Du Dir damit keine Freunde in OSM machen.

Nicht “nur weil man es immer schon so macht” sondern weil es ein Community-Konsens ist.

Ich mach das ungern, weil OSM in vielen Dingen eigene Definitionen hat, die nicht exakt mit der Realität übereinstimmen. Dies rein aus de Notwendigkeit heraus, dass in gewisser Weise abstrahiert werden muss und international gesehen ein und das selbe Objekt in einzelnen Regionen/Ländern unterschiedlich definiert ist oder begrifflich verschieden genutzt wird.
Wie gesagt “ungern”, aber wirtschaftlich im engeren Sinne ist ein Kunde erst dann Kinde, wenn bereits eine Geschäftsbeziehung eingegangen wurde; Voraussetzung ist also der Vertragsabschluss. Erst in der erweiterten Definition werden potenzielle Kunden, also diejenigen, die die Absicht haben, eine Geschäftsbeziehung einzugehen, zusätzlich einbezogen. Dies entspricht dann auch im Wesentlichen der OSM-Definition. Darunter fällt alles, was im weitesten Sinne Anbahnung und Eingehung von Geschäftsbeziehungen zwischen Unternehmen untereinander und zwischen Unternehmen und Verbrauchern umfasst, also Ware oder Dienstleistung gegen Geld, auch das Bahnsteigticket für 10 Cent.
Du versuchst jedoch, customers auf die Anbahnung der Geschäftsbeziehung einzuschränken und das erworbene Ticket (eigentlich Kunde im engeren Sinne) als Erlaubnis/Berechtigung umzudeuten. Das finde ich nicht gut.

Ja, permit beschreibt die Erlaubnis/Zugangsberechtigung. Und zwar typischerweise nicht zwingend gegen Entgelt für eine Leistung (was Bearbeitungsgebühren nicht ausschließen würde). Es fällt mir schwer Beispiele dafür zu finden. @aighes hat bereits die Zugangsberechtigung zu Nationalparks in den USA genannt. Auch die Zugangsberechtigung für Bahnmitarbeiter, die kein Ticket kaufen müssen, würde eher unter permit fallen - sowas mappen wir aber nicht, die access-Werte sollen nur für die Allgemeinheit definiert werden, und dieses permit ist eben nicht allgemein erhältlich.

Ein typisches Beispiel für permit habe ich - das ist im Prinzip auch im engl. Wiki ganz zum Schluss erläutert.
Hier in meiner Gegend gibt es öffentliche Grillplätze, mit überdachtem Grill, Schutzhütte und gemauerter Feuerstelle. Diese Grillplätze muss man bei der Gemeinde buchen. Die Erlaubnis, den Grillplatz nutzen zu dürfen, kann prinzipiell jeder bekommen, das kostet auch keine Miete. Eine Erlaubnis erhält man nur dann nicht, wenn der Platz zur gewünschten Zeit bereits anderweitig belegt/gebucht ist. Es geht hierbei also nicht um eine Geschäftsbeziehung (Nutzung gegen Entgelte) sondern nur um eine zeitliche Steuerung. Dies wäre für mich ein typischer Fall für permit.
(und nein, das ist so in den Daten noch nicht gemappt, könnte ich aber bei Gelegenheit mal machen)

3 Likes

Ich habe in London und Paris (zwei Stätte, wo man sich den Zugriff auf die Bahnsteige ihrer U-Bahnen erkaufen muss) mal nachgeschaut und i.d.R. werden die Bahnsteige nicht mit access=* markiert. Allerdings habe ich bei République in Paris einige Pfade gefunden, die durch die Bahnsteige gehen und mit access=customer markiert ist. Dies ist allerdings auch die Ausnahme als die Regel und andere U-Bahnhöfe beider Städte (welche ich überprüft habe) wurde dies nicht so gemacht.

Nichtdestotrotz ist die Angabe access=customer für mich natürlich, da man sich hierzu eben ein Ticket erkaufen muss d.h. einen Wille die U-Bahn zu verwenden zu haben, um auf die Bahnsteige zuzugreifen zu können (so vergleichbar mit Parkplatz vor Geschäft oder die Toiletten einiger Restaurants).access=permit ist zwar auch korrekt in der Situation aber nur, weil access=customer eher ein Sonderfall davon ist (d.h. bist du Kunde, hast du Erlaubnis, den Bahnsteig / den Parkplatz / die Toiletten zu nutzen).
Natürlich gibt es auch noch das Bahnsteigticket was speziell eine “Ich will nicht die U-Bahn nehmen”-Ticket ist, allerdings, um zur Toiletten-Analogie zurückzukommen, erlauben einige Restaurants die Nutzung ihrer Toiletten auch für die, die dort nichts essen wollen, wenn auch über eine Gebühr.

Edit: Diverse Grammatik- / Rechtschreibfehler behoben und fehlende Details hinzugefügt.

ich bin seit 2008 Mitglied der OSM-Comunity. Veränderungen in den Tagging-Schemas waren früher sicher einfacher. Aber das will ich auch gar nicht. Die Interpretation lag doch schon immer beim Einzelnen (oder habe ich etwas verpasst). Deshalb ist die Definition evtl zu schwammig und muss konkretisiert werde, damit es keine Missverständnisse gibt.

Das umtaggen würde die Hochbahn übernehmen (wurde oben gesagt).

In den meisten Fällen stimmt ja die Benutzung.
ich finde in Norddeutschland (mehr will OPA gerade nichta usspucken) gerade mal 1.575 Vorkommen von ["access"="customers"]["fee" = "yes"] (POI: 304, Linien: 510, Polygone: 761) overpass turbo


Können wir uns darauf einigen, dass OSM ["access"="customers"] als “Zugang nur für Kunden (incl. potentielle Kunden)” definiert?
["access"="customers"] wäre ähnlich wie access=destination nur dass eine bestimmte destination gemeint ist.

Die Schärfung der Abgrenzung von customers und permit betrifft ja nicht nur die Hamburger Hochbahn. Das gleiche gilt für andere Verkehrsbetriebe (z.B. München?) und diverse Attraktionen bei denen man Eintritt bezahlen muss um auf ein Gelände zu kommen.
Da Access nichts typisch Deutsches ist müsste das Thema müsste auch international diskutiert werden.

Auch wenn ich mich wiederhole: Ich sehe immer noch nicht, wie es das eigentliche Problem löst, dass der Router nicht weiß welche “Verbotszonen” du betreten darfst und welche nicht.
Insbesondere für das ÖPNV-Routing wäre es doch eigentlich die einzige Lösung die für ÖPNV-Kunden nutzbaren Bereiche insgesamt als “Bahnhof” zu markieren.

Wenn es nur darum geht das Routing in einem bestimmten Router zu reparieren, dann ist es Mapping für eine spezielle Software - und das wollen wir nicht.

Volle Zustimmung. da müsste der Router angepasst werden.

ich hab mal eine Diskussion angelegt: https://wiki.openstreetmap.org/wiki/Talk:Key:access#permit_vs_customers

Vielleicht liegt das einfach auch nur daran, dass OTP permit einfach gar nicht auswertet/berücksichtigt.

Ein Routenplaner muss für das Routen im ÖPNV sowieso nach ganz anderen Regeln routen als beim normalen Routing über Straße und Wege. Soweit das access=customers die Bahnsteige betrifft ist das einfach lösbar. Sobald als eines der Verkehrsmittel ÖPNV angesprochen wird, muss der Router das customers an Bahnsteigen einfach ignorieren. Bei anderen Wegen innerhalb des Bahnhofes ist das vielleicht etwas komplizierter, zumindest wenn man sicherstellen möchte, dass außerhalb des Bahnhofsbereiches customers beachtet werden soll.
Sollte es ausschließlich um eine Routinganwendung für den hvv gehen, könnte man dies über den operator ermitteln.

Meine Erfahrung: im Wiki bekommst du nicht viel Reaktion - da liest kaum jemand mit. Besser hier eine Diskussion im int. Teil aufmachen - im Wiki dann ein Link auf die Diskussion. Ich würde empfehlen die Abgrenzung von permit zu customer ganz allgemein zu klären und nicht am speziellen Beispiel Bahnsteige in Hamburg.

Bisher habe ich auch permit als “Genehmigung” verstanden. Aber erwirbt man nicht durch sein Ticket genau solch eine Genehmigung? Genauso könnte ich aber argumentieren, dass ich beim Supermarkt durch meinen Einkauf die Genehmigung erhalte, dann wäre das auch permit? Ist customer ggf. eine Kombination von destination und permit?

Was ist denn zum Beispiel mit einem gebührenpflichtigen Parkplatz oder einer Mautstraße? Die kann auch jeder nutzen wenn er bezahlt. Ist es jetzt :

  • access=yes/permissive (alle können sofern sie zahlen)
  • customers (Kunde des Betreibers)
  • permit (Erlaubnis vom Betreiber erworben)?

Auswertbar wird es am Ende nur durch fee oder toll etc.

Das ist dann sehr viel komplizierter und man möchte sicherlich nicht in jedem Router Sonderregeln für diverse operator führen.

Deshalb meine Einschränkung, wenn es um eine hauseigene Routinganwendung nur für den hvv ginge. Darauf könnte der vorletzte Absatz hindeuten.

Wir wollen den OTP nutzen und wie Leonard ausgeführt hat, könnten wir dort einen Hamburg Mapper anlegen, der dann die entsprechende Methode überschreibt, welche pro Way ermittelt, ob Durchgangsverkehr verboten ist. Da könnten wir technisch gesehen ohne jegliche Änderungen an OSM gänzlich access=customer ignorieren (dann auch außerhalb von Bahnhofsgebieten). Alterntiv könnten wir zB eine Kombination von access=customer und customer=HVV ignorieren, was dann ein Tagging in OSM voraussetzen würde.

Das ist beides technisch einfach zu machen und ohne potentielle Gefährdung anderer OTP-Instanzen in der Welt.

Falls das Routingverhalten selber aber geändert werden sollte, dann würde das deutlich mehr Instanzen berühren und die potentielle Fehlermenge wäre beachtlich größer. Aktuell werden schon beim Aufbauen des Graphen sämtliche Ways entfernt, die nach der Definition des verwendeten Mappers Durchgangsverkehr verbieten. Diese sind dann schlicht nicht mehr beim späteren Routing vorhanden.

Das hält den Router einfacher, da dieser keine Einzelfallunterscheidung mehr machen muss, sondern jede verfügbare Kante einfach nutzen kann (soweit ich es verstehe). Dadurch entstehen aber auch Inseln, die nicht mehr mit dem Graphen verbunden sind. Von denen kann dann kein Routing zu Gegenden außerhalb der Insel erfolgen.

Die zwei haben nichts miteinander zu tun. access=destination bedeutet, ich darf das Objekt nutzen, wenn mein Weg in dem Gebiet endet. Das ist weder bei access=permit noch bei access=customers eine Voraussetzung. Die beiden kommen eher aus access=permissive/private , sind nur etwas restriktiver. Bspw. könnte der

Das ist halt eher ein praktische Frage. Es macht den Parkplatz vor dem Supermarkt nicht gerade funktional, wenn du erst mit deinem Auto dort parkst, nachdem du an der Kasse bezahlt hast. Dito wird der Kellner die die Toilette nicht verweigern, nur weil du noch nicht das Essen bezahlt hast. Es liegt an der Natur der Örtlichkeit, dass man erst am Ende zahlt. Auch reicht die Absicht rechtlich nicht. Es reicht bspw. nicht aus, dass du einmal alibimäßig durch den Supermarkt gehst. Aber auch hier wirst du vermutlich keine Probleme bekommen.

Evtl. sind die beiden Begriffe ein wenig ambivalent und es ist mehr der Sprache geschuldet, dass es beide Tags gibt.
Der Router wird sie am Ende ähnlich behandeln und der einfachste/sicherste Weg ist da vermutlich, es dem access=destination gleichzusetzen. Aber das ist die Interpretation des Routers aus dem Analogieschluss, wer zum Supermarkt routet, wird da wohl auch einkaufen wollen. Er wird dich aber nicht durch den Zoo routen, weil es eher selten ist, dass jemand bereit ist, den Eintritt zu zahlen, nur um Abzukürzen. Du könntest aber auch den Router mit Eintrittspreisen füttern und sagen, die Minute Lebenszeit ist mir 1EUR wert. Wenn der Eintritt dann 20EUR beträgt, der Router annimmt du wartest 5min an der Kasse und der Weg ist 30min schneller, würde er dich durch den Zoo routen.

Kann ich das Ergebnis so zusammenfassen?

  • wir belassen access=customers
  • der Eintrag wird durch ein customers=HVV ergänzt

access=customers (mit s am Ende).

Das Tag customers=* wird bisher quasi nicht genutzt - etwa 400 Nutzungen weltweit - und ist dementsprechend undokumentiert.

Daher hatte ich operator=* vorgeschlagen. Kombiniert mit access=customers wird der Tag über 85000 mal genutzt.

halte ich für unglücklich, da die Wege nicht durch den HVV betrieben werden. Daher ist customers=* passend

3 Likes

Update zur Thematik:
Der HVV schafft zum 01.01.2024 die Bahnsteigkarte ab (Quelle).

Ich habe soeben diese Diskussion entdeckt. Wir hatten eine ähnliche Diskussion in Österreich, aus der eine Wiki-Seite entstanden ist. Wir haben für Parkplätze, welche exklusiv für ÖV-Fahrgäste nutzbar sind, den Tag access=customers und customers=public_transport gewählt.

Kommentar: In Österreich sind die Bahnhöfe meist von der ÖBB Infrastruktur AG betrieben, die Tickets kauft man aber von den Verkehrsverbünden oder der ÖBB Personenverkehr AG oder anderen Privatbahnen. Das wäre schwer mit konkreten Werten zu bezeichnen.

3 Likes