Parken mit Münze

Nein, aber das Wiki ist ja nur die Oberfläche, die Darstellung von Entscheidungen. Also wenn du Ideen hast wie du im Wiki besonders gut diese Entscheidungen darstellen und vermitteln kannst, go forward, be bold :slight_smile: Aber das heißt ja nicht, dass man kreativ im Alleingang Entscheidungen treffen kann.

Das ist meiner Meinung nach halt auch ein weiteres Problem, dass diese Ebenen immer verwechselt werden. Streng genommen, bräuchten wir eigentlich, wie bei Software üblich, eine festgeschriebene Dokumentation, die eher strukturell ausgelegt ist. Darauf könnte sich dann das Wiki beziehen, um das schön und gut zu vermitteln und in Zusammenhang zu bringen. Dass das so vermischt ist, hat mit OSMs Entiwcklung zu tun. Wäre man von Anfang an mit so einer strukturistischen Dokumentation an die Sache rangegangen, hätte OSM niemals so toll frei und schön wachsen können. Und ich finde auch nicht, dass man das jetzt strikt ändern muss. Aber etwas mehr Ordnung in diesen Wiki-klinsch zu bringen fänd ich schon wichtig. Vor allem deshalb, weil es inzwischen nicht mehr dazu dient neue Leute langfristig zu motivieren, weil dieses Chaos und die Unklarheit viel mehr abschreckt als anzieht.

kann ich mich anschließen :slight_smile: Aber trotzdem brauchen wir ja auch noch Entscheidungsprozesse

Aber auch die Proposals werden nur von einer “geringen” Prozentzahl aller Mapper entschieden, falls sie an der Abstimmung teilnehmen.

Vielleicht deshalb werden Schlüssel und Werte öfter neu gebildet.
Dort sollte dann eine Zusammenführung von gleichen / ähnlichen erfolgen und der meiste Verwendung Vorrang geben.

richtig, aber zumindest ist das ein offener prozess, wenn nur hier im deutschen Forum was diskutiert wird oder man gleich schonmal proforma das wiki anpasst ist das nicht offen. Ich sehe ja wie gesagt auch die schwerfälligkeit und schlechte akzeptanz des Proposal Prozesses. Aber ich bin zumindest dafür die taggingliste zu informieren bevor man etwas ändern will.

Man kann nun hier im deutschen Forum diskutieren, eine Entscheidung treffen und ins Wiki packen was dann später wieder jemand aus einem anderen Sprachraum ändert.

Oder man kann hier eine Entscheidung treffen, die auf der Taggingliste vorstellen wo sie dann eventuell wieder zerrupft wird.

Oder man kann die Taggingliste schon während der Diskussion informierenm damit die Leute dor auch Ideen spinnen können wenn sie Lust haben und man kann die Diskussionen gegenseitig befruchten. So läuft man auch nicht Gefahr, dass Leute das Gefühl haben übergangen zu werden und man findet auch heraus, ob ein Thema vielleicht unerwarteter Weise doch so kontrovers gesehen wird, dass man ein Proposal starten muss. Ich halte das momentan für die beste Lösung, aber hab keinen Bock immer den Informator auf der Tagginglist zu spielen :slight_smile:

