Die Polen machen schon seit jeher separate Wege. Fuß- und Radwege werden ganz pragmatisch neben die (Auto-) Straße gesetzt, selbst wenn es keinen trennenden Grünstreifen gibt. Das vereinfacht das Tagging ungemein. Und man kann so die Straße auch von Rad- und Wanderroutenrelationen entlasten. Der Nutzbarkeit der Daten für Routing oder Kartenrendering schadet das nicht, im Gegenteil.
Solche abenteuerlichen Konstruktionen wie hier diskutiert https://forum.openstreetmap.org/viewtopic.php?id=72542
habe ich in Polen auch noch nicht gesehen. Zwei parallele highways, aus die Maus. Hierzulande scheint in gewissen Teilen der OSM-Szene aber eher der Siemens-Ansatz vorzuherrschen: “Warum macht Ihr das so kompliziert?” “Weil wir es können.”
d.h. man muss da gar nicht von 50 auf 100 beschleunigen, um was von der Splittung zu haben, man kann auch aus dem Feldweg mit 100 kommen und muss erst am Ortsschild bei 40 sein.
Wenn die Behörden die Schilder so aufstellen, dann gelten sie auch so, und wenn man es genau nimmt, dann bildet man so was auch ab. Wenn ein Feldweg die ersten Meter noch befahrbar ist, kann man das auch so abbilden, warum nicht. Vermutlich ist das absichtlich so, dass man noch wenden kann.
Das Problem ist, dass man die sich nicht ändernden Tags am gesplitteten Weg wiederholt obwohl die sich nicht geändert haben, sprich unnötige Redundanz, und das tut dem Informatiker seiner Seele weh :-).
Und da ist schon, ohne Zweifel, was dran. Obwohl das Problem nicht die kurzen Segmente an und für sich sind, dass kann einfach kein Argument sein wenn unser Datenbestand hauptsächlich aus Wegen mit 4+1 Nodes besteht. Sondern eher, dass das Tagging von, an und für sich gleichen, Wegteilen auseinander driftet und es auch sonst etwas fehleranfällig ist.
Grundsätzlich gibt es für das Problem 2 mögliche Lösungen:
Routen so zu modellieren, dass die Wege nicht aufgeteilt werden müssen (also zum Beispiel durch Routen die irgendwie Nodes verwenden)
Die Geometrie von Wegen von den Eigenschaften/Tags zu separieren, also eben “Segmente” (das würde übrigens das “splitte ich den Weg dort wo die Geschwindigkeitsbegrenzung wirklich anfängt, oder lass es für zusätzlich 10m gelten” Problem nicht lösen).
Eines ist ziemlich klar, der Aufwand das Erstere zu machen ist viel viel viel kleiner als das Zweite.
Ich bin sehr für das separate Erfassen von Geh- und Radwegen. Das Hauptproblem hierbei ist jedoch das Routing, da es noch keine einfache Möglichkeit gibt anzugeben, dass man zwischen zwei parallel verlaufenden Wegen wechseln kann und ob und wenn ja welches Hindernis man dabei überwinden muss (kerb). So muss man bei separaten ways sehr viele Verbindungswege einzeichnen. Das wird leider oft nicht gemacht und macht das Routing kaputt.
ist ja auch alles kein Problem… solange man es nicht bearbeiten muss.
Wenn es dann mal kaputt geht… oder sich stark verändert… und man muss da ran.
Dann wird es zum Problem… wenn alles verklebt ist, zerstückelt, “übertaggt” , multipolygonitis ausgebrochen, Wege/Punkte/Relationen in einer Vielzahl an Relationen Mitglied ist. Da hilft dann oft nurnoch die Abrissbirne… delete
Ich finde dann die Leute cool die dann solche Edits mit ID machen… dass nennt man dann Mut zur Lücke Meinen nächsten Kreisel bau ich auch mit ID ein mal schauen wie viel ich kaputt mache
Straßen die aus vielen kurzen Einzelsegmenten bestehen erschweren die Bearbeitung und die Wartbarkeit. Bei der Anpassung einer Straße besteht die Gefahr, dass man ein kurzes Stück übersieht.
Für mich ist das aber kein ausreichender Grund. OSM wird detailreicher und das ist die logische Konsequenz daraus. Es ist Aufgabe der Editoren an dieser Stelle besser zu unterstützen.
Du kannst Dich darüber gerne lustig machen, aber als iD-User wusste ich von der Problematik bis vor Kurzem gar nichts. Woher auch?
Das Problem besteht schon ab einer Straße, die mit zwei Einzelsegmenten gemappt ist. Na klar, je mehr Einzelsegmente, je höher die Gefahr.
Was wären Bearbeitungen bzw. Wartungsarbeiten, wofür man die gesamte Straße auswählt? Taggingschemaänderungen?
Gibt es von Editoren wie JOSM kein Feature, mit dem man alle Teile einer Straße auswählen kann? Mit iD geht es wahrscheinlich bei langen Straßen nicht, weil der nur anwählen kann, was im aktuellen Kartenausschnitt im Browser sichtbar ist.
Lustig will ich mich nicht machen, aber es zeigt halt das dass jetztige System nicht optimal ist. Die Leute machen das ja nicht absichtlich, sondern sie wissen es halt nicht besser… da kann man keinen Vorwurf machen wenn was kaputt geht.
Und der Anspruch sollte halt auch sein das dass ganze auch ohne JOSM noch bearbeitbar bleibt, alles andere ist eine Entwicklung in die falsche Richtung.
Beispiele wären: Eigenschaften ergänzen (surface, smoothness, lit, maxspeed, name etc.), sich geänderte Eigenschaften updaten (ref, maxspeed, etc.), Typos bei Straßennamen fixen.
Was die konkreten Anwendungsfälle sind hängt davon ab, wie weit die Karte in dem Bereich schon entwickelt ist. Insbesondere wäre das nützlich wenn man bei größeren Straßen Eigenschaften wie lanes ergänzen muss, oder viele Stücke derselben Straße z.B. in eine Route-Relation einfügen will.
Mit Overpass und Filtern ist es kein Problem alle gewünschten Wege in JOSM auszuwählen. Ticket 20809 sollte eine weiter Option bieten.
In meiner Gegend, bin ich die ganze Zeit am entkleben und am Ergänzen von foot=use_sidepath und path=sidewalk und/oder is_sidepath[:*].
Häufig finde ich auch sidewalk=no und foot=no obwohl es ein Trottoir/Seitenweg gibt. Viele dieser Ungenauigkeiten muss ich leider der Fahrrad-Crew anlasten.
Wenn ich Wege aufteile, schaue ich mir immer an, ob ich nicht eine Hälfte/beide Endstücke mit den angrenzenden Wegen vereinigen kann. Hier könnte die Editor-Software mehr Unterstützung anbieten, allerdings braucht es einen genauen Blick auf alle Attribute und Mitgliedschaften.
Und wie wird dort der Zusammenhang zwischen Straße und ihren Seitenwegen in den Daten erfasst?
Gibt es Regelungen wie das Nutzungsgebot für Seitenwege für bestimmte Fortbewegungsarten?
Und wie funktioniert dann das Routing, insbesondere der Wechsel zwischen den beiden Wegen, und wie werden die beiden Wege als eine Einheit dargestellt? Wird ein area:highway als zusätzliches Objekt verwendet?
Muss? Bitte doch die Personen, die diese Konstrukte erstellt haben, sich darum zu kümmern. Das Hauptproblem ist auch hier die Kommunikation und die Software, die nicht entsprechende Warnung gibt bzw. manche Änderungen gar nicht zulässt.
Bitte nicht, damit geht jeder Bezug verloren und es macht kein Spaß erst alles zurückzusetzen, um die Änderungen nachzuvollziehen.
Habe ich kein Problem mit. Wenn das entsprechend im CS steht und eventuell noch per PM oder hier im Forum um Hilfe gebeten wird, um so besser.
ja, mit den Filtern kann man das machen, vor allem bei längeren Straßennamen ist das aber mehr Arbeit als die ways zu klicken (und es lohnt kaum, weil man sie wahrscheinlich nicht wieder braucht), der Vorteil ist, dass man sehr kurze Stücke nicht übersieht.
Vielleicht setzt ja jemand dein oder mein Ticket um, würde mich freuen.
Das hätte den Nachtteil, dass damit die Anwendungsfälle, in denen man wissen will, wo Busse herfahren, nicht abgedeckt würden. Ich denke zum Beispiel an Fälle von eher engen Straßen, vielleicht ohne Bürgersteig. Da könnte es dann zu einer starken Konkurrenz zwischen Fußgängern, Bussen und Radfahrern kommen. Wenn man in die Relation alle Straßenabschnitte aufnimmt, wo die Busse fahren, könnte man gegebenenfalls andere Verkehrsteilnehmer da herumrouten, vielleicht sogar abhängig vom Busfahrplan (der aus einer externen Quelle stammt).
Aber gibt es denn von den Verkehrsunternehmen überhaupt eine Zusage über “der Bus fährt diese Haltestelle an” hinaus? Könnten die sich das nicht jeden Tag anders überlegen, wo sie ihren Bus fahren lassen?
Im Prinzip ja, und neue, nicht orts-kundige Fahrer bekommen selbst das: “der Bus fährt diese Haltestelle an” nicht immer hin.
Rein daten-technisch braucht’s weder die Member-ways noch die potentielle Member-Stützpunkte.
Nur wenn man die Fahrstrecke in echt und korrekt auf Karten projizieren will … dann ja, dann braucht’s Unterstützung für die Renderer, oder liege ich da falsch?
Wär jedenfalls komplexer für Renderer, eine Route anzuzeigen.
Aber auf der anderen Seite wären dann route-Relationen sehr einfach zu maintainen. Das ist nicht nur gut für die Mapper, sondern letztlich auch für die Nutzer dieser Daten, die nicht ständig mit kaputten (=lückenhaften) Relationen rechnen müssen.
Eher nicht. Der Editor muss mir eine Vorschau mit dem gleichen Router erstellen den alle Kartenanbieter auch verwenden. Das könnte noch umsetzbar sein. Änderungen am Router machen diverse Routen kaputt. Sprich der Router muss auf alle Ewigkeit konstant bleiben.
Das größte Problem ist der exakte Verlauf ist nie gespeichert.
Als Anwender möchte ich bei einer Wanderroute/Radroute ihrem Verlauf exakt folgen. Denn da haben sich idR Menschen einen Kopf gemacht und eine schöne Route ausgewählt. Wenn ich ein von Stütpunkt zu Stützpunkt geroutetet Etwas haben möchte, kann ich das auch selber mit jedem Router erstellen.
Bei einer Busroute ist das was anderes. Da bin ich Passagier, da fahre ich mit und als Anwedner ist mir lediglich wichtig, dass ich weiß an welcher Haltestelle mein Bus abfährt, wo ich umsteigen muss und wo ich Aussteigen muss. Da kann das sehr gut mit solchen Konstrukten funktionieren.
man müsste die Geometrie (Nodes, Ways) von den Eigenschaften trennen. Bspw. name=Schulstraße sollte quasi eine collection (=relation) aus den Wegsegmenten sein, die zu dieser Schulstraße gehören. Es ließe sich im aktuellen Datenmodell umetzen, aktuelle Software, die Routenrelationen verwursten kann, kann auch damit umgehen. Per Definition müssen die Mitglieder alle verbunden sein oder nur ein Objekt beinhalten. Sprich vor einem Speichern kann ein Editor oder aber die API das validieren.
dass nennt man dann Mut zur Lücke 
da kann man keinen Vorwurf machen wenn was kaputt geht.