[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