[Talk-de] Stolpersteine - Vollständigkeitsauswertung

Frederik Ramm frederik at remote.org
Mo Mai 17 08:07:34 UTC 2010


Hallo,

Andre Joost wrote:
>>> - und das über die ganze Welt verteilt. Die Info kann man dann aber
>>> genauso gut über Datenbankabfragen (z.B. XAPI) abholen.
> 
> genauso gut nicht, weil man mit der XAPI neben der bounding box nur 
> genau ein Kriterium abfragen kann.

Fuer den konkreten vorliegenden Fall trifft "genauso gut" aber zu.

> Und wie verträgt sich das mit dem immer gern vorgetragenen Chaos-Prinzip 
> von OSM?

Eben gar nicht. Relationen, bei denen man erwartet, dass jeder, der ein 
Objekt erfasst, es auch in diese Relation eintraegt, damit man es 
spaeter leichter findet, widersprechen dem Chaosprinzip ;-)

Grundsaetzlich sind Mapper bei uns eine knappe Ressource, wir sollten 
also dem Mapper so wenig wie moeglich Arbeit aufbuerden, und einen 
Stolperstein einfach als solchen zu taggen und es dem Suchenden zu 
ueberlassen, was er suchen will, ist sicherlich leichter als sich erst 
einmal zu informieren, in welche Relationen ein Stolperstein aufzunehmen 
ist, diese herunterzuladen und zu ergaenzen.

Sowas kann man machen, wenn es aus technischen Gruenden nicht anders 
geht, aber in den meisten Faellen, wo Relationen als Kategorien 
missbraucht werden, ist es unnoetig.

>> Zugegeben: Es ist derzeit leichter, alle Haeuser von Hundertwasser
>> runterzuladen, wenn es so eine Relation gibt, weil man dann die XAPI
>> nicht braucht, aber wir sollten nicht anfangen, unsere Datenbank mit
>> Zugriffs-Vereinfachungen zuzupflastern
> 
> Ja stimmt, bei inzwischen fast 1 Million Relationen tut eine für 
> Stolpersteine in der Tat weh :-(

Jeder, der einen Stolperstein hinzufuegt oder entfernt, hat durch diese 
Relation mehr Arbeit, und jeder, der einen Stolperstein herunterlaedt, 
bekommt die Relation mit allen Stolpersteinen (oder ggf. die mit allen 
in seinem Ort) aufs Auge gedrueckt. Darum geht es, nicht um einen 
zusaetzlichen Eintrag in der Datenbank.

> Und warum soll man sich das Arbeiten an OSM nicht durch hierarchische 
> Relationen vereinfachen, auch und weil wenn es kein Renderer auswertet?

Das Arbeiten an OSM wird dadurch erschwert. Vereinfacht wird lediglich 
der Zugriff. Jede Huerde, die wir fuer potentielle Mitarbeiter aufbauen, 
schadet uns.

> Oder die Wanderwege (oder Buslinien oder Hochspannungsleitungen oder 
> ...) des Vereins A sich mit den Wanderwegen des Vereins B räumlich 
> vermischen, man aber speziell nur die des Vereins A haben möchte.

Wanderwege und Buslinien sind in der Regel eh als eigene Relation 
gemappt. Die Wanderweg-Relation hat dann ein Tag "operator=Alpenverein" 
oder sowas. Dafuer braucht man keine Extra-Relation "Wanderwege des 
Alpenvereins". Das gleiche gilt fuer Buslinien oder 
Hochspannungsleitungen. Ob nebendran noch andere Wanderwege anderer 
Vereine verlaufen, spielt keine Rolle, denn diese werden eigene 
Relationen haben.

Ein Problem gaebe es dann, wenn derselbe Wanderweg von zwei Vereinen 
zugleich betrieben wuerde (und damit ist *nicht* gemeint, dass zwei 
verschiedene Wanderwege sich einen Waldweg teilen), dann muesste man, um 
ein "operator=Alpenverein;Wandervoegel" zu vermeiden, eine Relation fuer 
Alpenverein-Wanderwege und eine fuer Wandervoegel-Wanderwege haben.

Bye
Frederik




Mehr Informationen über die Mailingliste Talk-de