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

Ich habe für den neuen Schlüssel “healthcare” das Post-vote clean-up angefangen (und bis auf die Map features soweit auch alles gemacht).
Hab auch schon ein Map Features Template erstellt.

Da ich das alles aber zum ersten mal mache und das dann auch noch gleich bei einem neuen Key, scheue ich mich noch das Ganze in die Map Features zu stellen.

Kann einer von euch da mal drüber schaun ob das Map Features Template und alles andere so richtig ist?

Ich weiss auch noch nicht wie ich das mit den Values wie hospital, dentist etc. machen soll. Die stehen derzeit ja unter amenity und sollen in das healthcare wandern. Soll ich zu jedem eine Kopie der Originalseite anlegen oder es eher direkt verschieben (also z.B. von http://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddoctors nach http://wiki.openstreetmap.org/wiki/Tag:healthcare%3Ddoctors verschieben?) Und bei den Map features unter amenity bei dem Tag jeweils ein Kommentar eintragen, dass das nun durch healthcare=doctors etc. ersetzt wurde und man künftig dieses verwenden soll?

Danke schonmal für die Hilfe :slight_smile:
Steffen

Hey, das Proposal wurde nach den üblichen Regeln nicht angenommen, da weniger als 15 Votes und keine einstimmige Zustimmung. Selbst nach der “Rule of thumb” ist das als Ablehnung zu interpretieren.

Wenn man dann noch bedenkt, dass hier nicht ein neues Tag eingeführt, sondern vollkommen problemlos existierende und tausendfach verwendete Tags ersetzt werden sollen - was Änderungen in sämtlichen Anwendungen nach sich zieht -, ist der Vorstoß als gescheitert zu betrachten.

Sehe ich auch so. Für eine Änderung von solcher Tragweite braucht man deutlich mehr Zustimmung.

Oh Shit sorry, hab das unanimous überlesen. Dann mach ich das heute Abend wieder rückgängig … gut das ich nochmal nachgefragt hab …

Ist die Frage wieviel Zustimmungen es dafür braucht. Eine Regel dazu gibt es ja nicht.

Doch die Regeln gibt es schon…

Die Frage ist halt wie bindend das Ganze ist. Es sind schon mehrere Dinge einfach eingeführt worden ohne das jemals ein Proposal existierte.
Wenn jedoch

dann ist das natürlich nicht i.O.

Zusätzliche Tags werden öfters mal dazugenommen, wenn sie schon häufig verwendet werden (Hab mal was von einer Faustregel > 100).

Aber ein Umtaggen von etablierten Tags sollte man grundsätzlich vermeiden.

So, ich hab mal alles wieder rueckgaengig gemacht. Nur die Key-Seite (http://wiki.openstreetmap.org/wiki/Key:healthcare) konnte ich nicht loeschen, wo kann ich denn einen Loeschantrag stellen? Konnte nichts finden.

bezgl. Umtaggen von tags vermeiden: Ich denke solange wir noch die moeglichkeit haben weil OSM bisher (weltlich gesehen) in sehr wenigen laendern so bekannt ist wie in Deutschland, sollten wir es nutzen die keys zu strukturieren wo es sinnvoll ist um die Uebersichtlichkeit und zuordenbarkeit fuer die Zukunft zu gewaehrleisten.

Es gibt da Template:Delete.

Meiner Erfahrung nach wird das freilich nicht besonders zügig abgearbeitet im OSM-Wiki. Wir sollten ein paar Wikipedia-Löschadmins importieren. :wink:

Kann der Vorschlag nicht wieder neu eingestellt werden? Meine Stimme wäre ihm sicher. (War bei der ersten Wahl noch nicht dabei.)

amenity=(doctors|dentist) ist meiner Meinung nach viel zu einschränkend. Was ist mit anderen Gesundheitsberufen? Physiotherapeuten, Hebammen & Co.?

Wir arbeiten noch an einem neuen, leider brauchen wir jemanden, der den Proposal vorran treibt:
http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare

Das Proposal wäre prima und völlig unkontrovers, wenn es darauf verzichten würde, den Key zur “Sortierung” verwenden zu wollen, und einfach bei amenity bliebe.

Warum also dieser healthcare-Schlüssel? “It seems more logical to use different keys for different areas whenever possible” ist ja wohl kein praktisches Argument, sondern bestenfalls eine Geschmacksfrage. Und “der Bereich Gesundheitswesen ist so vielschichtig, daß er mit diesem TAG-Schema nicht zufriedenstellend erfaßt werden kann” ist irgendwie auch nicht einleuchtend - bei fast allen vorgeschlagenen Tags könnte man ohne jegliche Einschränkungen healthcare durch amenity ersetzen.

Tags wie healthcare=shop zeigen auch gleich ein Problem mit der Idee, Kategorien durch die Verwendung von Keys einführen zu wollen: Warum nicht shop=healthcare? Es gibt keinen zwingenden Grund, das eine dem anderen vorzuziehen - kann man also raten oder jedes Mal im Wiki nachschauen (wo dann wahrscheinlich hier das eine, dort das andere empfohlen wird…). Aber es blieben ja noch viel mehr Optionen: Auf der Tagging-Mailingliste hat erst kürzlich jemand vorgeschlagen, Krankenhäuser nach emergency=hospital zu verschieben, zusammen mit Feuerwehrstationen u.ä. Und medical=hospital ist auch schon in der Diskussion. Die Wahl des Schlüssels ist also letztlich nicht “logisch”, sondern willkürlich.

Der einzige entscheidende Unterschied für den Mapper durch wie auch immer gewählte Kategorien als Schlüssel ist, dass er sich nicht nur die Werte (hospital, dentist, …), sondern auch noch den Schlüssel merken muss (hat sich jetzt healthcare durchgesetzt oder medical? Doch emergency? Oder hat sich die Gruppe durchgesetzt, die emergency=hospital nur für Krankenhäuser mit Notaufnahme nehmen will? Was ganz anderes? Oder werden inzwischen alle Keys nebeneinander verwendet, aber wo war jetzt aber noch mal die Grenze?). Resultat: Mehr Merkaufwand, mehr Chaos, kein relevanter Nutzen.

Wegen dem Chaos wäre es ja sinnvoll das möglichst rasch eindeutig zu regeln.

Wegen dem Chaos wäre es sinnvoll, einfach alles in amenity unterzubringen (bzw. dort zu belassen). Viele der Probleme, die ich bei “Kategorienschlüsseln” sehe, haben nämlich nicht mal was mit der Umstellung zu tun und können daher auch nicht durch eine reibungslose Umstellungvermieden werden.

Auch nach einer reibungslosen Umstellung muss ein Mapper noch die willkürliche Einteilung von Objekten in Kategorien auswendig lernen. Auch nach einer reibungslosen Umstellung verstärken Schlüssel den Effekt, eigene Bedeutungen in sie hinein zu interpretieren, die ursprünglich nicht existierten (ähnlich der Bedeutungsverengung von natural=wood vor ein paar Jahren, seit der natural=wood jetzt ein “natürlicher” Wald ist, natural=water aber keineswegs “natürliches” Wasser sein muss). Und auch nach einer reibungslosen Umstellung hat die Verwendung von Kategorienschlüsseln eben keinen entscheidenden praktischen Nutzen.

Nur meine Meinung natürlich, aber ich halte den immer mal wieder gestarteten Versuch, amenity “aufzuräumen”, für einen Irrweg.

Einen praktischen Nutzen hätte es, wenn “healthcare=foo” von den Renderern ein Standard-Gesundheits-Logo bekommen würde, sofern kein spezielles foo-Logo definiert wäre. Ich weiß nicht, ob das möglich ist (noob).

Es gibt halt viele Gesundheitsberufe, die keine Ärzte sind, aber auf einer Karte Sinn machen: Heilpraktiker, Psychotherapeuten (keine Ärzte), Physiotherapeuten, Ergotherapeuten, Hebammen, Sprachtherapeuten, Ernährungsberater, Podologen

Wenn man die alle als “amenity=foo” eintragen würde, müsste man für jeden ein extra Logo definieren. Und dem Renderer nicht bekannte Gesundheitsberufe könnten nicht gerendert werden.

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: