route-Relation

Wolmatinger · 2013-12-20 20:08:40

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?

Prince Kassad · 2013-12-20 20:21:15

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.

streckenkundler · 2013-12-20 20:52:21

Prince Kassad wrote:

Vor allem wäre es nicht eindeutig.

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

SunCobalt · 2013-12-20 20:58:20

streckenkundler wrote:

Bei Fließgewässern wäre es Fließgewässerkennzahl.

Bedauer ich es wenn ich fragen würde, was die Fließgewässerkennzahl ist?

streckenkundler · 2013-12-20 22:16:55

SunCobalt wrote:

streckenkundler wrote:
Bei Fließgewässern wäre es Fließgewässerkennzahl.
Bedauer ich es wenn ich fragen würde, was die Fließgewässerkennzahl ist?

Fließgewässerkennziffer oder-kennzahl im Prinzip vergleichbar mit der Nummer von Straßen...

Sven

Last edited by streckenkundler (2013-12-20 22:17:10)

Schina02 · 2013-12-21 02:13:29

streckenkundler wrote:

Selbst Namen gehören (logischerweise) ans Objekt.

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...

streckenkundler · 2013-12-21 09:55:24

Schina02 wrote:

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

Schina02 · 2013-12-21 12:17:02

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?

streckenkundler · 2013-12-21 12:24:46

Schina02 wrote:

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

chris66 · 2013-12-21 12:27:44

Wenn das der Fall ist wär's ja eine Sammelrelation, die bekanntlich nicht erwünscht sind.

morjak · 2013-12-21 13:25:07

streckenkundler wrote:

Schina02 wrote:
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
Sven

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.

streckenkundler · 2013-12-21 13:43:31

morjak wrote:

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

morjak · 2013-12-21 14:44:34

streckenkundler wrote:

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...

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.

Prince Kassad · 2013-12-21 15:07:00

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.

streckenkundler · 2013-12-21 15:27:15

morjak wrote:

Gerade bei mehreren Namen bieten sich Relationen doch an, weil am Weg nur ein Name stehen kann.

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.

morjak wrote:

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.

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

morjak · 2013-12-22 08:58:13

streckenkundler wrote:

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.

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.

streckenkundler wrote:

Was sind bei dir gegenständliche und nichtgegenständliche Eigenschaften?

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.

streckenkundler wrote:

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.

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.

Prince Kassad · 2013-12-22 10:29:33

Relationen sind aber in der Tat recht schwierig zu bearbeiten. Mit Potlatch etwa ist es nahezu unmöglich, eine neue Relation zu erstellen.

chris66 · 2013-12-22 10:33:10

morjak wrote:

Ich habe ehrlich gesagt manchmal das Gefühl, wir machen uns hier wegen der Angst vor Relationen alles unnötig schwieriger, als es ist.

Kann es sein, dass Du die API 0.3 mit ihren Segmenten zurück haben möchtest?

streckenkundler · 2013-12-22 10:34:39

morjak wrote:

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.

Da hast du jetzt einen Betrag nicht richtig gelesen...

streckenkundler wrote:

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...

Genau für solche Dinge ist eine Relation gut und funktioniert. Aber...

morjak wrote:

Ä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.

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...

morjak wrote:

Straßenbreite, Oberfläche, tracktype, Brückenhöhe usw sind gegenständliche Eigenschaften. Ich würde hier sogar Geschwindigkeitsbegrenzungen dazu zählen.

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...)

morjak wrote:

Ich habe ehrlich gesagt manchmal das Gefühl, wir machen uns hier wegen der Angst vor Relationen alles unnötig schwieriger, als es ist.

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

Last edited by streckenkundler (2013-12-22 10:36:37)

Thomas8122 · 2013-12-22 10:34:41

Prince Kassad wrote:

Mit Potlatch etwa ist es nahezu unmöglich, eine neue Relation zu erstellen.

Das ist Quatsch. Ich wäre wohl kaum auf Platz 791(Stand heute) beim hdyc-Relation-Ranking wenn das nahezu unmöglich wäre.

Last edited by Thomas8122 (2013-12-22 10:37:01)

Thomas8122 · 2013-12-22 10:38:14

streckenkundler wrote:

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.

+1

Gehrke · 2013-12-22 10:41:37

Thomas8122 wrote:

