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 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de