Rendering der Stolpersteine

wambacher · 2013-10-13 09:23:52

openzzz wrote:

Google ist zwar auch gut, kommt aber beim Datenumfang nicht an OSM heran. Lediglich die Verlinkung dort ist besser gelöst, wo man auf Mausklick weitere Informationen zum POI bekommt, z.B. Tel., Homepage, Foto.

Klar, weil an genau dieser Stelle die Registrierkasse von Google klingelt. Jeder Klick auf einen POI kann Kohle bringen.

Ich könnte mir gut vorstellen, die OSM-Daten in zwei unabhängige Teile zu spalten, die Karte an sich und eine POI-Sammlung.

Wenn wir mehr als eine DB haben wollten, müssten wir erst das Problem die Verlinkung lösen:
Objekte in OSM haben eine ID, die sich jederzeit ändern kann. Wenn die ID als Link zwischen den beiden DB genommen wird und jetzt ein POI gelöscht/neu angelegt wird (*) , ist plötzlich die Verknüpfung futsch. Ansätze, OSM-Objekten zusätzlich eine unveränderliche UUID zu geben, sind gescheitert. Wenn ein Mapper ein Objekt löscht und danach neu einträgt, kann ihn niemand "zwingen", die UUID des alten Objektes mitzuschleppen. Und schon sind die erweiterten Informationen verloren.

Für einen Restaurantführer (POI auf Karte oder in Suchfunktion) wäre es günstiger eine einheitliche Kodierung zu finden. Eigentlich reicht ja eine Koordinate pro POI. Die konkrete Hausform ist nur für die Kartenzeichnung relevant.

Das ist wohl nur eine Frage der Abfrage. POI können ja Nodes sein oder sich in Ways/Relationen verstecken. Eventuell könnte man dazu die API aufbohren sodaß nicht jeder Entwickler das Rad ("wie finde ich meine POI?") neu erfinden muß. Gut sehen kann man das ja bei der zunehmenden Verwendung der Overpass-API. Dort werden derzeit ja die Techniken mit dem UNION-Befehl propagiert. In SQL gibt es das schon lange aber es ist dennoch äußerst lästig, bei jeder Query alle drei Objekttypen abfragen zu müssen. Performant ist das auch nicht gerade.

Gruss
walter

*) Das geschieht häufig wenn die Daten eines POI-Nodes an den Way des Buildings oder gar an die Relation einer Site geschoben werden. Node weg -> ID weg -> Link weg -> Daten weg

okilimu · 2013-10-13 09:58:01

Hallo openzzz,

openzzz wrote:

Apropos Erinnerung:
Im Pflaster erfüllen die Stolpersteine durchaus ihren Zweck:
http://www.youtube.com/watch?v=LuBv9rDhV_4

Danke für den Link

openzzz wrote:

Ansonsten finde ich weniger Begeisterung daran, würde sie also nicht
anhand eines Stadtplans gezielt aufsuchen. Dafür erzählen sie einfach zu wenig.

Zum einen ist die Beschäftigung mit dem Thema allgemein und die Aufarbeitung konkret für die Opfer eine wichtige Arbeit und da machen auch viele Schulen mit.

Zum anderen ist es natürlich wichtig, das das sehen eines Steins neugierig machen soll und man in Zukunft leichter zu weiteren Infos kommen kann. Es gibt schon mehrere Apps zum Thema, die meines Wissens nach derzeit aber immer nur die Geschichte einer Stadt (Berlin) oder evtl. eines größeren Umfelds (im Saarland) unterstützen.

Wir (einige bei OSM) versuchen auch gerade, die weiteren Infos bereitzustellen. Das kann so erfolgen, das wir die Links auf im Netz vorhandene Biografien ergänzen oder evtl. auch eine zentrale Biografiesammlung bereitstellen. Das ist aber noch im frühnen Planungszustand.

openzzz wrote:

Wer sich wirklich erinnern will, sollte vielleicht das Tagebuch lesen,
oder die gelungene filmische Umsetzung anschauen:
https://www.youtube.com/watch?v=dBXV33g7Uag
Und was viele nicht wissen, es gibt auch eine polnische Variante:
https://www.youtube.com/watch?v=XwhkbkP2L_A
Das ist erinnern, das brennt sich ins Gedächtnis wie kein Stein im Pflaster.