Prince Kassad wrote:
Mit Potlatch etwa ist es nahezu unmöglich, eine neue Relation zu erstellen.
Das ist Quatsch.

Schwierig ist es schon; insb. diese zu referenzieren. -1 kann man in den Dialog nicht eingeben, sondern muss eine ewig lange Liste scannen. Oder habe ich da etwas verpasst?

Thomas8122 · 2013-12-22 10:56:31

Gehrke wrote:

-1 kann man in den Dialog nicht eingeben, sondern muss eine ewig lange Liste scannen.

Das es leicht ist hab ich nicht gesagt. Es ging mir um das unmöglich.

morjak · 2013-12-22 11:14:56

streckenkundler wrote:

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...

Mal ein Beispiel:

Wir haben die Teilwege 1,2,3,4,5,6

Eine Bundesstraße besteht aus den Teilwegen 2, 3, 4 und 5. Weiterhin bilden 1 und 2 die "Bahnhofstraße" und 4, 5 und 6 die "Industriestraße".

Die Relation Bundesstraße enthält nun die Wege 2, 3, 4 und 5.
Die Relation Bahnhofstraße enthält 1 und 2.
Die Relation Industriestraße enthält 4, 5 und 6.

Das ist eine saubere Lösung und ich sehe keine übermäßige Komplexität - eher im Gegenteil, da z.B. bei einer Straßenverlegung nur die Mitglieder der jeweiligen Relation angepasst werden müssen.

streckenkundler · 2013-12-22 11:34:43

morjak wrote:

Das ist eine saubere Lösung und ich sehe keine übermäßige Komplexität - eher im Gegenteil, da z.B. bei einer Straßenverlegung nur die Mitglieder der jeweiligen Relation angepasst werden müssen.

Schau dir (erstmal) die Listen der Bundesstraßen und Landesstraßen an (Anzahl!!). Wann sollte das denn nach deinem Schema erfasst/ geändert werden? Ne, da macht keiner mit, und das will auch keiner. Dein Schema hat was von einer Vorstufe der Sammelrelation von Straßen gleicher Namen.
Zum anderen wechseln ja die Straßennamen auch nicht so oft wie Leute ihre Unterhosen... Am ehesten ändert sich mal der ref-Tag, da eine Straße oder deren Abschnitt umgewidmet wird. (Wenn auch einem Abschitt der Bundesstraße eine Landesstraße wird, aus einer Landesstraße 1.Ordnung eine der 2. Ordnung oder umgedreht oder aus einer Landesstraße eine Kreisstraße oder aus Kreisstraße Gemeindestraße... oder so...

Es ist schon ein Kanten Arbeit, Landesstraßen und Kreisstraßen in Relationen zu packen und mit lanes und turn:lanes anzufügen (den LDS-Kreis bin ich zu 2/3 durch).

Sven

Announcement

#1 2013-12-20 20:08:40

route-Relation

#2 2013-12-20 20:21:15

Re: route-Relation

#3 2013-12-20 20:52:21

Re: route-Relation

#4 2013-12-20 20:58:20

Re: route-Relation

#5 2013-12-20 22:16:55

Re: route-Relation

#6 2013-12-21 02:13:29

Re: route-Relation

#7 2013-12-21 09:55:24

Re: route-Relation

#8 2013-12-21 12:17:02

Re: route-Relation

#9 2013-12-21 12:24:46

Re: route-Relation

#10 2013-12-21 12:27:44

Re: route-Relation

#11 2013-12-21 13:25:07

Re: route-Relation

#12 2013-12-21 13:43:31

Re: route-Relation

#13 2013-12-21 14:44:34

Re: route-Relation

#14 2013-12-21 15:07:00

Re: route-Relation

#15 2013-12-21 15:27:15

Re: route-Relation

#16 2013-12-22 08:58:13

Re: route-Relation

#17 2013-12-22 10:29:33

Re: route-Relation

#18 2013-12-22 10:33:10

Re: route-Relation

#19 2013-12-22 10:34:39

Re: route-Relation

#20 2013-12-22 10:34:41

Re: route-Relation

#21 2013-12-22 10:38:14

Re: route-Relation

#22 2013-12-22 10:41:37

Re: route-Relation

#23 2013-12-22 10:56:31

Re: route-Relation

#24 2013-12-22 11:14:56

Re: route-Relation

#25 2013-12-22 11:34:43

Re: route-Relation

Board footer