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

Reclus · 2010-08-09 19:47:20

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.

errt · 2010-08-09 20:04:28

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.

Reclus · 2010-08-09 20:18:43

errt wrote:

Warum also dann in einem Prozess dafür sorgen, dass es danach gleich drei Möglichkeiten gibt, ein Krankenhaus zu taggen?

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.

errt · 2010-08-09 21:33:52

Reclus wrote:

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

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.

Reclus · 2010-08-10 15:01:59

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

!i! · 2010-08-10 15:06:00

Vielen Dank Reclus! Dein Einsatz ist wirklich gut

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

Tordanik · 2010-08-10 16:50:30

!i! wrote:

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

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.

!i! · 2010-08-10 17:31:10

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?

BBO · 2010-08-10 17:45:27

!i! wrote:

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.

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

errt · 2010-08-10 18:32:04

Halte ich für kein gutes Argument. Auch das vermeintlich einfache amenity wird so oft falschgeschrieben. Und ein Schlüssel mehr oder weniger wird da nicht wirklich was daran ändern. Ich muss mir sowieso die gängigen Kombinationen einprägen, ob ich sie mir mit diesem oder jenem Schlüssel merke ist doch irrelevant. Ich werde nie jedes Wort kennen, dass in OSM als Schlüssel oder Wert verwendet wird, also muss ich deren Schreibung eben auswendig lernen oder im Wiki nachschlagen.

BBO · 2010-08-10 18:52:42

errt wrote:

Auch das vermeintlich einfache amenity wird so oft falschgeschrieben.

Unbedingt einfach würde ich es nicht einschätzen. Aber es wird oft falschgeschrieben, richtig.

errt wrote:

Und ein Schlüssel mehr oder weniger wird da nicht wirklich was daran ändern.

Einer sicher nicht aber wenn "alles" neu in Kategorien gesteckt werden sollte...

errt wrote:

Ich muss mir sowieso die gängigen Kombinationen einprägen, ob ich sie mir mit diesem oder jenem Schlüssel merke ist doch irrelevant.

Das kann ich schlecht einschätzen. Aber wenn du meinst...

War auch nur so Einwurf aus meiner Richtung. Vieles was für uns Fortgeschrittene einfach, logisch usw. klingt muss dies nicht für Anfänger sein. Dieses Problem dürfen wir nicht aus den Augen verlieren. Wir sind auf "Nachwuchs" gerade auf dem Lande angewiesen. Ich befürchte diese werden zur Zeit noch durch zu komplizierte Strukturen schnell abgeschreckt.

BBO

errt · 2010-08-10 21:47:02

Ich denke, dass das eher andersrum ist: Die, die schon länger hier sind, beschweren sich, weil sie seit Jahren amenity für Krankenhäuser verwendet haben und sich jetzt umgewöhnen sollen. Ein Anfänger dagegen wird sich umschauen, sehen "Aha, Krankenhäuser werden als healthcare=hospital getaggt" und sich denken, dass das ja irgendwo logisch sei und wenig Probleme damit haben. Zumindest ist das meine Meinung

BBO · 2010-08-10 21:58:53

Wir reden aneinander vorbei... es ging mir Hauptsächlich um das Allgemeine weniger auf dieses konkrete Problem bezogen... hätte ich sicher deutlicher Ausdrücken müssen.

Aber: amenity=hospital ist für mich genauso logisch wie healthcare. Ist aber auch ein ungünstiges Beispiel. Die meisten Krankenhäuser sind getaggt (hier alle) und die Umstellerei wird sicher eh ein Bot vornehmen. Hier auf dem Land kommen keine neuen mehr dazu (es werden eher weniger). Also wird sich wohl auch kaum jemand umgewöhnen müssen oder überhaupt erst nachschauen.

BBO

Last edited by BBO (2010-08-10 22:10:26)

!i! · 2010-08-10 22:19:59

Ja ebend, ich sehe es als gar nicht so gravierend an. Die meiste Arbeit haben die Leute die die Software schreiben, weil sie die anpassen müssen aber für die Mapper ist es nur eine kurze Umgewöhnung bzw. durch die Editoren ändert sich nicht wirklich was dran.

Tordanik · 2010-08-11 07:39:03

!i! wrote:

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 frage mich eben, wieso dort "zu viele" Sachen sind - die Anzahl der möglichen Werte übersteigt die Anzahl der Wörter der englischen Sprache, da sollte also doch eigentlich genug Platz für so ziemlich alle Objekte der Realität sein.

Eben wegen der doch eher zufälligen Abgrenzung sehe ich auch nicht viele Fälle, wo ich in einem Tool wirklich nach einem Kategorienschlüssel filtern wollte. In Dokumentation (z.B. in den Map Features) muss man ja eh nicht nach Schlüssel sortieren, dort kann man einen Healthcare-Abschnitt ja auch anlegen, wenn alle Tags darin in amenity liegen.

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?

Das Problem der Abgrenzung zu Nachbarkategorien hat man keineswegs immer, sondern nur dann, wenn man auf der Einsortierung in Kategorien besteht - was ich eben gerne unterlassen würde.

Aber ich sehe schon, ich werde euch den Vorsatz, amenity aufzuräumen, wohl nicht ausreden können. Minimiert wenigstens etwas den Schaden durch die versuchte Umstellung:

Redet mit den Leuten vom "medical"-Proposal und überzeugt sie, es zurückzuziehen, damit nicht noch eine Variante mehr herumschwirrt.
Macht in der RFC-Infomail von vornherein klar, dass im Rahmen des Proposals auch eine Umstellung existierender Tags stattfindet, so dass sich keiner hintergangen fühlt.

