Voting beendet: Tagging von Lichtquellen als man_made=lamp

Leider selten geworden, aber es gibt auch noch ein paar Dörfer mit Laternenringen, da muss es dann kein System geben.

Und hier sind wie versprochen die Tagging-Presets für JOSM:

http://manuelhohmann.dyndns.org/osm/lamp.xml

Hallo Manuel,
zunächst einmal vielen Dank für deine ganze Mühe, auch wenn das Abstimmungsergebnis negativ ist.

Wenn ich an meine eigenen Proposals zurückdenke, dann waren auch dort das Ersetzen existierender Tags für viele ein Problem. Insofern würde ich einfach auf die Benutzung deines Schemas setzen und das sich highway=street_lamp dann “rauswächst” und Schritt für Schritt manuell durch die neuen Sachen ersetzt oder zumindest angereichert werden.

Ja, so sehe ich das auch. Wenn man bedenkt, wie viele Straßenlampen und andere Lichtquellen es gibt, sind selbst 235.000 existierende Nodes relativ wenig - zumal durch das aufkommende Micromapping erst noch ein Anwachsen von gemappten Lampen zu erwarten ist. Um so besser ist es, dass die Tags proposed sind und von einigen Mappern befürwortet wurden, die gerade für das Micromapping aktiv sind - und sie dann hoffentlich auch nutzen :wink:

Mal ganz davon abgesehen, dass ein Abstimmungsergebnis von +/- 0 am Ende zwar nicht positiv, aber immerhin auch nicht negativ ist :stuck_out_tongue:

Nun ja, nach meiner Meinung ist eine Straßenlampe schon ein wichtiges Element in der Straßenausstattung und ist daher bei highway durchaus gut aufgehoben.

Mein Vorschlag:

  1. Lasse highway=streetlamp wie es ist.
    Die zusätzlichen Taggs kann man ja auch dafür verwenden.
  2. Nimm Dir Frederiks Rat zu Herzen und vereinfache das Proposal.
    Nur die wichtigsten Elemente gehören zum Kern.
    Der Rest kann als mögliche / vorgeschlagene Erweiterung
    dokumentiert werden. Hier wäre ein Hinweis auf die Verwendung
    insbesondere für 3D-Anwendungen sicher sinnvoll.

Mit Punkt 2 nimmst du dem Problem “Zu kompliziert” die Schärfe. Wir ‘Deutschen’ mögen zu einem großen Teil gerne, die Dinge bis in die letzten Details zu beschreiben.
Nach meiner Einschätzung gehören lamp:type, lamp:lit und ggfs. support + lamp:height zum Kern des Vorschlags. Alles weitere sind Details für 3D-Rendering oder Technik-Verliebte.

Wichtig bei einer Überarbeitung wäre es, Kern und Erweiterung optisch durchgehend zu unterscheiden.

PS:
Ich fände es gut, wenn du das Proposal von “Proposed_features/lamp” in “Proposed_features/man_made=lamp” umbenennen würdest. Dann ist a) klarer, um was es geht, und der Vorschlag ist b) leichter zu finden.
Dem Dank von !i! schließe ich mich an.

Edbert (EvanE)

  1. Ich habe ja auch ausdrücklich geschrieben, dass ich nicht vorhabe, highway=street_lamp komplett umzutaggen, sondern erst dann nach und nach abzulösen, wenn sich das neue Tagging dafür etabliert hat. Genau das würde aber auch ohne Proposal irgendwann passieren, wenn neue Tags eingeführt und benutzt werden. Die gleiche Problematik stellt sich ja immer, wenn ein neues Tag vorgeschlagen wird, das ein altes ablösen soll.

  2. Genau deshalb habe ich ja diese ganzen Zusatztags ausdrücklich als “optional” gekennzeichnet und nie behauptet, dass man auch nur eines davon benutzen muss. Das grundlegende Tagging ist bewusst einfach gehalten - die ausdrücklich optionalen Attribute sind ja auch nur für jede Mapper / Anwender gedacht, die Wert darauf legen. So habe ich es ja auch im Proposal geschrieben.

Mit diesen beiden Punkten bin ich ja schon auf genau diese Kritik eingegangen und habe das Proposal vom ersten zum zweiten Voting entsprechend angepasst, was auch auf Zustimmung gestoßen ist. Aber allen kann man es ja ohnehin nie Recht machen.

