Hi,
wenn ich das wiki richtig verstanden habe, gehört ein highway=*** oder ein waterway=river usw. nicht an die route-Relation. Wäre dann ja doppelt.
Richtig oder nicht?
Vor allem wäre es nicht eindeutig. Denn eine Bundesstraße (nur um mal ein Beispiel zu nennen) kann in ihrem Verlauf auch autobahnähnlich ausgebaut sein. Man kann aber eine Relation nicht gleichzeitig als highway=primary und highway=trunk taggen; das geht nur, wenn man die Tags auf die einzelnen Ways packt.
Richtig. An solchen Relationen gehören nur Tags, die die gesamte Relation betreffen. Straßen: ref=* (Bundes- Landes-, Kreisstraßennummer) Bei Fließgewässern wäre es Fließgewässerkennzahl. Selbst Namen gehören (logischerweise) ans Objekt.
Sven
Bedauer ich es wenn ich fragen würde, was die Fließgewässerkennzahl ist?
Da ist meine Logik zu Ende. 
Warum soll ein Name an das Objekt und nicht in die Relation? Bei einem Fluss bspw. ändert der sich ja doch eher selten unterwegs…
Selten… das ist das richtige Wort… Manchmal ändern sie aber duch ihren Namen…
Vergleiche: http://de.wikipedia.org/wiki/Uecker In Brandenburg heißt der Fluß Ucker, in Mecklenburg-VP Uecker
Ansonsten haben wir im Spreewald auch komische Namensgeschichten an Gewässern…
Na und beim Straßennamen dürfte es klar sein…
Sven
Ja ok, wenn sich der Name der Objekte in der Relation unterscheiden, dann kann der natürlich nicht in die Relation. Aber wenn die Objekte in der Relation alle den gleichen Namen haben, dann spricht doch nichts dagegen, den Namen in die Relation zu nehmen. Oder?
Im Prinzip nicht. Eine Weiterverarbeitung der erstellten Geodaten wird aber erleichtert, je mehr Informationen am Objekt erfasst sind.
Sven
Wenn das der Fall ist wär’s ja eine Sammelrelation, die bekanntlich nicht erwünscht sind. 
Wären dann hier nicht 3 Relationen sinnvoll? Eine für alle Abschnitte “Ucker”, eine für alle Abschnitte mit “Uecker” und eine mit allen Abschnitten für die Flussnummer.
Ich finde sowas unnötig. Name ans Objekt, Flusnummer an die Relation.
Wenn man das alles in Teilrelationen aufteilen wollte, müsste für die Spree diverse Teil-Relationen erstellen, wo nachher keiner mehr durchblickt. Namen muß man dann trotzdem ans Objekt setzen, da gerade im Spreewald eine Gewässer oft mehr als einen Namen hat…
Einfacher ist da besser.
Warum macht man hier eigentlich eine Relation? Meiner Ansicht nach nur, um das Gewässer als Ganzes zu identifizieren. Mehr nicht. Prinzipiell ist selbst eine Relation nicht mal nötig, denn die Flußnummer kann auch ans Objekt… und mittels Merge (oder einer Abfrage) über die Flußnummer hätte man wieder alles Objekte.
Mit einer Relation hat man allerdings das Gewässer besser im Blick… Ähnlich wie bei den Straßen und dem Abarbeiten von fehlenden Tags…
Sven
Gerade bei mehreren Namen bieten sich Relationen doch an, weil am Weg nur ein Name stehen kann.
Um es mal etwas weiter zu treiben: Ich wäre generell dafür, nur physische Eigenschaften an Knoten und Wege zu packen. Alle nichtgegenständlichen Eigenschaften sollte dann in Relationen erfasst werden.
Wird das dann auch interpretiert, wenn z. B. das ref einer Straße nur in der Relation eingetragen ist? Bappt der Renderer dann das ref an die einzelnen Mitglieder der Relation?
Noch fehlen leider sehr viele route-Relationen, aber es sollte nicht schwer sein, diese zu vervollständigen. Nur bei den teilweise sehr zahlreichen Kreisstraßen wird das eine schier endlose Arbeit.
Ooch… da gibt es genung Möglichleiten: alt_name, loc_name, hist_name… Es ist ja ein und der selbe Gewässerlauf, der mehrere Namen hat… Nö… Je mehr Relationen an ein Objekt verbastelt werden, desto komplizierter und unübersichtlicher wird das Ganze. Einfacher ist besser. Je mehr an Relationen gepackt wird, desto schwieriger wird die Auswertung der Daten.
Bei Gewässern würde ich mir eine Rendering des Wertes im “alt_name” in Klammern hinter dem Namens-Tag wünschen.
Was sind bei dir gegenständliche und nichtgegenständliche Eigenschaften?
Access-Tags sind nichtgegenständliche Eigenschaften. Access-Tags beschreiben kein Objekt, sondern diese bilden Rechte am Objekt, an einer Sache ab. Wie wiillst du denn die Motorboot-Erlaubnis (z.B. nur Bergfahrt) eines Gewässersabschnittes in einer Relation abbilden? Das geht nicht. Das gehört alles ans Objekt: z.B. Befahrung mit Motorboot: motorboat=backward an den entsprechenden Gewässerabschnitt.
Sven
Das sehe ich genau umgekehrt. je mehr tags an den Wegen sind, umso unübersichtlicher wird es, da die Datenflut weitaus größer ist. Stelle die nur mal vor, es gäbe z.B. keine Wanderwegsrelationen, was da an tags an die Wege geklebt werden müsste, wenn mehrere Routen auf dem gleichen Weg verlaufen.
Weiterhin wird die Wartung vereinfacht. Ändert sich z.B. der Name einer Straße, müssen alle Abschnitte aufwendig geändert werden. Bei einer Relation reicht es, dieses zu Bearbeiten, d.h. es muss genau eine Änderung vorgenommen werden.
Die Auswertung ist auch nicht weiter schlimm, da Relationen ja alle benötigten Objekte enthalten. Ich finde die Auswertung ohne Relationen weitaus aufwendiger, da man prüfen muss, ob man tatsächlich nur die Objekte erwischt, die man auch tatsächlich will.
Bleiben wir mal bei Straßen:
Straßenbreite, Oberfläche, tracktype, Brückenhöhe usw sind gegenständliche Eigenschaften. Ich würde hier sogar Geschwindigkeitsbegrenzungen dazu zählen.
Name und ref hingegen sind nichtgegenständlich, eigentlich sind sie nur eine Ansammlung von Wegabschnitten, die zusammengehören, also eine Relation.
Man könnte es auch so formulieren: Alle Attribute, die für alle Abschnitte gelten, kommen an die Relation, alle die nicht für alle gelten an die jeweiligen Wege.
access-tags könnten tatsächlich direkt an den Weg, wobei natürlich auch Relationen in Frage kommen würden. Abbiegebeschränkungen sind ja auch Relationen, weil sie direkt am Weg keinen Sinn machen. Für die Richtung z.B. gibt es die forward/backward Rolle. Hier müsste man also entscheiden, was sinnvoller ist.
Ich habe ehrlich gesagt manchmal das Gefühl, wir machen uns hier wegen der Angst vor Relationen alles unnötig schwieriger, als es ist.
Relationen sind aber in der Tat recht schwierig zu bearbeiten. Mit Potlatch etwa ist es nahezu unmöglich, eine neue Relation zu erstellen.
Kann es sein, dass Du die API 0.3 mit ihren Segmenten zurück haben möchtest? 
Da hast du jetzt einen Betrag nicht richtig gelesen…
Genau für solche Dinge ist eine Relation gut und funktioniert. Aber…
funktioniert nicht. Ich greife mal die brandenburgische Landesstraße L 51 heraus. Willst du alle Teilabschnitte mit eigenen Namen in eigene Relationen packen?? Das wird chaotisch… zum einen wer soll das machen? Zum anderen wer soll das Pflegen… Nee neee nee… Da kannst du dir mindestens alle Bundes- und Landesstraßen anschauen… Eine Relation pro Straße reicht, maximal Teilrelationen pro Bundesland…
Richtig. Geschwindigkeiten gehören zwingend hinzu auch wegen: maxspeed:forward=* und maxspeed:backward=*
Name ist auch eine gegenständliche Eigenschaft (siehe Beispiel L 51). Die ref-Eigenschaft ist im Prinzip eine künstliche Zusammenfassung von Teilabschnitten zu einer Einheit (Kreis- Land- oder Bundesstraße…)
Nein, ich würde es anders formulieren, wir versuchen einen gesunden Mittelweg zu finden zwischen relationsfreiem Tagging von Objekten einerseits und dem Einsatz von Relationen da, wo es sinnvoll ist.
Sven
Das ist Quatsch. Ich wäre wohl kaum auf Platz 791(Stand heute) beim hdyc-Relation-Ranking wenn das nahezu unmöglich wäre.