Nette Toiletten - einheitliches Tagging

Hallo Joachim

ich würde mir das derzeitige (uneinheitliche) Schema mal etwas genauer ansehen und ev. daraus ein gutes Proposal ableiten.

amenity=toilets halte ich für wenig geeignet, da
1.) es von echten öffentlichen Toiletten nicht unterschieden werden kann, und
2.) es sich mit sämtlichen anderen amenity=* POIs schlägt.

amenity:toilets=yes (1350x verwendet) ist da schon um einiges besser, aus meiner Sicht aber oversized
toilets=yes (2100x verwendet) ist am einfachsten, mir aber zu unpräzise
toilets=permissive wäre nicht schlecht (bisher erst 3x verwendet)
toilets:access=permissive/customers beschreibt es auch recht eindeutig (permissive auch erst 45x verwendet)

Ich bin sicher, dass damit bereits recht brauchbare Varianten gebildet werden könnten.
Es müsste ich halt jemand die Mühe machen, das gut zu beschreiben.

Walter

Hmm dann aber bitte noch mal erklären, worin sich das nun von einer regulären öffentlichen Toilette unterscheidet? Die dürfen doch nun gerade genutzt werden, ohne dass man dort Gast ist? Und die Öffnungszeiten der Kneipen sind ja wirklich sehr ausgedehnt, von daher wäre mir das zu wenig dafür extra ein neues Schema aufzulegen :confused:

Danke für die Rückmeldungen.

Der Anschub, mich mit dieser Thematik zu beschäftigen, stammt aus dem Wettbewerb Apps4Bremen, in dessen Rahmen u.a. Geodaten zum Themenkomplex Nette Toilette, barrierefreie Behördentoiletten zur öffentlichen Nutzung und Standorte von Hundekotbehältern veröffentlicht wurden. Bremen hat das System übernommmen, um die Anzahl der städtischen Toiletten stark zu reduzieren und so jährlich eine Million Euro einzusparen. Vor diesem Hintergrund haben diese Toiletten schon einen gewissen öffentlichen Status und unterscheiden sich von normalen Kundentoiletten.

Wenn man sich die Gegend von Vegesack im Editor ansieht, wird anhand von den beiden Lokalen “Zum Vegesacker Jungen” und “Goden Wind” klar, dass man eine bessere Lösung braucht.

Natürlich habe ich mir schon Gedanken über ein Proposal gemacht . Der Einsendeschluss für den Wettbewerb ist der 01. Februar 2012, so dass das Tagging-Schema bis Ende diesen Jahres stehen sollte. Daher die Vorüberlegungen auf “breiter Basis” um schnell Möglichkeiten und Probleme zu erkennen.

Ziel ist, auszuprobieren wie man mit einer solche “Datenspende” communityverträglich und nachhaltig umgeht. Natürlich soll das Endergebnis möglichst einfach, universell verwendbar und leicht pflegbar sein.

Grüße
Joachim

Wir mappen zwar nicht für den Renderer, aber die Informationen sollen natürlich irgendwie auf die Karten. In einem weitläufigen Uni-Gebäude ist es natürlich kein Problem, einen entprechenden zusätzlichen Punkt zu setzen, aber in Innenstädten rückt alles sehr dicht zusammen.

Der Hauptzweck einer öffentlichen Toilette ist klar, denn dafür wurde sie ja gebaut, oft auch als einges Gebäude oder Gebäudeteil.
Ein Lokal oder Geschäft ist in erster Linie für Essen, Trinken und Einkaufen da und es stellt so nebenbei seine Toiletten im Rahmen der Aktion während der Geschäftszeiten zur Verfügung. Die Werbeanlage für den eigentlichen Geschäftszweck ist ja auch viel größer und auffälliger als das kleine Hinweisschild für die Zugehörigkeit zu dem Toilettensystem.

Bezüglich Öffnungszeiten, Adressdaten und Koordinaten gehören beide Funktionen zusammen und sollten in einem Datensatz gespeichert werden. Wie es dann dargestellt wird, hängt vom Themenschwerpunkt der Karte ab.

1+
walter

Mein Vorschlag:

amenity=restaurant
name=*
opening_hours=*
toilet=yes
toilet:access=permissive
toilet:system=Nette_Toilette
toilet:fee=yes/no

Alternativ wäre vielleicht toilet:access:system=* noch exakter, da ja nicht das Toilettensystem sondern das Zutrittssystem gemeint ist.
Mit toilet=yes + toilet:access=permissive ist eigentlich schon alles gesagt, andernfalls wird heute schon toilet:access=customers verwendet.

