access=customers wird seit jeher diesbezüglich kontextabhängig verstanden. Auf einem Parkplatz darf ein Kunde, der lediglich die Absicht hat, einen Vertrag zu schließen, parken. In sehr vielen anderen Anwendungsfällen schränkt access=customers allerdings auf zahlende Kunden ein (barrier=gate, Wege hinter solchen Toren, Spielplätze/Toiletten, die zu Restaurants gehören, …)
Ggf. sollte man diese unterschiedlichen Fälle mit einem Subtag abdecken, aber an access=customers würde ich hier nicht rütteln.
Das Grundproblem verstehe ich ja schon. customers wird von Routern faktisch wie destination verstanden. Liegen Start oder Ziel im customers-Bereich, ist meist alles gut. Liegen Start und Ziel aber beide außerhalb, wird nicht durch geroutet. Dieses Routingproblem. haben auch viele Fährverbindungen, dort hat man jedoch eine Lösung.
Das halte ich für den besseren Ansatz. Vielleicht ja authentication:public_transport_ticket=yes statt oder zusätzlich zu toll=yes, oder auch fee=yes (analog zu parking:<side>:authentication:disc=yes), aber im Grunde wäre es ja auch so schon verständlich.
Das heißt die Einschränkung ist noch stärker als customers.
ja
Inwiefern löst den permit das Problem im Generellen? Auch hier weiß der Router nicht, ob du eine eine Berechtigung vom Eigentümer hast und dürfte dich daher eigentlich dort nicht langrouten.
lass uns das Problem vom Router lösen. Und uns darauf konzentrieren, was der Unterschied zwischen den beiden Tags bedeutet.
barrier=gate, Wege hinter solchen Toren,
ich würde behaupten, dass hier das tagging falsch ist, da man nicht nur Customer sein muss, man muss auch eine spezielle Erlaubnis (Ticket) erworben haben. Stell dir vor, du bist (langjähriger) Kunde eines Kaufhauses, trotzdem darfst du noch lange nicht einfach so im Parkhaus parken. Du brauchst eine spezielle Erlaubnis.
Spielplätze/Toiletten, die zu Restaurants gehören
auch hier akzeptieren die meisten restaurants, dass man sich an einen Tisch gesetzt hat und die Karte studiert. es muss noch kein Vertrag zustande gekommen sein, um die Spielplätze/Toiletten benutzen zu dürfen.
Wir sollten uns an das Wiki halten. (dass der Tag teilweise anders/falsch benutzt wird, sollte unerheblich sein)
access=customers würde ich hier nicht rütteln.
Warum nicht, wenn es falsch benutzt wird?
Ansonsten müssen wir das Wiki anpassen.
Sorry, wenn ich so darauf rum reite, aber einen gut gemeinten Vorschlag und ein konkreteres/genaueres Tagging abzulehnen, nur weil man es immer schon so macht, finde ich falsch. Ich hab in letzter Zeit nicht mehr so viel an OSM getagt, aber meine, dass OSM immer für eine möglichst genaue Abbildung der Realität stand.
Es geht mir lediglich darum, dass access=customers in beiden Fällen verwendet wird und ich den Unterschied für subtil genug halte, dies nicht als falsch zu bewerten. Es braucht keine Änderung des Wikis.
access=permit fühlt sich an dieser Stelle nicht richtig an, da es tendenziell access=private/no gegenüber gestellt wird. Die deutsche Wiki-Seite sagt wenig aus, aber die englische liefert ein besseres Bild von der eigentlichen Bedeutung: Tag:access=permit - OpenStreetMap Wiki Das passt schlicht nicht auf das Eingangstor eines Zoos, bei man nebenan am Schalter seine Karte kauft. (z.B. Permit situations may be complex. A mapper on the ground encountering a “permit required” sign might consider initially tagging it as access=private, only later changing it to access=permit after researching the permit situation.)
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.
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.
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)
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.
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.
