Neuer Key healthcare in Map features eintragen ... noch nie gemacht

Es ist möglich. Aber: Ich halte das nicht für einen gängigen Anwendungsfall, denn:

  • Eigentlich alle Renderer, die in erster Linie versuchen, eine praktisch nutzbare Karte zu erstellen, ignorieren sogar viele bekannte Tags. Es ist nicht anzunehmen, dass sie dann Dinge rendern wollen, von denen sie nicht einmal wissen, was es ist. Der Renderer, der alles rendert, wäre keineswegs der Normalfall.

  • Wenn man eine Kategorie wie “Gesundheit” konsequent durchzieht, dann sind die Objekte darin viel zu unterschiedlich, um sie vernünftigerweise noch gleich behandeln zu können. Ein Symbol, das sowohl für Objekte von der Größe eines Krankenhauses als auch für den einzelnen Defibrillator-Kasten an einer Wand eingesetzt wird (und zwangsläufig auf der gleichen Zoomstufe auftaucht) wäre nicht besonders aussagekräftig.

  • Falls der Renderer-Autor eine andere Meinung davon hat, wie die Objekte einsortiert werden sollen, nützt ihm der Schlüssel gar nichts. Und, wie ich schon versucht habe, darzustellen: Es gibt nun mal nicht die eine “richtige” Kategorisierung, die jeder Renderer-Autor wählen würde. Neben den bisherigen Vorschlägen (healthcare, medical, emergency) könnte man ein Krankenhaus z.B. auch als “öffentliches Gebäude” einsortieren - oder in sicher viele weitere Kategorien.

  • Wenn ein Renderer wirklich dasselbe Symbol für viele Objekte verwenden möchte, dann ist der Aufwand für das Ergänzen einer Liste der Tags für dieses Symbol sehr gering. Wenn der Renderer-Autor die Kontrolle darüber abzugeben bereit ist (das würde er ja auch, wenn er neu erfundene Tags automatisch anhand des Schlüssels rendern lässt), dann könnte das sogar eine Wiki-Seite o.ä. sein. Und: Mit einer solchen Technik könnten unterschiedliche Renderer problemlos unterschiedliche Kategorisierungen verwenden und das vorgenannte Problem wäre vermieden.

Das Tag “amenity” ist meiner Meinung nach

  1. absolute aussagelos (was ist eine Annehmlichkeit http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=&search=amenity )
  2. total überfrachtet mit den unterschiedlichsten Dingen von k1=‘amenity’ v1=‘hunting_stand’ bis k1=‘amenity’ v1=‘school’

Ich plädiere für eine langfristige Abschaffung von “amenity” und der Einführung von aussagekräftigen Tags.

Und das ist gut so! Der Wert (“hospital”/“dentist” …) sagt nämlich schon alles aus, was nötig ist: Dieses Objekt ist ein Krankenhaus/Zahnarzt/…

Weitere Aussagen sind nicht nötig - von Zusatzattributen abgesehen, natürlich -, also soll der Schlüssel aussagelos sein.

Ich fände eine Ersetzung von “amenity” und anderer Hauptschlüssel (natural, man_made - also Schlüssel, die den Objekttyp, und nicht etwa Attribute angeben) hin zu einem eindeutiger generischen Schlüssel (“type”, “class” o.ä.) gut: Damit wäre klar, dass die Information ausschließlich im Wert zu finden ist und sein soll.

Aber wahrscheinlich ist das den Aufwand der Umstellung nicht wert, amenity tuts schon auch.

Generische Hauptschlüssel wären sicher eine Lösung, aber in vielen Fällen steckt die Hauptinformation im Schlüssel,
z.B highway=…, railway=…, shop= …,
bei anderen dagegen nur im Wert, landuse=…, natural=…

Ich persönlich bevorzuge das erste,nämlich aussagekräftige Schlüssel, aber immer lässt sich das nicht realisieren.

Ich versteh dich schon. Woher soll ein Einsteiger wissen was nach HEALTH und was nach EMERGENCY kommt…