Hey, ich wusste noch gar nicht, wieviel Resonanz ein Einzeiler in einer dt. Wiki-Beschreibung auslösen kann.
Nur hat sich noch keiner (außer Thoschi) irgendeinen Kopf gemacht, wie das, zugegebene sehr kleine OSM-Tagging Problem (wir reden jetzt wieder über die Frage im #1 von Gerald) gelöst werden könnte…

Darum bat ich und nicht um eine Grundsatzdiskussion zur Neuaufstellung und Folgeprozeduren zum bisher gebräuchlichen Proposalprozessen.

(mM.: Ohne das tolle Engagement vieler OSM’ler, die das OSM Wiki ausformulieren, ergänzen, neue Seiten erstellen, übersetzen, vereinheitlichen (ohne jede Zeile auszudiskutieren)… wäre OSM in all den Jahren ein Raum für Hobbykartenbastler geblieben. Dabei soll natürlich alle primär wichtigen Angelegenheiten auf möglichst vielen Commun.-Plattformen ausdiskutiert werden, was ich auch für richtig halte.)

… Das Tag payment:special_coin hat imho eine Daseinsberechtigung. Aufmerksam machen möchte ich jedoch auch auf den engl. Begriff:

Token Coin auch hier im eng. Wiki beschrieben.

Vielleicht wäre dies eher was für die internationale Variante oder nur dieses (wenn dies im engl. Sprachraum genutzt wird für z.B. Parken mit Sondermünze). Um dies in Erfahrung zu bringen, bitte ich jedoch, englisch erfahrenere Kollegen um Meinung und Recherche.
(Anh. mM: Für den deutschen Sprachraum eignet sich der Begriff weniger, denke ich. Der Begriff war mir bislang nicht bekannt.)

P.S. Habe den Vorschlag “special_coin” erst mal wieder rausgenommen. Grundsätzlich (nach weiterer Recherche) wäre tatsächlich für alle Bezahlzwecke mittels einer Hilfsmünze das tag payment=token_coin besser gegeignet. Wer schlägt das vor auf der Diskussionsseite?

naja, dass sich so so themen immer in verschiedene diskussionsstränge, vor allem grundsatzdiskussionen sit ja osm-typisch, ich erkläre mich da auch für extrem schuldig :slight_smile: Aber auch weil es sonst nicht so richtig gemacht wird…

Ganz meine Meinung, und zu den fleißigen OSM’lern gehörst Du maßgeblich dazu!

Edit: Wollte erst payment=token vorschlagen, da “token” eine Wertmarke ist, aber payment=token_coin ist eindeutiger:

https://commons.wikimedia.org/wiki/Category:Token_coins

Kürzlich habe ich von Stromtankstellen gehört, für die man Wertmarken erwerben muss. In Zusammenhang damit dürfte auch ein Automatentyp von Interesse sein: “token machine”, “token vending machine” oder “token change machine”.

Okay, das tagging wäre natürlich payment:token_coin=yes. Hab es dann mal auf der Diskussionseite vorgeschlagen.

Der Fall ist doch eher ungewöhnlich, daher kann ich mir nicht vorstellen, dass es in absehbarer Zeit ein Navigationsprogramm geben wird, das seinem Benutzer die besondere Lage verständlich mitteilt. Daher wird wohl zusätzlich zu irgendwelchen Spezialtags eine verständliche erforderlich sein.

Wenn wir mal “weiterspinnen”, befindet sich doch die Einwurfsvorrichtung für eine Parkmünze oder ein Ticket an einem barrier=lift_gate.
Ich finde erstmal die deutsche Beschreibung dafür nicht sehr gelungen. Bei den meißten kostenpflichtigen Parkplätzen muss man ein Ticket oder eine Münze einwerfen, um dieses Barrier “öffnen” zu lassen.
Wie wird dies getaggt? (Auch im Hinblick auf immer mehr Indoor-Tagging)
Ein Automat für Parkmünzen könnte dann so getaggt werden:

amenity=vending_machine
vending=token_coin
token_coin=parking

P.S. Schlage vor für ein Parkplatz Ausgang Lift_gate: access:for=parking_tickets / token_coin / automatic_open

Mit der Bildersuche habe ich mir Beispiele von Automaten angeschaut. Dort wird nur das Wort “Token” verwendet:

https://commons.wikimedia.org/wiki/File:Spadina_TTC_85_Spadina_Road_token_vending_machine_15628608380.jpg

Also reicht wahrscheinlich:

amenity=vending_machine
vending=token <- Singular/Plural?
token=parking/bus/...

payment:token=yes wird laut Taginfo bereits (selten) verwendet. Bei Bedarf könnte man vielleicht noch <ticket=coin> angeben. Wobei ich mich frage, ob das überhaupt erforderlich ist. Denn bei Zahlung per Wertmarke aus Papier würde man vielleicht eher payment:prepaid_ticket=yes angeben.

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 … :wink:
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:

https://www.eurocoin.co.uk/products/ta1006-thomas-1006

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