Re: Rendering der Stolpersteine

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.