Obwohl ich sicher eine PostGIS DB installieren kann auf Linux oder Windows, ist das fuer mich viel Aufwand, nur zum bestimmen ob etwas in etwas anderes liegt. Auf Android gelingt das schon nicht mehr. Da bin ich dann froh wenn ich sowas nur abfragen kann mittels eine Relation.
Auch um Daten, die hierarchisch eingetragen sind (ich denke jetzt an Collections von Netzwerke von Routes), herunterzuladen mit der Overpass API sind Relationen unschatzbar wertvoll. Polyglot 2012/7/9 Sarah Hoffmann <lon...@denofr.de> > On Mon, Jul 09, 2012 at 01:20:51PM +0200, Frederik Ramm wrote: > > Bei Relationen ist wenigstens ein generischer Support moeglich - > > gaengie Editoren koennen Dir wenigstens sagen, dass da eine Relation > > ist, selbst wenn sie nicht wissen, was sie bedeutet. Aber wenn im > > XML halt ploetzlich ein <area> oder <route> oder <turnrestriction> > > auftaucht, fliegt Dir der XML-Parser entweder um die Ohren oder > > schmeisst das Ding ganz weg. > > > > Eventuell sollte man alle diese neuen Datentypen dann in irgendwas > > gleichartiges kapseln, so dass eine Software, die den Datentyp nicht > > versteht, nicht total aufgeschmissen ist *duck* > > Genau aus diesem Grund finde ich Relationen so wie sie sind eigentlich > eine geniale Idee, einfach und flexibel. (Aauch in der Verarbeitung, > wenn man sich mal eine Minute von osm2pgsql lösen kann.) > > Wir haben mit Relationen keine technisches Problem sondern > ein menschliches. Ein paar Powermapper meinen, dass jede Beziehung > von Objekten in der DB explizit mit Relationen modeliert werden müsse > und treten dabei dei eigentliche Idee von OSM mit Füssen, nämlich > dass OSM eine spatiale DB ist und keine relationale. > Anstatt also zu überlegen, was man den Leuten alles > verbieten müsste, sollten wir die Mapper besser darüber aufklären, > warum ihre Relationsmania überflüssig und gefährlich ist. > > Jans Frage am Anfang dieses Threads macht insofern überhaupt keinen > Sinn. Es ist komplett irrelevant, wie leicht oder schwer eine > Relation zu verarbeiten ist. Die einzige Frage, die er sich stellen > sollte ist die: ist die Relation wirklich nötig oder ist es möglich, > meine Information auch in Form von einfachen Tags und geografischen > Beziehungen in der DB unterzubringen. Die Antwort auf diese Frage > ist eindeutig, dass es möglich ist, und damit sollte die Sache > erledigt sein. > > Ähnliches gilt für Anwendungen, die hier in letzter Zeit diskutiert > wurden. (Ich denke mit Schaudern an den Thread zum Eisenbahn-Tagging.) > Redundanz ist kein Argument für Relationen. "Ich weiss nicht, wie man > es anders in einer spatialen Datenbank verarbeiten kann" ist kein Argument > für Relationen. "Ich kann die Daten so leichter runterladen" ist kein > Argument für Relationen. Das einzige relevante Argument ist: es geht nicht > anders[1]. Und das sollten wir allen Mappern klar machen. Wie es > eine ungeschriebene "on the ground"-Regel gibt, sollten wir eine > "vermeide Relationen"-Regel einführen und so oft wie möglich zitieren. > > Wenn wir es schaffen mehr Selbstdisziplin zu üben und Relationen auf > eine Handvoll klar definierter Anwendungsfälle zu begrenzen, braucht > es keine Änderung an der API. > > Gruss > > Sarah > > [1] Und bevor man mich jetzt zu sehr beim Wort nimmt: das schliesst > auch die Fälle ein, wo es zwar anders ginge, aber nur von hinten > durch die Brust etc. > > _______________________________________________ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
