wäre der verkehrte Tag. <fee=yes> + payment:prepaid_ticket=yes bzw. payment:token=yes erscheint mir bei Bezahlungspflicht richtiger. Was soll “automatic_open” bedeuten?
Mit “automatic_open” meint Rolf bestimmt, dass die Schranke nicht von Personal bedient wird, wie z.B. bei Parkhäusern.
<fee=yes> & payment:token=yes gefällt mir, reicht eventuell payment:ticket=yes ohne “prepaid”? Gibt es dazu schon Beispiele?
Edit: Eventuell stören sich Kollegen an der Verwendung von “payment”, da die Bezahlung vorab an anderer Stelle erfolgt.
Hallo,
eigentlich wollte ich das Thema nicht mehr weiter anpacken, aber ihr lasst ja nicht locker.
Grundsätzlich finde ich das Parkplatztagging noch sehr “erweterungsfähig”. Bisher attributieren wir einen Parkplatz mit access, fee und capacity…
Auch werden u.U. die Zufahrten und Ausfahrten mit einem barrier tag gemappt. Alles gut und schön. (Vom oben gewünschten Parkmünzenbezahlung muss ich hier etwas abweichen).
Nun, viele Parkplätze, die eigentlich privat sind (customers, Hotel, Restaurant), aber auch normale Parkhäuser oder -Flächen, haben (meißt urban) doch eine gesicherte Zu- und Ausfahrt (meißt mit barrier=lift_gate).
Aber nur dort muss etwas passieren. Also:
- man zieht sich eine Parkkarte an der Einfahrt, entwertet diese am Automaten und man damit an der Schranke wieder “rausfährt”
- die Einfahrtschranke öffnet nur mit entsprechender Karte oder Schlüssel (z.B. Hotel) oder automatisch (Lichtschranke, Druckschalter), um dort die Ausfahrt zu behindern
- die Einfahrtsschranke ist tagsüber offen, nachts geschlossen
- die Einfahrt ist überwacht, man zahlt beim Wächter
- die Ausfahrtsschranke lässt sich nur mit entsprechend entwerteter Karte (aller Art), Münze oder Schlüssel öffnen (ggf gar z.B. 30 Min freies Parken ohne Entwertung)
- die Ausfahrtschranke öffnet automatisch zu bestimmten Zeiten (z.B. weil man an der Einfahrt schon bezahlt hat)
- die Ausfahrt ist überwacht mit Parkwächter.
Allgemeine Frage: Sollen wir uns in der OSM mit solchen Details beschäftigen?
Imho finde ich ja, unbedingt. Solche Fragen sind wichtig, wenn man eine Reise oder einen Ausflug plant. Und es ist definitiv eine Geo-Angelegenheit, obwohl auch z.t. indoor Mapping. Eigene Erfahrung bei der Ausflugsplanung lassen mich dies nun doch zur Diskussion bringen.
Ihr seht, warum ich mich etwas zurückhalte. Warum einfach, wenn es auch kompliziert geht!
Meine Anregung ist halt, nicht nur die Parkplatzfläche zu attributieren, sondern auch die Barrieren.
Moin,
Zurückhaltung ist manchmal durchaus angemessen - ich halte mich auch sehr zurück, solche Details überhaupt zu erfassen … 
Insofern solltest Du aber Deine Zurückhaltung etwas aufweichen und vielleicht ein paar Anwendungsfälle erläutern, wo solche Details in Deiner Planung zum Tragen kommen.
Ich kann mir da derzeit wirklich nichts vorstellen - abgesehen von der erfassungswürdigen freien Parkfrist.
Grüße, Georg
Nun, aber bitte nicht mosern, Georg wollte ein Beispiel.
Folgendes Versuchstagging:
Ich habe diesen Parkplatz mal mit maxstay:for_free=0.5h getaggt.
Und die barrier=lift_gate (Ein- und Ausfahrt) mit access:for=park_ticket. (Da gerade erst gemappt, noch nicht unbedingt auf Mapnik).
Diese Eigenschaften kenne ich genau, da der Hotelparkplatz auch für andere Firmen im Haus und Kundschaft genutzt wird.
Jetzt weiß ich: Aha! Ich darf 30 Minuten frei parken. Muss mir aber an der Einfahrt ein Ticket ziehen und an der Ausfahrt wieder einwerfen!
Wenn das kein Mehrwert ist, dann weiss ich auch nicht weiter.
Möglich, das Hotelkunden ein Dauerticket bekommen. Weiß ich aber nicht. Die Ticketautomaten haben auch eine Gegensprechanlage. Sowas wird überhaupt noch nicht gemappt.
Mir ging es vorrangig erstmal gar nicht um Parkplatzmapping, sondern um ein Tag für Tokens als Bezahlform, denn dafür gibt es verschiedene Anwendungskontexte: Parkplätze, E-Tankstellen, ÖPNV (hier auch vending=token für Automaten)…
Wenn es in Zukunft verstärkt um Indoor-Mapping und/oder Detailmapping von Bahnhöfen/Flughäfen/… geht, werden Parkplätze und Parkhäuser bestimmt auch detaillierter gemappt werden. Besonders dann ergibt sich der Mehrwert des Detailmappings bzw. macht es Sinn, solche Informationen mit auszuwerten.
Ja, sicher. Wäre gut “token” und “token_coin” - Automaten zu erfassen. Leider bisher nur getaggt im Freizeit- und Fun Bereich des “Brighton Piers”. Und da ist wirklich die Frage, was die unter “tokens” verstehen? (Mitnahmeandenken?, Erinnerungsmünze, wo man ein Geldstück einwirft (zusätzlich noch zahlt), etwas rumgurgelt und dann aus deiner Münze ein Andenken gepresst wird?) Englische Kurzbegriffe sind mM nicht immer kompatibel mit unserer deutschen Sprache, deswegen wird imho hierzulande sich der Begriff token auch nicht durchsetzen. Aber man kann es ja mal versuchen damit.
So eine Gedenkmünze heißt auch “elongated coin”, unter vending=elongated_coin sind etwa 400 zu finden. Einige Indoor-Automaten sind mit vending=subway_token getaggt.
Mir ging es erstmal nur darum, wie diese Münzen in alltäglicher englischer Sprache bezeichnet werden. Deswegen habe ich mir Fotos von Automaten im öffentlichen Raum angeschaut, um einen Beleg für “Token” als alltägliches Wort zu haben. Auch bei Herstellern von Automaten habe ich “Token” gefunden, für Spielautomaten ebenso wie für Park- oder Waschautomaten:
Frage: Sollten nicht alle Eigenschaften am Parkplatz hängen? Man zieht zwar das Ticket aus der Schranke aber das braucht man ja für den Parkplatz. Wenn jemand mit den OSM Daten eine Parkplatz-App o.ä. macht müsste er ja nicht nur nach Parkplätzen suchen sondern auch nach dazugehörigen Schranken oder Automaten. Wenn die nicht verbunden sind muss es doch schwierig sein einen Zusammenhang herzustellen.
Nur ein Gedanke da ich von irgendwelcher Programmierung keine Ahnung habe und darum nicht weiß wie schwierig etwas zu realisieren ist.
Gruß, Gerald