Mal sehen, wie die Reaktion der weiteren Community auf die Umstellung populärer Tags wie amenity=hospital ausfällt. Ich rechne mit einer Verstärkung der auf den englischsprachigen Listen gerne geäußerten Ressentiments gegenüber "wiki-fiddlers" und einem weiteren Akzeptanzverlust des Proposal-Prozesses.

BBO · 2010-08-11 07:44:57

@Tordanik
Das wollte auch ich Ursprünglich ausdrücken, bin dann aber wohl gedanklich etwas abgeschweift und habe mich undeutlich ausgedrückt bzw. bin zu einem anderen Thema gewechselt.
Vielen Dank für deinen Post

BBO

!i! · 2010-08-11 07:49:21

Danke für den Hinweis Tordanik, habe sie mal angeschrieben.

Ich denke das es ebend wesentlich einfacher ist, wenn man eine Karte für BOS oder so machen will und sofort sieht, dass ja die Objekte der Kategorien Healht und Emergency sicherlich für einen in Frage kommen anstatt wirklich die komplette Featureliste durchgehen zu müssen um zu schauen was denn da gut für wäre.
Ist aber vielleicht ein subjektives Ding. Nur jedes Directory braucht eine Hierachie, auch wenn diese dann nicht für jeden zufriedenstellend ist.
Das dadurch Änderungen notwendig sind, ist leider so. Aber da sich OSM insgesamt immer weiter spezialisieren wird, wird das wohl öfters vorkommen.

Von daher lasst uns erstmal schauen was andere sagen wenn wir das Proposal auf den Weg gebracht haben

chris66 · 2010-08-11 09:21:19

Ich bin auch Tordaniks Meinung. Wieso überlässt man nicht den Anwendungen die Kategorienbildung?
Die Kategorien hängen ja eventuell auch vom Anwendungszweck ab.

Je mehr Keys es gibt, desto größer die Gefahr des Falsch-Taggings.

"Wie tacke ich nochmal 'ne Sauna? War das leisure, amenity oder gar healthcare?"

Und etablierte Tags nachträglich zu ändern, das sollte meiner Meinung nur im
absoluten Ausnahmefall gemacht werden.

Chris

!i! · 2010-08-11 09:41:11

Hmm ja ok stimmt schon aber mit derselben Begründung könnte man doch auch wieder dafür sein und sagen, dass die Anwendungen dass dann eh für einen machen?

Aber Wikis sind doch immer in Bewegung? Und das ist doch auch jedem klar bei OSM, dass weder der Zustand der Datenbasis noch das Modell je final ist.

Das geht ja auch ein wenig über diesen Prosposal hinaus, ich fände es aber gut, wenn wir das beim RFC (und dann ebend international) mal bereden können.

!i! · 2010-08-11 19:06:21

Das andere Proposal wird wohl eingestellt.

Ich habe noch 2 Fragen aufgeworfen, könntet ihr auf die noch mal bitte eingehen?
http://wiki.openstreetmap.org/wiki/Talk … _values.3F

!i! · 2010-08-24 12:26:40

Ok das Proposal ist nun im RFC Status, also bitte schhaut mal drüber und kommentiert es auf der Talk Wiki Seite
http://wiki.openstreetmap.org/wiki/Prop … Healthcare

chris66 · 2010-08-24 12:52:47

<gelöscht>

Last edited by chris66 (2010-08-24 12:58:41)

Reclus · 2010-10-30 14:53:15

Der healthcare-Proposal steht ab Montag, den 1. November 2010, zur Wahl. Bitte stimmt ab. Danke!

!i! · 2010-10-30 16:47:11

Danke schon mal für deine lange Geduld und die viele Arbeit Reclus :-)

r-michael · 2010-10-31 08:17:02

Reclus wrote:

Der healthcare-Proposal steht ab Montag, den 1. November 2010, zur Wahl. Bitte stimmt ab. Danke!

Die Daten für "vote start" und "vote end" sollten aber auch noch in den Proposed Features eingetragen werden, damit Jeder darüber informiert ist.
Eine Frage hätte ich noch dazu:
Sehe ich das richtig, dass man nur über das gesamte Paket abstimmen kann und nicht über einzelne Features?

mfG Michael

Announcement

#26 2010-08-09 19:47:20

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

#27 2010-08-09 20:04:28

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

#28 2010-08-09 20:18:43

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

#29 2010-08-09 21:33:52

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

#30 2010-08-10 15:01:59

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

#31 2010-08-10 15:06:00

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

#32 2010-08-10 16:50:30

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

#33 2010-08-10 17:31:10

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

#34 2010-08-10 17:45:27

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

#35 2010-08-10 18:32:04

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

#36 2010-08-10 18:52:42

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

#37 2010-08-10 21:47:02

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

#38 2010-08-10 21:58:53

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

#39 2010-08-10 22:19:59

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

#40 2010-08-11 07:39:03

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

#41 2010-08-11 07:44:57

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

#42 2010-08-11 07:49:21

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

#43 2010-08-11 09:21:19

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

#44 2010-08-11 09:41:11

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

#45 2010-08-11 19:06:21

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

#46 2010-08-24 12:26:40

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

#47 2010-08-24 12:52:47

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

#48 2010-10-30 14:53:15

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

#49 2010-10-30 16:47:11

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

#50 2010-10-31 08:17:02

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

Board footer