Wiki hin - Wiki her. Ich halte das aufgrund der völligen Unwartbarkeit/Unzuverlässigkeit von Sammelrelationen für den falschen Weg.
aus der -vorerst- letzten Diskussion zu SR: http://forum.openstreetmap.org/viewtopic.php?pid=355924#p355924
Meine Bitte gilt auch für sich. Einen gangbaren OSM-konformen Weg habe ich ja schon vorgeschlagen - wobei ich bei Straßen auch Probleme sehe. (*)
Gruss
walter
*) da fahre ich gerade mal eine Auswertung aus meiner DB
Ich würde auch nicht die Wiki-Artikeln des Namensgebers der Straße bei der Straße eintragen, denn dort gehört ein Wiki-Artikel nur hin, wenn er über die Straße selbst ist.
Ein Tag “namesake” (Wörterbuch, keine Ahnung ob die richtige Übersetzung) finde ich da weitaus zielführender, da es speziell auch durch Anfänger getagged werden kann. Die Sammelrelation für eine bestimmte Person zu suchen, ist vermutlich für 90% der Bearbeiter zu aufwendig.
Zu der Relation (gestreckt wegen der Lesbarkeit):
Proposal gab es dazu wohl keine?
1566 Relation beinhalten 1678 Members, das heißt, dass mindestens 1454 Relationen sozusagen “wertlos” sind und genausogut durch ein Tag ersetzbar wären
1285 der 1566 kommen aus Polen (über 80%) (handvoll User, Massenedit?) z.B.: http://www.openstreetmap.org/browse/changeset/13556132
der Großteil der Informationen besteht aus Geburts- und Sterbetag, welche in einer geografischen Datenbank nicht wirklich gefragt sind.
“Friedhofmapping” von vermutlich unbekannten Personen z.B.: http://www.openstreetmap.org/browse/relation/2501950 ?!
Wollte ich ja auch nicht. Der Wiki-Link zur Straße, falls es den mal gibt, soll natürlich erhalten bleiben. Nur irgend ein zusätzlicher Verweis auf den Namensgeber erschien mir sinnvoll.
jo, so ginge es auch.
Gruss
walter
Nicht alles, was im Wiki steht, ist sinnvoll. Zugegebenermaßen ist es für einen Anfänger praktisch unmöglich, Unfug als solchen zu erkennen. Insofern ist es nicht Dein Fehler, sondern der Fehler desjenigen, der sich diesen stumpfsinnigen Relationstyp ausgedacht hat.
Jimmy_K hat dazu ja bereits einiges angemerkt, aber hier noch einmal etwas detaillierter. Schauen wir uns einmal an, wer diese 1576 Relationen erstellt hat (also nicht der letzte Bearbeiter, sondern der Autor von Version 1):
765 Zbigniew_Czernik
293 piottr
221 Władysław Komorek
81 marimil
75 Yarl
34 Dotevo
30 rewelator
24 kietlak
12 TimeJourney
sowie 16 weitere mit 1-9 erstellten Relationen
Knapp die Hälfte der Relationen stammt also vom Autor der Wiki-Seite, ein weiteres Drittel von zwei weiteren Personen. Das läßt nicht wirklich auf eine breite Akzeptanz schließen.
Sehen wir uns ferner einmal die Größe der vorhandenen Relationen an. Erste Spalte: Anzahl der Mitglieder, zweite Spalte: Häufigkeit.
0 160
1 1387
2 17
3 1
7 1
10 2
13 2
30 1
32 1
33 1
151 1
224 1
598 1
10% der Relationen sind also leer (157 von 160 stammen vom User piottr, der sie offenbar in v1 nichtleer erstellt und anschließend leergeräumt hat: vielleicht ist er zur Vernunft gekommen und wollte den Quatsch wieder löschen?), 88% enthalten genau ein Element. Genau 12 Relationen (<1%), im wesentlichen die jüngst von Dir erstellten, enthalten mehr als zwei Elemente.
Und zum Beispiel bei den 143 Friedrich-Ebert-Plätzen, die Du in die entsprechende Relation gepackt hast, hast Du selbst nachgeprüft, daß nicht der eine oder andere Namensvetter dabei ist? Ebenso bei den 556 Karl-Liebknecht-Straßen, 21 Karl-Liebknecht-Plätzen, 17 Karl-Liebknecht-Ringen usw.? Sehr beeindruckend; verrätst Du uns, wie?
Argumente, warum solche Daten in der OSM-Datenbank nichts zu suchen haben, wurden ja bereits genug genannt. Um zu illustrieren, wie bei “konsequentem” Einsatz von person-Relationen der Datenbestand (völlig unnütz) aufgebläht und Bearbeitungen erschwert würden, noch ein paar Zahlenbeispiele. Die Auswertung habe ich vor einem halben Jahr gefahren, die Zahlen sind also eher noch zu klein (beispielsweise gibt es in meiner Auswertung nur 131 Friedrich-Ebert-Plätze, nicht 143). Abgesehen davon zeigen die Zahlen auch die praktische Unmöglichkeit auf, solche Relationen zu pflegen.
Neben den Friedrich-Ebert-Plätzen gibt es in DE noch 1826+ Friedrich-Ebert-Straßen, 67+ Friedrich-Ebert-Alleen, 62+ Friedrich-Ebert-Ringe, 29+ Friedrich-Ebert-Anlagen, 21+ Friedrich-Ebert-Brücken, 15+ Friedrich-Ebert-Dämme, 6+ Friedrich-Ebert-Wälle sowie 6+ Friedrich-Ebert-Ufer, 5+ Friedrich-Ebert-Höfe, 4+ Friedrich-Ebert-Siedlungen und eine Reichspräsident-Ebert-Straße, diverse falsch geschriebene Varianten (u.a. Friedruch, Freidrich, Friedricht, Friederich, …) noch gar nicht mitgezählt. Von den 170+ Ebertstraßen, 44+ Ebertalleen, 28+ Ebertplätzen, 6+ Ebertringen, 2+ Ebertwegen, 2+ Ebertpassagen sowie je eine Obere und Untere Ebertstraße dürfte ein guter Teil auf den alten Ersatzkaiser zurückgehen. Die möchtest Du alle im einzelnen prüfen? Viel Spaß, aber bitte verzichte auf person-Relationen. Die muß dann jeder ungewollt mitbearbeiten, der z.B. eine darin enthaltene Straße teilt - und wieder eine neue Version einer Relation mit O(2500) Elementen anlegen.
Das willkürlich herausgegriffene Beispiel Friedrich-Ebert-.* ist dabei übrigens noch nicht das größte Übel. Die (nach Anzahl der OSM-Wege) häufigsten Straßennamen, die sich offenkundig auf Personen beziehen, sind (wenig überraschen) Schillerstraße (3518+), Goethestraße (3412+) und Jahnstraße (3250+), zu denen es natürlich allerlei Varianten mit einem oder mehreren sowie ohne Vornamen und/oder Adelstitel und verschiedene Namenssuffixe wie Straße/Platz/Ring/Allee/Weg/Promenade/Brücke/Gasse/Höhe/Berg/Steig gibt. Richtig spannend wird es etwa bei “Bachstraße” (2550+).
Wie wäre es mit einer Sammelrelation für “Hauptstraße” 
http://de.wikipedia.org/wiki/Haupt
:duckundweg:
Das ewig gleiche Muster: der User ist weg, der Datenmüll bleibt.
Hallo,
ich häng’s mal hier an.
Zur Zeit läuft das Voting für ein Sammelrelations-Proposal. Bitte helft mit, es abzulehnen. Ich habe schon meine gesammelten Gegenargumente dort geäußert:
Es gibt Nominatim und Overpass API.
Die Daten gehören in eine OpenPersonDB.
Es kann uns in Konflikt mit Persönlichkeitsrechten und Datenschutz bringen.
Es kann uns bzw. der armen DWG Probleme mit dem Recht auf Vergessenwerden bringen.
Sammelrelationen sind in OSM unerwünscht. Zur Vermeidung siehe 1. Alternativ bitte Wikipedia verwenden.
Ich würde mich nicht davor scheuen, solchen Datenmüll zu löschen.
Viele Grüße
Michael
abgelehnt… (das Proposal natürlich)
Sven
Danke für den Hinweis. 
Ich halte auch nichts davon (weil es für mich nicht nach OSM gehört). Aber es ist nmM keine Sammelrelation, sondern eine Klasse/eine Kategorie/ein Konzept “Person”, das durch eine OSM-“Relation” instanziiert wird.
Ach, der Quatsch! Das Zeug hatten wir doch schon drin - und rausgeschmissen.
Wenn noch Argumente braucht:
Danke und Gruss
walter
Ich übersetze hier die Argumetation der Verfasser auf Bitte von Zbigniew Czernik:
Nutzt die “Personendatenbanken” - https://de.wikipedia.org/wiki/Genealogie-Datenbank - und dort die Koordinatenerfassen der Grabstelle, Geburtstort, Schulort, Wohnort - als Layer
Hab keine Karten im Spiel: Könnt Ihr bitte die Alternativen bzw. Argumente für bzw. gegen in diesem Thread auf english posten:
http://forum.openstreetmap.org/viewtopic.php?id=27304
Viele Grüße,
Marek
Wie gebe ich meine Stimme ein ? (angemeldet bin ich)
Muß ich Voting bearbeiten aufrufen oder gibt es irgendwo eine Schaltfläche zum anklicken, die ich übersehen habe ?
Gruß
Peter
Indem Du den Wiki-Eintrag bearbeitest und {{vote|no}} einfügst.
done
Gruß
Peter
Genauso wie bei mehrern Objekten in einem Building: Mehrere POI
hier mit ref=.
Gruss
walter
Hallo Marek,
ich habe mal etwas ausführlicher als in meinem Voting meine Vorbehalte gegen Sammelrelationen und das Eintragen von Personen im polnischen Forum geäußert und um Alternativvorschläge (siehe unten) ergänzt.
Das hat man bei Stolperstein-Relationen auch gesagt (naja, nicht ganz)
Wenn das Grab als Node oder Fläche (sei es ein in sich geschlossener Way oder ein Multipolygon)
cementary = grave
grave:inside = Joe Average (1920-08-04 to 2001-01-15); Maria Average (1919-11-02 to 2009-02-27)
grave:ontop = nice flowers 
Oder wenn man stattdessen nur den Grabstein mappt, weil die genauen Ausmaße des Grabs nicht erkennbar sind.
historic=tombstone
inscription:machine-parsable=Joe Average (1920-08-04 to 2001-01-15); Maria Average (1919-11-02 to 2009-02-27)
Ich denke, dass Geburtsorte nur gemappt gehören, wenn sie entweder von innen (z.B. Schild in der Eingangshalle) oder außen mit Schildern wie “Geburtshaus von Theodor Heuss” [1] gekennzeichnet sind. Für Gräber ist die An-das-Grab-Taggen-Methode noch praktikabel (bei Massengräbern sind die dort Vergrabenen meistens nicht namentlich bekannt?), bei Gebäuden (erst recht bei Krankenhäusern) ist das jedoch nicht mehr editierbar (ohne Plugin). Aber man sieht ja selten ein Gebäude, mit einer riesigen Tafel aller hier Geborenen.
Für eine Verbindung von Geburtsort und Liegeplatz kann man dann die Overpass-API bemühen, wenn es eine berühmte Person ist. Für weniger berühmte Personen oder Personen, auf die der Hausbesitzer bzw. die Gemeinde nicht stolz ist, kann man diese Information in einer OpenGenDB mit Geokoordinate oder Adresse lagern. Verwandschaftsgrade haben in OSM nichts zu suchen (daran stören sich wohl die meisten und lehnen das Proposal deshalb ab).
Viele Grüße
Michael
[1] Wurde in den 1950er-Jahren mit seiner Erlaubnis abgerissen, dann einen Kelter gebaute, die jetzt das Stadtarchiv beherbergt.
so wie ich das sehe, ist das Proposal vorzeitig beendet und mit abgelehnt markiert worden:
Sven