Die Umbenennung ist eine gute Idee, das lässt sich sicher machen.

Ich sehe auch, dass du versucht hast, diese Probleme zu adressieren, aber vermutlich hat Edbert recht. Du kannst zehnmal optional drüberschreiben, wenn man auf die Seite geht wird man von einem halben Hundert Tags erschlagen. Wahrscheinlich hast du mehr Chancen, wenn du erstmal nur den Kern aufschreibst und darüber abstimmen lässt. Der Rest ist erstens nicht so wichtig und wird zweitens wahrscheinlich eher nur noch von wirklich interessierten betrachtet, die dem dann auch eher zustimmen werden. Das Gleiche gilt für highway=street_lamp - ja, da steht, dass du es nicht per Massenedit ersetzen willst. Aber trotzdem steht da letztlich, dass es verschwinden soll. Was ich durchaus unterstützen würde, aber eben auch vielfach auf Ablehnung stößt. Also vielleicht besser garnicht erwähnen, das neue Schema als Alternative einführen und dann sehen, ob sich das Problem nicht von selbst erledigt. Wenn es das nicht tut, aber deine Variante trotzdem schon genug Verbreitung hat, kann man immernoch ein Proposal machen, um highway=street_lamp für veraltet zu erklären.

Nun ja, inzwischen ist die Sache ja ohnehin so weit gelaufen und es wird sich zeigen, wie sich das Tagging nun entwickelt - unabhängig vom Ergebnis (das eben “nachträglich” übrigens noch eine positive Stimme bekommen hat, womit die Befürworter nun in der Mehrzahl sind).

Es gibt ja noch einige Möglichkeiten, ein erstrebtes Tagging-Schema ein wenig zu puschen:

  • viel drüber reden/schreiben: machst du
  • josm-preset erstellen: hast du
  • Tags in die Editoren integrieren lassen: schwierig
  • Statistiken/Trendberichte erzeugen
  • Karten/Anwendungen erstellen, die die neuen Tags verwenden

und ab und zu auch mal kleinere Brötchen backen (nicht alles gleich ganz neu machen)

Sieht doch eigentlich ganz gut aus. Mach in 2-3 Monaten einen neuen Anlauf und dann schau’n mer mal.

Gruss
walter

Genau so hatte ich es ja gemacht :wink: Mir hat das ganze auf jeden Fall gezeigt, dass es Interesse von Seiten der Community gibt, und wer Interesse hat, wird das Tagging sicherlich anwenden, und das unabhängig vom Stand des Proposals vermutlich auch jetzt schon (es gibt ja bereits 1600 man_made=lamp). Darum geht es mir und das ist ja die Hauptsache - nämlich dass Tags genutzt werden, wenn sie sinnvoll sind. Ob das Proposal dafür nun mit kleiner oder großer Mehrheit angenommen wurde, ist dafür ja letztlich Nebensache. Aber wenn das irgendwann noch mal jemand neu versuchen möchte, will ich natürlich niemanden davon abhalten :wink:

Nun ja, das scheint nicht wirklich rüber gekommen zu sein.
Immerhin steht im Proposal klar die Absicht highway=street_lamp auf Dauer abzulösen.
Mir ist z.B. nicht wirklich klar gewesen, was nun optional und was unabdingbar ist.

Also kürze dein Proposal, erwähne die optionalen Tags kurz (ohne die Details) als mögliche Erweiterungen und lagere deren Dokumentation auf eine eigene Seite aus.

Mache ganz klar, dass du highway=street_lamp nicht ersetzen willst.
Statt diesem man_made=lamp + lamp:type=street_lamp zu verwenden, soll alleinige Entscheidung der einzelnen Mapper sein (drei Tagging-Varianten funktionieren ja auch bei kombinierten Rad-/Fußwegen). Die Tagging-Praxis wird dann schon zeigen, ob es eine Mehrheit für das eine oder andere geben wird.
Falls es dann irgendwann mal eine Zwei-Drittel-Mehrheit für das zweite gibt, kann man immer noch vorschlagen highway=street_lamp als veraltet (depracted) zu erklären.

Edbert (EvanE)

