RadNETZ Baden-Württemberg

[JochenB (Jochen)]

@rainerU

hätte ich gerne ein niedrigschwelliges Angebot, das ohne diese vielen Relationen auskommt.

In meinem Proposal hatte ich zwei Taggingmöglichkeiten vorgeschlagen. Einmal niederschwellig als ‘lcn=basic_network’ an den Wegelinien und einmal aufwendiger über route-Relationen.

So gibt es die Chance, das Netz (erstmal) unkompliziert zu erfassen. Solange die einzige Aufgabe der Relation ist, die Mitglieder als Teil des Netzwerkes zu markieren ist das ebenbürtig mit einer Relation. Wenn weitere Eingeschaften des Netzwerkes erfassen werden sollen, so ist es m. E. besser, das einmal in der Relation zu erfassen und nicht an jeder einzelnen Wegelinie.

Wenn sich jemand findet, der Wege mit ‘lcn=basic_network’ in Relationen überführt und mit weiteren Informaionen anreichert, so kann er es im Anschluss gerne tun. Wichtig ist erstmal, dass es überhaupt erfasst wird und man es von anderen Routen unterscheiden kann.

[rainerU]

@JochenB

In meinem Proposal hatte ich zwei Taggingmöglichkeiten vorgeschlagen. Einmal niederschwellig als ‘lcn=basic_network’ an den Wegelinien und einmal aufwendiger über route-Relationen.

Das habe ich gesehen.

Wenn weitere Eingeschaften des Netzwerkes erfassen werden sollen, so ist es m. E. besser, das einmal in der Relation zu erfassen und nicht an jeder einzelnen Wegelinie.

Wenn sich jemand findet, der Wege mit ‘lcn=basic_network’ in Relationen überführt und mit weiteren Informaionen anreichert, so kann er es im Anschluss gerne tun. Wichtig ist erstmal, dass es überhaupt erfasst wird und man es von anderen Routen unterscheiden kann.

Wenn die Relationen erst mal angelegt sind, muss sie auch jemand pflegen. Ich stoße aber immer wieder auf lcn-Relationen, die einmal vor fünf oder mehr Jahren angelegt und seitdem nicht mehr bearbeitet wurden. Ich würde diese Relationen ja pflegen, wenn ich deren Nutzen erkennen würde, genauer gesagt ihren Mehrwert gegenüber dem einfachen lcn=yes am Weg.

Ich nehme nur mal das Thema Routinganweisungen als Beispiel. Ein nützliches und hilfreiches Feature von Fahrradnavis wäre eine Richtungsansage, wie man sie von Autonavis gewohnt ist. Eine solche Ansage lässt sich aber mit den basic_network-Relationenen trotz des hohen Aufwands, den man rein steckt, nicht realisieren, da die Richtungsangaben der Wegweiser in keiner Weise mit der zugehörigen Verbindung verknüpft sind.

[Karthoo]

@rainerU

Wenn die Relationen erst mal angelegt sind, muss sie auch jemand pflegen. Ich stoße aber immer wieder auf lcn-Relationen, die einmal vor fünf oder mehr Jahren angelegt und seitdem nicht mehr bearbeitet wurden. Ich würde diese Relationen ja pflegen, wenn ich deren Nutzen erkennen würde, genauer gesagt ihren Mehrwert gegenüber dem einfachen lcn=yes am Weg.

Mir geht’s da tatsächlich ähnlich, allerdings mit lcn=yes an den Wegen. Ich stoße immer wieder auf einzelne Wege mit lcn=yes, die oft nicht einmal (mehr) Teil eines lcn-Netzwerks sind. Ich habe das Gefühl, lcn=yes ist viel unübersichtlicher als die Relationen-Lösung.

@rainerU

Ich nehme nur mal das Thema Routinganweisungen als Beispiel. Ein nützliches und hilfreiches Feature von Fahrradnavis wäre eine Richtungsansage, wie man sie von Autonavis gewohnt ist. Eine solche Ansage lässt sich aber mit den basic_network-Relationenen trotz des hohen Aufwands, den man rein steckt, nicht realisieren, da die Richtungsangaben der Wegweiser in keiner Weise mit der zugehörigen Verbindung verknüpft sind.

Deshalb füge ich an die Relationen meistens auch die Richtungsangaben via destination:forward/backward an, wie z.B. hier.

[skyper]

@Karthoo

@rainerU

Wenn die Relationen erst mal angelegt sind, muss sie auch jemand pflegen. Ich stoße aber immer wieder auf lcn-Relationen, die einmal vor fünf oder mehr Jahren angelegt und seitdem nicht mehr bearbeitet wurden. Ich würde diese Relationen ja pflegen, wenn ich deren Nutzen erkennen würde, genauer gesagt ihren Mehrwert gegenüber dem einfachen lcn=yes am Weg.

Mir geht’s da tatsächlich ähnlich, allerdings mit lcn=yes an den Wegen. Ich stoße immer wieder auf einzelne Wege mit lcn=yes, die oft nicht einmal (mehr) Teil eines lcn-Netzwerks sind. Ich habe das Gefühl, lcn=yes ist viel unübersichtlicher als die Relationen-Lösung.

Liegt das nicht eher daran, dass die Relationen in QA unterstützt werden, während l*n=* an Linien komplett ignoriert wird?

@Karthoo

@rainerU

Ich nehme nur mal das Thema Routinganweisungen als Beispiel. Ein nützliches und hilfreiches Feature von Fahrradnavis wäre eine Richtungsansage, wie man sie von Autonavis gewohnt ist. Eine solche Ansage lässt sich aber mit den basic_network-Relationenen trotz des hohen Aufwands, den man rein steckt, nicht realisieren, da die Richtungsangaben der Wegweiser in keiner Weise mit der zugehörigen Verbindung verknüpft sind.

Deshalb füge ich an die Relationen meistens auch die Richtungsangaben via destination:forward/backward an, wie z.B. hier.

Die Richtungen sollten ja aus den superroute Relationen erkennbar sein, aber auch laute hier die Frage wohl, welche Software wertet das korrekt aus.

[rainerU]

@Karthoo

Deshalb füge ich an die Relationen meistens auch die Richtungsangaben via destination:forward/backward an, wie z.B. hier.

Auch das kann man am Weg machen, Beispiel.

[JochenB (Jochen)]

Also ich nutze für sowas auch Relationen wegen der guten Wartbarkeit. Auf einen Blick sieht man Lücken oder kann auf die gesamte Verbindung zoomen. Womöglich liegt das am verwendeten Editor. In JOSM ist das sehr komfortabel gelöst.