Nur müssen wir das aus den genannten Gründen auseinanderziehen, hilft nix sonst haben wir echt ein Chaos.

Wenn man mal schaut wie es bei anderen Hierachien z.B. Bibliotheken in Programmiersprachen geregelt wird ist es ähnlich. Einiges würde man intuitiv an anderen Stellen erwarten aber das geht schon, wenn einen die Werkzeuge, Listen,… dabei unterstützen

Dem stimme ich voll zu. Diese Schlüssel “täuschen” eine Klassifikation der zu kartierenden Objekte vor, die sie jedoch weder tatsächlich leisten noch leisten können. Versuche, dies dennoch zu tun ergeben oft endlose und unnötige Diskussionen, da sie meiner Kenntnis nach noch nie zu einer Einigung geführt haben (führen können). Zum Beispiel wird an der wikipedia: Dewey-Dezimalklassifikation seit dem 18. Jahrhundert gearbeitet und trotz Einsatz von viel Geld und Menschen gibt es bis heute kein einheitliches System.

Ausserdem gilt bei OSM:

Mein Hauptproblem mit diesem Argument ist die Tatsache, dass auf der Proposalseite healthcare=biohazard vorgeschlagen wird. Ich würde wirklich nur ungern ein Gesundheitslogo bei einem Seuchengebiet sehen. Ansonsten ist mir relativ egal, ob der Schlüssel nun amenity oder healthcare ist, auch wenn ich aktuell noch keinen großen Nutzen sehe in einer Umstellung, da es sich ja praktisch nur um einen 1:1 Austausch der Schlüssel handelt.

amenity=waste_disposal
Du hast recht, irgendwas ist da bei der Namensgebung falsch gelaufen… :smiley:

Wenn man amenity mit (sonstige) Einrichtung üebersetzt, dann passt auch das!

Der Defibrillator-Kasten gehört meiner Meinung auch nicht in “healthcare”, sondern venünftigerweise in “emergency” o.ä. Die Rettungsdiensten sind eine eigene Schiene. Bei einem Krankenhaus fände ich es z.B. nicht schlimm, wenn es sowohl ein “healthcare”- als auch ein “emergency”-Tag hätte. Sinnvollerweise wäre die Notaufnahme mit “emergency” getaggt.

Ich habe übrigens den “heathcare”-Vorschlag um ein paar Gesundheitsberufe ergänzt. Logopäden, (nichtärztliche) Phychotherapeuten, Podologen & Co.

Finde ich auch unsinnig.

Was mich stört ist, dass es einige Gesundheitsberufe, für die es bis jetzt keine vorgesehene Möglichkeit gibt sie zu taggen. Ergotherapeuten, Physiotherapeuten, Logopäden & Co. Laut Wikipedia laut Forsa sind jeweils 20% aller Kinder in Physiotherapie und Ergotherapie. Diese Berufe dürften also eine gewisse Relevanz haben.

Ist noch jemand außer mir der Ansicht, dass Apotheken in “shop” gehören?

Apotheken sind doch im Wesentlichen Läden für Medikamente. Auch wenn Medikamente besondere Handelswaren sind und Apotheken deshalb besonders lizensiert werden und der Betreiber eine besondere Ausbildung benötigt und ggf. auch eine Beratung anbieten oder einfache Medikamente selbst herstellen kann. Es bleibt doch ein Laden.

Da es aber keine Doppeldeutigkeit beim Wort “Ergotherapeut” gibt, kann es genausogut in amenity untergebracht werden. Auch wenn ich eher für Kategorienschlüssel bin: Das ist noch kein Argument. Und natürlich ist es nicht schlimm, wenn es einen healthcare und einen emergency Schlüssel mit dem Wert hospital gibt. Aber einen Nutzen kann man daraus nicht ziehen. Warum also dann in einem Prozess dafür sorgen, dass es danach gleich drei Möglichkeiten gibt, ein Krankenhaus zu taggen? Denkt doch auch mal an die Renderer, deren Regeln immer weiter aufgeblasen werden, weil es von allem drei Dutzend Varianten gibt. Dann lieber einmal was vernünftiges geschaffen. Ein Schema in das alles passt und das sobald keiner mehr über den Haufen wirft.