Eben, mit der Betonung auf “auf Dauer”, und nicht von heute auf morgen. Gerade das ist ja eines der Argumente, das die Befürworter angesprochen hat - siehe die dortigen Kommentare.

Naja, viel deutlicher als es mit dem Wort “optional” ausdrücklich zu kennzeichnen geht as eigentlich nicht…

Wenn du so konkrete Ideen hast, kannst du das Proposal natürlich gerne übernehmen :wink: Mir persönlich fehlt für einen weiteren langwierigen Proposal-Prozess leider einfach die Zeit. Was ich natürlich durchaus machen könnte (und auch geplant hatte) wäre, Wiki-Seiten der Form Key:x und Tag:x=y für die vorgeschlagenen Tags zu erstellen - wenn ich das richtig sehe, kann man die ja auch mit einem “Status: Proposed” kennzeichnen. Das kann ich bei Gelegenheit mal machen.

Das ist ja gerade eines der grundlegenden Ziele des Proposals - natürlich langfristig und nicht von heute auf morgen.

@wambacher: Du hattest ja noch vorgeschlagen, Karten / Anwendungen zu erstellen, die das neue Tagging auswerten. Das hatte ich mir durchaus auch schon überlegt, die Auswertung ist ja nicht weiter schwierig. Mir fehlt es nur an passenden Server-Kapazitäten, um sowas einem größeren Kreis bereitzustellen… Aber wenn sich da was findet und ich etwas mehr Zeit finde, kann ich auch mal versuchen, was zu basteln.

So siehst du das und ich halte das auch für einen Fortschritt in deiner Argumentation.
Andere sehen nur, dass ihr liebgewonnes highway=street_lamp abgeschafft werden soll.

Nein, ich habe kein Interesse, dein Proposal zu übernehmen.

Aber konkret unterteile zwischen “Recommended combination” (Teil des Proposals) und “Optional extensions” (nicht Teil des Proposals).
Für mich gehören lamp:type, lamp:lit, height/lamp:height und support zu den “Recommended combination”. Das sind alles Dinge, die man auf einfache Weise durch Beobachtung ermitteln kann.
Alles weitere sind technische Details oder fürs 3D-Mapping und gehören zu den “Optional extensions” und damit nicht zum eigentlichen Proposal. Diese sollten nur kurz erwähnt und auf eine eigene Seite mit ihren Details ausgelagert werden. Das verhindert, dass ein Leser durch die Fülle der Möglichkeiten erschlagen wird und gleich mit Ablehnung reagiert.

Nun, manchmal ist es günstiger, das Endziel nicht explizit zu erwähnen.
Die diversen Proposals im Bereich Strom (power …) sind ein Beispiel dafür. Da steckt nach meinem Eindruck eine klare Gesamtabsicht dahinter. Das Beharren auf IEC Kompabilität ist nach meiner Meinung ein Indiz dafür.
Letztlich wird sowieso durch die Mapping-Praxis abgestimmt, egal wie eine Abstimmung gelaufen ist oder nicht.

Edbert (EvanE)

Meiner Meinung nach ist das die einzige Änderung, die für ein erfolgreiches Proposal nötig ist. Den aktuellen Abstimmungsbegründungen zufolge hätte man ohne die Gegner einer Ablösung von highway=street_lamp eine solide Mehrheit für das Proposal.

Der Meinung bin ich auch.
Ich begrüße die Initiative von MHohmann sehr. Ich finde, wir brauchen es.

Auf der Tagging-Mailingliste kam jetzt folgender Vorschlag auf:

Statt alle verschiedenen Arten von Lichtquellen unter man_made=lamp zusammenzufassen und dann per lamp:type=* zu spezifizieren, um was genau es sich handelt, wird ein neuer Key light_source=* für Lichtquellen eingeführt.

Vorteil: Auf diese Weise werden nicht mehr Straßenlaternen / Lichtquellen zum Zwecke der Beleuchtung mit Signallampen / Lichtquellen zum Zwecke der Kommunikation, Warnung, Dekoration etc. in einem gemeinsamen Tag man_made=lamp “gemischt” (was als Kritikpunkt beim Voting genannt wurde). Stattdessen gibt es nur noch den gemeinsamen Schlüssel light_source=*, aber verschiedene Werte für die verschiedenen Arten von Lichtquellen.