Walter

Anstatt :system würde ich :ref verwenden, der Einheitlichkeit halber.
Und dann nicht “Nette_Toilette” sondern “Nette Toilette”. Es heißt ja auch nicht “Berliner_Straße” sondern “Berliner Straße”.
Außerdem vielleicht toilet zu toilets, da letzteres öfter verwendet wird, und vor allem im Zusammenhang mit yes. toilet wiederum eher mit no.*
Ansonsten +1

Das führt dann zu:

Hallo E-Malte, sieht gut aus.

ref sollte man für eine eindeutige Bezeichnung der datenführenden Stelle verwenden, um später (halb)automatisch die Datenbestände auf Änderungen überprüfen zu können. Wie wäre es mit

toilets:ref=<interner Schlüsselwert>
toilets:brand=Nette Toilette

Grüße
Joachim

So sehr ich für die Kraft des faktischen bin, die Schlüssel sollten in Einzahl sein (egal ob positiv oder negativ)! Wenn zwingend eine Anzahl erfaßt werden soll, dann bitte mit capacity (dort dann aber auch die Anzahl der Pinkelbecken, die in der Höhe für Youngster sind :wink: ).

MfG Georg V.

Wie taggt man denn die Art des Zielpunkts im Urinal? Also Fliege oder Tor oder so?

toilets=yes + toilet=10 sieht schon sehr seltsam aus.
Um das heute noch zu korrigieren ist wohl ein Approval mit breiter Zustimmung inkl. gut aufgesetztem Bot notwendig, sonst sehe ich hier keine Change.
Dem Approval würde ich selbst nur dann zustimmen, wenn der Bot-Einsatz geklärt ist und gleichzeitig mit beschlossen wird.
Sonst schadet das ganze mehr als es nutzt.
http://wiki.openstreetmap.org/wiki/Automated_Edits

Walter

Warum ein aber? Es ist eine öffentliche Toilette. Sie hat einen anderen Besitzer, aber jeder darf ganz hochoffiziell dahin. Wie das ganze in der Karte aussieht, das sollte man doch lieber dem Kartenrenderer überlassen.

Wenn die Toilette als ganz normale Toilette gekennzeichnet ist und zusätzlich ein Tag für den jeweiligen Ortsverband oder wer auch immer dahintersteht hat, dann ist es doch vollkommen ausreichend. Der Renderer malt eh erstmal das Symbol für das Restaurant.

Meinst Du hier auch die Toiletten, die bei dem “Offenen System” mitmachen? Wenn die das monieren, gleich ne Beschwerde an den Systembetreiber schicken, daß die dafür Geld bekommen, aber alles unternehmen, daß keiner das nutzt.

Hallo Walter

toilet(s)=yes ist eigentlich überflüssig.

  • In Mitteleuropa sind Toiletten für das Gastgewerbe zwingend vorgeschrieben.
  • durch toilet(s):= ist in anderen Fällen ausreichend klar, dass es Toiletten geben muss.

Ansonsten möchte ich mich der Bemerkung von DD1GJ anschließen und :brand= vorschlagen.
Solange es amenity=toilets und toilets=yes heißt (http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtoilets) würde ich bei toilets:
bleiben. Wenn die beiden Werte geändert werden, kann man sich ja immer noch anpassen.

Edbert (EvanE)

Schon möglich, dass es überflüssig ist, aber:

  • OSM gibt es nicht nur in Mitteleuropa
  • wenn ich keine Infos über Systemname etc. habe, sondern nur weiß, dass es Toiletten sind, die ich mal benutzt habe, kann ich nichts anderes als toilets=yes eintragen*
  • zum Auswerten ist es meines Erachtens erheblich einfacher, wenn man zuerst nach toilets=yes schauen kann, und in Abhängigkeit davon dann nach weiteren Unterschlüsseln wie toilets:access= oder ähnlichem sucht oder es eben bleiben lässt

Viele Grüße,
Malte

  • Du trägst ja auch erstmal highway=xyz ein, obwohl sich das eigentlich aus den ganzen Access-Werten, der Breite, der Anzahl der Spuren, der Nutzung durch Busse, der refs und ähnlichem ergeben sollte. (Ok, schlechtes Beispiel, aber ich hoffe du weißt, worauf ich hinaus will.)

Hallo Malte