Im Vorschlag steht ja, dass “healthcare=hospital” gleichbedeutend zu “amenity=hospital” stehen soll. Eigentlich wäre es ja aber eher sinnvoll vorzuschlagen, dass ersteres letzteres ablösen soll. Dito bei “amenity=doctors” und “amenity=dentist”.

Bezüglich einem “emergency”-Tag für Krankenhäuser: Das sollte meiner Meinung nach entweder zusätzlich zu “healthcare=hospital” stehen oder besser nur die Notaufnahme anzeigen.

Keine n Alternativen. Da stimme ich voll zu.

Ja, ich. Wenn du es jetzt nicht angesprochen hättest, hätte ich sogar geschworen, dass sie da schon drin sind. Tatsächlich ist da aber nur chemist. Und ja: Wenn schon, dann sollte es den anderen Tag zumindest offiziell ablösen. Weiterverwendet wird er trotzdem noch werden. Und ich widerspreche emergency=hospital für eine Notaufnahme. Sollte wenn dann emergency=ER sein o.ä. Aber nicht den gleichen Wert für etwas inhaltlich deutlich anderes.

Ich habe die Wikiseite mal überarbeitet. Könntet ihr vielleicht nochmal drüber schauen bevor ich den RFC starte?

Vielen Dank Reclus! Dein Einsatz ist wirklich gut :slight_smile:

Ich werd noch mal mit ein paar Medizinern sprechen was die darüber denken.

Bitte zeige mir noch mal (?) die Gründe, die erste Nennung muss ich verpasst haben. Hilfe für Renderer wurde angesprochen, aber das ist nicht stichhaltig, siehe weiter oben. Das Fehlen von eigener Aussagekraft des “amenity”-Tags ist kein Bug, sondern ein Feature - da die komplette Aussage ja schon im Wert liegt. Inwiefern produziert die Verwendung von amenity also ein Chaos? Ich verstehe ehrlich nicht, woher diese Bedenken kommen!

Als Hinweis, falls das der Grund sein sollte: Auch wenn Tags denselben Schlüssel verwenden, kann man sie im Wiki, in Preset-Menüs und anderswo trotzdem problemlos in Kategorien sortieren. Es besteht keine Verpflichtung, alles mit demselben Schlüssel als unstrukturierte Liste hinzukippen.

Ich meinte insbesondere die Kritik, dass das teilweise subjektv ist, was in HEALTH und was in EMERGENCY o.ä. liegt.
Global gesehen sind zu viele Sachen bereits bei AMENITY und das ist auch kein Begriff, den man unbedingt kennt.
Eine Selektion von Objekten oder auch nur Features wird so wesentlich vereinfacht, indem man sich auf einige wenige Kategorien beschränkt und nicht die große Hauptkategorie komplett durchsuchen muss.

Ich sehe auch keinen fundamentalen Nachteil das als HEALTH zu spezialisieren, das Problem das Abgrenzung zu Nachbarkategorien hat man ja immer und das ist nie (z.B. kulturell) eindeutig. Aber vielleicht habe ich etwas übersehen? :confused:

Wenn ich etwas suche nutze ich die Suche im Wiki und schaue nicht eine “Kategorie” durch. Wenn es um Vorlagen im Editor geht: hier ist niemand gezwungen alles mit amenity in eine Kategorie zu stecken.
Es gibt auch genügend Mitmenschen die nicht die Vorlagen nutzen und kein English können. Für dich und mich mag die Bedeutung und Schreibweise von health, emergency etc. klar sein, aber für genügend andere nicht. Diesen ist nicht geholfen wenn sie sich noch mehr “fremde Buchstabenfolgen” einprägen müssen. DIESE Probleme gibt es. Ich habe gerade erst wieder einige “Tippfehler” beseitigt.

BBO