Wenn jemand eine Stolpersteinverlegung mitmacht, ist das auch prägend. Da sind öfters Schulklassen dabei und ich habe schon Nachkommen der Opfer gesehen, die aus den USA oder Israel nur zur Verlegung angeflogen kamen.

Es gibt Einzelschicksale, die aufbereitet wurden und sehr eindringlich sind. Auf der anderen Seite gibt es die immensen Opferzahlen, die kaum fassbar sind.

Die Stolpersteine versuchen die Verbindung herzustellen. Ich finde, das klappt in einem Ort auch ganz gut.

Was mir fehlt, ist die Darstellung des Gesamt "Kunstwerks" (für mich ist es eher ein Erinnerungswerk). Da können wir gerade in OSM die ganze Bandbreite des Werks zeigen. Im Ort die verlegten Steine, vor welchen Gebäuden bin hin komplett herausgezoomt das die in 16 Ländern verlegt sind (wenn wir sie mal in OSM haben).

Viele Grüße

Dietmar

openzzz · 2013-10-13 16:12:59

wambacher wrote:

Wenn wir mehr als eine DB haben wollten, müssten wir erst das Problem die Verlinkung lösen:
Objekte in OSM haben eine ID, die sich jederzeit ändern kann. Wenn die ID als Link zwischen den beiden DB genommen wird und jetzt ein POI gelöscht/neu angelegt wird (*) ...
*) Das geschieht häufig wenn die Daten eines POI-Nodes an den Way des Buildings oder gar an die Relation einer Site geschoben werden. Node weg -> ID weg -> Link weg -> Daten weg

Traditionell ist ein POI in GPS-Anwendungen einfach nur ein Punkt, d.h. eine WGS84-Koordinate, wie schon der Name "point" of interest sagt. So gesehen besteht dann gar nicht die Notwendigkeit der Verlinkung. Solche Datenbanken könnte man dann unabhängig voneinander führen, separat überlagern, in der Karte auch aus unterschiedlichen Resourcen zusammenführen. Da gibt's ja auch schon viele POI-Sammlungen, z.b. die beliebten "Blitzer-POI".

Davon habe ich selbst sehr viele, Tankstellen-POI, Campingplatz-POI etc. Die werden üblicherweise als ASCII-Koordinatenlisten (CSV) geführt. Sehr schön, man kann diese Dateien beliebig hin- und herkopieren. Es gibt viele Public-Domain Sammlungen. Und über Konverter können solche POI auch in die kommerziellen Auto-Navigationssysteme eingespielt werden (TomTom, Navigon, GoPal, etc.). OSM-basierte Navis sind noch nicht so zuverlässig wie die Kommerziellen.

Bei OSM habe ich zum ersten Mal gesehen, dass auch anderen geometrischen Formen, z.B. einem Haus-Polygon, Eigenschaften wie Restaurant-Name etc. zugeschrieben werden. Prinzipiell Ok, aber jetzt haben wir damit ein Durcheinander von "echten" POI und Objekt-impliziten POI. Für die Systematik wäre es günstiger, man hätte die POI irgendwie einheitlicher. Auch für Mapper-Neulinge ist es verwirrend, ob man nun dem Haus die Restaurant-Daten hereinschreiben soll, oder dafür separat einen POI-Punkt überlagern soll.

Ich hab jetzt auch kein Patentrezept wie man das am besten löst. Man könnte auch sagen, die POI-Eigenschaften eines Restaurants kommen grundsätzlich in einen "POI-Punkt", den man über den Hausgrundriß legt. Das verlinkt dann die Daten noch nicht, aber über die Koordinate ist die Beziehung dann eigentlich klar. Ohnehin wäre es falsch, ein Haus mit mehreren Stockwerken und Restaurant im EG dann komplett mit den Restaurant-Daten zu markieren. Die "POI-Punkte" könnten komplett unabhängig von den anderen OSM-Kartendaten verwaltet werden. Unabhängigkeit schafft Vereinfachung. Vor allem lassen sich so auch unterschiedliche Projekte aus verschiedenen Internet-Quellen verheiraten. Beispielsweise könnte das Stolperstein-Projekt eine eigene Datenbank aufbauen und die entsprechenden POI einer Overlay-Layer zuführen, darin dann gleich die Freiheiten nutzen, die Daten beliebig zu strukturien, z.B. kurze Biographien der Personen mit einzuspeichern. Es würde die Verwaltung von OSM erheblich entlasten, wenn OSM quasi nur die Grundkarte bereitstellt und sich darum herum eine freie Infrastruktur an Overlays bilden kann. Das hindert auch keinen daran, fremde Daten auf der openstreetmap.org Homepage wieder als optionale Layer anzubieten.