Wenn du nur weißt, dass es eine Toilette gibt, dann ist toilets=yes natürlich das Mittel der Wahl. Ich wollte auch keineswegs anregen, dies in solchen Fällen wegzulassen.
Im Fall dass du die anderen Attribute hast, ist es im Prinzip nicht notwendig. Die meisten Programme machen es sich eher einfach und suchen schlicht nach einem bestimmten Wert (hier ‘toilet’) im String. Also finden die auch automatisch die Sub-Taggs. Wenn die einen solche Zeichenkette finden, dann wird genauer nachgesehen/ausgewertet.
Dieses Verfahren wird deshalb gerne verwendet, weil toilet(s) oder auch andere Zeichenketten sowohl im Wert (amenity=toilets) als auch im Schlüssel (toilets=yes/no/…) vorkommen kann.

Nur um das klar zu machen:

  • Ich halte toilet(s)=yes für nicht notwendig, wenn es die Sub-Tags toilet(s):= gibt.
  • Aber auch in diesem Fall ist toilet(s)=yes durchaus möglich/zulässig.

Edbert (EvanE)

Hallo Edbert,

bei allen mir bekannten OSM-Datenformaten gibt es nicht “einen String”, in dem Schlüssel und Wert (key+value) gleichzeitig stehen.
In .osm (xml) sind es zwei verschiedene Attribute des XML-Elements-, und in den mir bekannten Datenbankrepräsentationen von OSM sind sie auch nach key und value getrennt.
Ich kann mir jedenfalls nicht vorstellen, dass es der Sinn einer (im Fall von OSM sogar großtenteils einheitlichen) key-value-Struktur ist, keys und values gleichzeitig nach einem Wert (hier “toilet”) zu durchsuchen.

Abgesehen davon ist es vom Prozessoraufwand meines Erachtens effektiver, wenn man zunächst einen key namens “toilet” sucht, und beim Finden desselben nach weiteren Unterschlüsseln (subkeys) sucht. Eine Suche eines Teilstrings innerhalb eines ganzen ist deutlich aufwändiger, weil die ganze Zeichenkette durchsucht werden muss, und sie nicht als ganzes benutzt werden kann. Außerdem besteht hier wieder das Problem der freien Wählbarkeit der Schlüssel. Dann hast du auf einmal als einziges einen key, der “toilets:women:disabled” heißt, und der einzige key ist.

In einer mit osem2pgsql gefüllten Datenbank findet man die Key-Value-Paare gleichberechtigt in einem Array. Sprich es ist egal ob du ein Array nach toilet im key oder im value suchst. Die Zuordnung Key oder Value geschieht einzig und allein über den Index des Arrays.
Viele Softwaretools vereinfachen sich die Auswertung der Schlüssel. Dies geschieht dadurch, dass nur die ersten X Zeichen des Schlüssels ausgewertet werden. Dies kann man recht schnell mit Teilstringfunktionen erreichen. Das heißt aber, dass der gesuchte Teilstring nicht irgendwo im String stehen darf, sondern zu Beginn des Strings stehen muss.

Sollen sie das? Mich interessiert das Finanzierungsmodell in einer Karte überhaupt nicht. Mich interessiert, wo ein Klo ist (amenity=toilets), ob ich es benutzen darf (access=yes/customer/private/no) und ob ich für die Benutzung zahlen muss (fee=*).

Und? Beim Rendern macht es keinen Unterschied. Restaurant und Klo sind sowieso 2 verschiedene Signaturen, egal ob du sie in 1 gemeinsamen oder in 2 getrennten Nodes erfasst hast.

Aber die anderen Tags gehören nicht zusammen, deshalb wird man nicht umhin kommen, 2 verschiedene Objekte zu erfassen.

Coast ist stolz darauf, mit den Tag-Value-Paaren eine einfache Struktur geschaffen zu haben, die jeder Mapper gleich versteht. Der Nachteil ist, dass komplexe Sachverhalte damit nicht vernünftig abgebildet werden können. Wenn du z.B. natural=peak + man_made=cross + name=XY + ele=123 zusammen in einem Node hast, bezieht sich name=XY dann auf den Gipfel oder aufs Kreuz? Und was ist, wenn der Gipfel einen Namen hat und das Kreuz einen anderen? Dann könntest du neue Tags einführen wie name:peak=* und name:cross=, oder name:natural:peak= und name:man_made:cross=, oder doch peak:name= und cross:name=? Das alles sparst du dir, wenn du 2 getrennte Nodes machst und die Redundanz in Kauf nimmst, dass in beiden die selbe ele= drinsteht. Genauso ist das mit den WCs.

Back to the roots? KISS? Mal ein paar Nächte darüber schlafen …
Man wird allmählich betriebsblind.