Beispiele:

  • light_source=lantern - Straßen-/Bahnhofs-/Flugplatz-Laterne. (Weil hier das Wort “street” mehr nicht vorkommt, beantwortet das auch die von einem Abstimmer gestellte Frage, wie man denn Laternen taggt, die nicht Teil einer Straße sind.)

  • light_source=floodlights - Flutlichtanlage.

  • light_source=warning - Warnleuchte (z.b. auf hohen Gebäuden oder Türmen)

Ein weiterer Vorteil ist, dass nun eine Laterne (unabhängig davon, was sie beleuchtet) mit nur einem Tag light_source=lantern getaggt werden kann statt mit dem vorher vorgeschlagenen man_made=lamp, lamp:type=street_lamp. Und für alle Befürworter von highway=street_lamp bleibt dieses Tag als Shortcut für light_source=lantern erhalten.

Als weiterer Vorschlag von der Mailingliste, der auch bei den Kommentaren der Abstimmung zu finden ist, wird nun nicht mehr “lamp” benutzt, da die “Lampe” im engeren Sinne das Leuchtmittel ist. Unterschlüssel zu light_source=* werden z.B. mit light:colour=, light:aperture=, light:direction=, light:tilt= getaggt - dann ist klar, dass es sich um die Farbe des Lichtes, den Öffnungswinkel des Lichtkegels sowie seine Ausrichtung handelt, und nicht um Eigenschaften der Lampe.

Ich persönlich finde dieses Tagging nun relativ klar und halte es für eine Verbesserung gegenüber meinem bisherigen Proposal. Insbesondere räumt es Missverständnisse zwischen lamp und light aus dem Weg und fasst zwei Tags zu einem zusammen, macht das Tagging in der Praxis also einfacher.

Allerdings ist es auch ein größerer Schritt, einen neuen Primärkey light_source=* vorzuschlagen, und ich bin mir nicht sicher, wie die Meinungen und Reaktionen dazu sind. Deshalb wäre ich für jeden Kommentar und jede Meinung dankbar.

Sollte sich tatsächlich eine Mehrheit dafür finden, würde ich das Proposal entsprechend überarbeiten und zugleich “aufräumen”, d.h. weiter vereinfachen. Kernpunkt des Proposals wird dann light_source=* sein. Alles, was optional ist, wird dann als mögliche Ergänzung / Erweiterung ausgelagert.

Hallo

Bitte mache für den neuen Vorschlag eine neue Seite auf.
Die Seite des ‘alten’ Vorschlags kannst du in “Proposed_features/lamp (archived)” (oder so ähnlich) umbenennen, wenn dir das sinnvoll erscheint. So wird sofort klar, dass der ‘alte’ Vorschlag nicht mehr aktiv ist.

Edbert (EvanE)

Es ist ja erst einmal nur eine Idee, und bevor ich überhaupt irgendetwas in der Richtung mache, würde mich interessieren, ob das überhaupt sinnvoll erscheint oder nicht.

Moin,

ich finde das einstufige “light_source” besser als “lamp” mit “lamp:type”.

Anflug- und Pistenbefeuerung von Flughäfen und Hindernisbeleuchtung für die Luftfahrt (rote Lichter, Blitzlichter) würde ich nicht unter “light_source” sondern eher unter “aeroway / aviation” einordnen, ähnlich wie Leuchttürme und beleuchtete Seezeichen ein “seamark”-Tag bekommen.

Alle Arten von Signallampen/Lichtzeichen/Ampeln für Straßenverkehr, Bahn, Seefahrt und Luftfahrt würde ich nicht als “light_source” einordnen.

Für den Anwender ist es egal, ob Straßenlampen als “highway=street_lamp” oder “light_source=lantern” in der Datenbank stehen.
Ein langfristiger Parallelbetrieb führt zu Frust, Mehrarbeit und Verwirrung bei allen Aktiven.
Für eine Umstellung braucht man eine überzeugende Mehrheit.

Grundsätzlich finde ich es wichtiger am Objekt (Straße, Sportplatz, Gebäude, …) zu erfassen, ob es (zeitweise) beleuchtet ist, denn die Lichtquelle als Objekt zu modellieren.

Ja, das halte ich auch für sinnvoll. Ich habe inzwischen auch schon Ansätze für so ein Tagging gefunden.

+1