Natürlich soll OSM auch weiterhin eine POI-Sammlung bleiben. Ich denke diese Vollständigkeit kommt gerade dadurch zustande, daß Leute auf der Karte ein POI vermissen, z.B. ein Restaurant, und dann einfach über den "Bearbeiten"-Knopf das nachtragen können. Die bisherigen freien POI-Sammlungen hatten nicht diese einfache und einladende Kollaborationsmöglichkeit. Wohl auch ein Grund, warum sie nie wirklich brauchbar wurden. Die Campingplatz-POI waren so unvollständig, dass man doch wieder einen Campingatlas kaufen musste, um keinen schönen Platz zu verpassen. Vollständigkeit haben die POI-Listen nur da bekommen, wo es systematische Sammel- oder Konvertieraktionen gab. Die Aldi-POI oder Aral-Tankstellen-POI kamen sicherlich aus einer anderen Datenbank und wurden vollständig umgesetzt. Da wo die POI einzeln zusammengetragen werden mussten kam dann auch nichts brauchbares zustande. OSM ist diesbezüglich wirklich revolutionär.

Tordanik · 2013-10-13 19:58:24

openzzz wrote:

Bei OSM habe ich zum ersten Mal gesehen, dass auch anderen geometrischen Formen, z.B. einem Haus-Polygon, Eigenschaften wie Restaurant-Name etc. zugeschrieben werden. Prinzipiell Ok, aber jetzt haben wir damit ein Durcheinander von "echten" POI und Objekt-impliziten POI. Für die Systematik wäre es günstiger, man hätte die POI irgendwie einheitlicher. Auch für Mapper-Neulinge ist es verwirrend, ob man nun dem Haus die Restaurant-Daten hereinschreiben soll, oder dafür separat einen POI-Punkt überlagern soll.

Eine solche Vereinheitlichung ist so oder so problematisch. Eigentlich sollten natürlich die meisten "POI" (im OSM-Kontext ist der Begriff natürlich verwirrend) bevorzugt als Fläche erfasst werden, nur ist der reine Punkt eben deutlich weniger Arbeit. Umgekehrt bei der Standardisierung auf einen Punkt würde man verschiedene Möglichkeiten zur Detailerfassung verlieren: Mehrere Eingänge beispielsweise, die Zuordnung mehrerer Gebäude zu einem größeren Gelände oder die Integration mit Indoor-Mapping.

Allgemein ist so etwas fast immer das Hindernis für verschiedene Datenbanken, Daten-Ebenen oder ähnliche Konzepte, bestimmte Daten gesondert abzulegen. Solang man mit einer einfachen Lösung zufrieden ist, scheint die Trennung möglich. Aber bestimmte Anwendungen brauchen dann eben doch wieder zusätzliche Details. Daher hat bisher das Auslagern nur dort geklappt, wo es existierende externe Datenbanken mit (relativ) stabilen IDs gibt.

Oli-Wan · 2013-10-13 22:02:45

Netzwolf wrote:

Du erinnerst mich daran, das ich noch die Wege auf dem Rhöndorfer Friedhof und bei der Gelegenheit das Adenauer-Grab erfassen will.

Bei der christdemokratischen Wallfahrtsstätte kommst Du ein Jahr zu spät. Das Tagging hat freilich keine sieben Stunden durchgehalten.
Aber an den Wegen kannst Du Dich noch austoben

Tordanik · 2013-10-13 22:20:15

Oli-Wan wrote:

Bei der christdemokratischen Wallfahrtsstätte kommst Du ein Jahr zu spät. Das Tagging hat freilich keine sieben Stunden durchgehalten.
Aber an den Wegen kannst Du Dich noch austoben

Also beim Grab kann man sich gern auch austoben und die Relation in die ewigen Jagdgründe schicken. Wir sind keine Personendatenbank.

Netzwolf · 2013-10-13 23:26:07

Nahmd,

Oli-Wan wrote:

Netzwolf wrote:
Du erinnerst mich daran, das ich noch die Wege auf dem Rhöndorfer Friedhof und bei der Gelegenheit das Adenauer-Grab erfassen will.
Bei der christdemokratischen Wallfahrtsstätte kommst Du ein Jahr zu spät.

Nicht wirklich. Zum einen sind die Koordinaten falsch (Node offensichtlich aus der Entfernung grob abgeworfen), zum anderen ist das ein historisches Objekt ohne Foto.

Das Tagging hat freilich keine sieben Stunden durchgehalten.
Aber an den Wegen kannst Du Dich noch austoben

Der Waldfriedhof ist (Überraschung!) dicht bewaldet und liegt in einem engen Tal, da dürfte der Empfang nicht wirklich gut sein.

Tordanik wrote:

Also beim Grab kann man sich gern auch austoben und die Relation in die ewigen Jagdgründe schicken. Wir sind keine Personendatenbank.

Auf Personenrelationen bin ich zum ersten Mal gestoßen, als ich beim Lesen des Planets die Schachteltiefe von Relationen untersucht habe (zur Zeit gibt es 7 auf Schachteltiefe 11, 0=Relation enthält keine Relation, 1=Relation enthält nur Relationen, die keine Relationen enthalten, usw.) und dabei auf zyklische Relationen gestoßen bin: durch Relationsmembers ausgedrückte Verwandschaftsverhältnisse: A = Vater/Mutter/Elter von B, B = Sohn/Tochter/Kind von A.

Die Relation hier ist sinnlos, beeinträchtigt aber die Funktion der OSM-DB nicht. Also mag wer auch immer die löschen, ich tu's nicht.

Gruß Wolf

PS: falls jemand neugierig ist: das sind die 7 Relationen auf Level 11:

- 420339
- 420344
- 420345
- 420346
- 420348
- 420349
- 1524411

Und falls jemand Langeweile hat: das sind die zyklisch verknüpften Relationen:

- 285836
- 1085634
- 1154653
- 1205072
- 1368401
- 1543698
- 1750007
- 2132897
- 2133498
- 2431858
- 2431861
- 2435464
- 2579600
- 2718415
- 2813982
- 2885227
- 2990554
- 3018045
- 3018206
- 3047822
- 3119737
- 3120098
- 3122622
- 3122640
- 3170559
- 3187114
- 3208182
- 3228416
- 3253167
- 3256779
- 359309
- 3236785

Oli-Wan · 2013-10-13 23:30:32

Tordanik wrote:

Also beim Grab kann man sich gern auch austoben und die Relation in die ewigen Jagdgründe schicken. Wir sind keine Personendatenbank.

Von mir aus gerne. Ich hatte damals keine Lust, mich mit dem Massenumtagger zu streiten, erst recht zumal ich in der Gegend auch nur zu Besuch war. Wie neulich bereits festgestellt, scheint Zbigniew_Czernik an seiner (sinnfreien) Schöpfung zu hängen.

Netzwolf wrote:

Der Waldfriedhof ist (Überraschung!) dicht bewaldet und liegt in einem engen Tal, da dürfte der Empfang nicht wirklich gut sein.

Ist mir noch in Erinnerung, danke.

Announcement

#26 2013-10-13 09:23:52

Re: Rendering der Stolpersteine

#27 2013-10-13 09:58:01

Re: Rendering der Stolpersteine

#28 2013-10-13 16:12:59

Re: Rendering der Stolpersteine

#29 2013-10-13 19:58:24

Re: Rendering der Stolpersteine

#30 2013-10-13 22:02:45

Re: Rendering der Stolpersteine

#31 2013-10-13 22:20:15

Re: Rendering der Stolpersteine

#32 2013-10-13 23:26:07

Re: Rendering der Stolpersteine

#33 2013-10-13 23:30:32

Re: Rendering der Stolpersteine

Board footer