max_speed Richtungsabhängig???

Hallo, ich habe eine Straße von A → B. Dort darf man 100 km/h fahren. In der umgekehrten Richtung aber nur 70 km/h. Wie mappe ich sowas mit Potlatch oder josm??? Vielen Dank für Eure Hilfe Andreas

Das Problem tritt ziemlich haufig auf und zwar nicht nur bei speedlimits sondern auch (unsinnigerweise) bei Zugangsbeschraenkungen und max weight, ich sehe diese Ungereimtheiten vor allem auf dem Lande… Eine Loesung habe ich allerdings nicht Gruesse, Wolfgang

Relationen haben sich noch nicht in ihrem vollen Potential durchgesetzt, aber damit wäre sowas durchaus Möglich… Du erstellst einfach eine Relation mit maxspeed=70, und gibst ihr die Role “forward”. Und dann erstellst du eine zweite Relation mit maxspeed=100 und der Role “backward”. Backward und forward richten sich nach der wegrichtung des Ways…

Erstmal danke für den Tipp. Aber irgend wie bin ich zu blöd das umzusetzen. Kannst Du mir bitte Schritt für Schritt sagen, was ich eingeben muß? Potlatch oder JOSM wäre egal. Vielen Dank Andreas

Ich kanns dir jetzt nur für Potlatch sagen… 1.) Markiere den Weg 2.) Klick auf das “zu einer Relation hinzufügen”-Icon. (ganz rechts das mittlere) 3.) “Eine neue Relation erstellen” auswählen und OK klicken. 4.) Mit dem “+”-Icon einen neuen Tag hinzufügen. 5.) Links “maxspeed” und rechts “70” eintragen. Dann OK klicken. 6.) Auf dem Pfeil-icon die Wegrichtung überprüfen. 7.) In das kleine Feld bei der Relation “forward” eintragen, wenn das maxspeed in Wegrichtung gilt. Ansonsten “backward”… 8.) Wiederhole Punkt 1-7 für die andere Richtung

Hallo, ich mal wieder. Ich habe die Relationen wie oben beschrieben (mit Potlatch) angelegt. Seid einiger Zeit verwende ich nun JOSM. Als ich heute hier http://www.openstreetmap.org/?lat=51.93904&lon=9.085324&zoom=18 wieder so eine Relation mit JOSM angelegt habe, erhielt ich folgende Fehlermeldung:

Relation ohne Typ - Ungültige Schlüssel/Wertkombinationen (1)

Wie lege ich die Relation korrekt an? Danke für Eure Hilfe. Andreas

Generell heißt diese Info oft nur, dass man eine recht neue Taggingidee einsetzt, die der Validator noch nicht kennt, was nicht immer ein Fehler deinerseits ist. Eine solche Meldung ist durchaus zu erwarten, weil eine Relation wie von TEL0000 beschrieben wohl seine persönliche Erfindung ist, jedenfalls existiert meines Wissens noch keine Dokumentation oder nennenswerte Verbreitung. (Es existiert hier allerdings noch keine Lösung, die diese Kriterien erfüllen würde.)

Frage an TEL0000: Warum mit Relationen auf Spatzen schießen und nicht einfach Keys maxspeed:forward=70 und maxspeed:backward=100 setzen? Siehe entsprechendes Proposal.

Ein wichtiger Punkt ist da noch. In Zukunft die Richtung des gezeichneten Weges nicht ändern bzw. aufpassen das dies auch kein anderer tut. Die Wege haben ja keine natürliche Grundrichtung, die legt der der Mapper fest. Ansonsten würde das getaggte dann von B nach A 100 und umgekehrt 70 bedeuten. Das ist der Haken an dieser virtuellen Beschreibung. Deswegen warte ich auf etwas genaues, ist mir zu Fehleranfällig.

backward und forward als role einer relation anzugeben ist sehr wohl sehr verbreitet. Das ganze mit Maxspeed zu machen, das hab ich mir ausgedacht. Aber ich hab lediglich bereits verwendete Verfahren kombiniert, so dass eine Software die das backward/forward-relation-role-system kennt, und tags in relationen erkennt, das ganze automatisch richtig auswerten würde.

Weil eine Software das auslesen könnte, ohne den speziellen Tag zu kennen, bzw. ohne einen neuen Tag zu erfinden. Aber im Prinzip ginge es auch so, wie du es vorschlägst. Würde zu meinem Verständnis der hirarchischen Schlüssel passen… Leider zählt jeder Schlüssel nachwievor nur als ganzes, so dass man jeden erdenklichen Fall beim erfinden der Schlüssel berücksichtigen muss. @Mirko: Warum sollte man die Wegrichtung ändern? So wie du es sagst müsste man auch bei jeden oneway aufpassen, dass keiner den Weg dreht. Da ist es nämlich noch wesentlich fataler. Meiner Meinung nach müsste sogar auch der oneway-tag von oneway=yes zu oneway=forward/backward geändert werden.

Wahrscheinlich aus dem gleichen Grund, aus dem einiger anderer überflüssiger Unfug resultiert. Unkenntniss, Schaden… Ist ein bisschen dünn sich einzig darauf zu verlassen, das keiner Mist baut. Wenn wir schon keine richtige Trennung zwischen Fahrbanen hinkriegen, sollte es wenigstens die Möglichkeit von zweit festen Punkten geben. Von Punkt A nach Punkt B auf Weg C gilt Wert X. Das macht irgendwelche virtuellen Konstrukte überflüssig und ist eindeutig. Erspart nebenbei auch das zerstückeln. Dann kannst du den Weg befingern ohne einen Einfluss auf die Seperaten Angaben zu nehmen.

Es passte wieder. Vorige Woche hatte ich erst den Fall das einer einen Wanderweg Track einfach mal so über alles andere legte. Ich hatte ihn angeschrieben und gebeten die vorhandenen Wege zu nutzen und die Betroffenen Abschnitte in einer dafür vorgesehenen Relation für den Wanderweg zu packen. Ich wollte das nicht kommentarlos löschen. Keine Antwort. Stattdessen wurde der Track gestern noch erweitert und kreuzt bzw. überlagert jeglichen Feldweg bis hin zur Bundesstraße auf knapp 30 km Länge. Und genau deswegen halte ich in diesem Projekt rein garnichts von virtuellen Angaben, die Vorwissen und Aufmerksamkeit erfordern. Die Leute meinen das sicher nicht böse, aber hier bleiben Fehler nunmal nichts aus. Es gibt viele banale Gründe aus denen Anfänger auch Wege drehen, so in der Praxis auch schon gesehen. Der Mapper fängt in seinem Ort an und geht ensprechend seiner Erfassungsrichtung Sternförmig heraus. Irgendwann trifft er auf vorhandenes. Dann will er verbinden, JOSM verbindet aber nur in einer Richtung, ein Klick und bums ist es möglicherweise passiert. Ein anderer nimmt sich seiner Bundesstraße an und sammelt Infos. Auf Wiki liest er dann “führt von Adorf über Klunkershausen nach Pimpelhausen”. In der Erfassung wurde der Weg aber in gegensätzlicher oder abschnittsweise unterschiedlicher Richtung erfasst. Das ist auch eher die Regel. Nun glaubt der Mapper die Richtung vereinheitlichen zu müssen. Nun wäre die Straße zwar in einer einheitlichen vielleicht auch korrekten Richtung, aber eventuelle virtuelle Angaben sind dann für die Tonne. Nirgends werden solcherlei Angaben an eine eigentlich beliebige Zeichenrichtung gebunden. Dafür werden immer fest Bezugspunkte gewählt. Ich nehme da mal das Beispiel Bahn. Eine Langsamfahrstelle gilt nicht hinter Tuntenhausen bis zu Plätscherbachbrücke. Eine Lf beginnt mit den entsprechenden Schildern am Kilometer 105,7 und endet Kilometer 106,1. In der Gegenrichtung entsprechend abwärts. So steht es dann auch im Geschwindigkeitsheft. Prinzip dürfte klar sein. Zwei unmissverständlich feste Bezungspunkte. Solche Bezugspunkte haben wird auch. Das sind die Nodes. Denen ist die Richtung egal, sie müssen nur vorhanden sein. Nun brauche ich den Nodes nur eine entsprechende Rolle zuzuweisen. Node 1 bekommt beispielsweise start, Node 2 end, von mir aus auch from → to, beschrieben mit beispielsweise maxspeed=80. Da bräuchte man den Weg nichtmal auftrennen. Ausser es wäre technisch noch immer nötig die aufzutrennen und mit in die Relation zu packen, das kann ich nicht beurteilen. Das wichtigste wäre aber erreicht. Ich mache die Angabe nicht vom Weg abhängig, sondern habe zwei feste unabhängige Bezugspunkte mit unmissverständlicher Richtung. Optimal wäre natürlich noch immer die Informationen komplett vom Objekt zu trennen. Ein eigenes Objekt mit Start und Ende. So könnte man theoretisch auch den ganzen Weg schrotten, ohne das dessen Informationen gleich mit verschwinden. Das schützt zwar nicht vor Vandalen, ist aber vor den typischen Bearbeitungsfehlern sicher.

Dafür kann der Editor die richtungsabhängigen Angaben automatisch mitdrehen. Und da jetzt sicher wieder das Argument kommt: “Was ist mit den Editoren die das nicht unterstützen?”. Für jede der bisher vorgeschlagenen Möglichkeiten braucht man zusätzliche Editorunterstützung um Fehler zu vermeiden. Meistens sogar sehr viel kompliziertere Dinge als man für richtungsabhängige Tags braucht.

Nur dass die Bezugspunkte bei der Bahn festgelegt sind, bei OSM nicht. Auch Nodes sind virtuelle Objekte, die willkürlich gesetzt und verändert werden können. Sie geben zwar den Straßenverlauf wider, allerdings ist für einen einzelnen Node nicht festgelegt, welchem realen Objekt oder welcher Position er entspricht (nur solange er eben nicht verschoben wird, genauso wie für einen Weg eine Richtung festgelegt ist solange er nicht gedreht wird).

Dann gäbe es aber immer noch einige Dinge zu klären: - Wenn einer der beiden Punkte gelöscht wird - Wenn die relative oder absolute Lage der Punkte verändert wird und damit die Information verfälscht wird - Wie wird das im Editor dargestellt? Wenn nur die Nodes in der Relation enthalten sind, ist es sehr aufwendig (ohne zusätzliche Editorunterstützung) diese Anfangs oder Endpunkte zu finden. - Was ist wenn es mehrere Wege zwischen from → to gibt? Und vor allem was ist wenn sich die Wege dazwischen verändern? Darauf müsste der Editor dann auch achten.

Wäre ein anderer Ansatzpunkt. Mir geht es nicht um den Weg sondern ums Ziel. Ob nun konkret auf Nodes bezogen oder der Editor denkt mit, letzendlich vollkommen egal. Im Moment hat aber forward/backward ohne mitdenkenden Editor keinen wert. Darum geht es mir.

Deswegen wäre mir eine Trennung vom Objekt auch viel lieber. Ändert einer die Straße dann betrifft das immer alles was mit daran hängt. Von der Geschwindigkeitsbeschränkung bis runter zur hinterletzten Busrelation. Versaut das einer aus oder ohne Absicht, ist gleich alles fehlerhaft. Wenigstens werde ich bei JOSM gewarnt, bevor ich etwas lösche und so aus einer Relation werfe. Was die virtuelle Richtung betrifft kommt nichts. Wer forward/backward nicht kennt, wird da auch nicht darauf achten. Und in der Praxis arbeiten hier eben viele mit, die eben nicht alles vorher studiert haben. Siehe oben oder zwei, drei Threads weiter. Wer JOSM schon nicht zum laufen bringt, wird auch nicht auf kompliziert verschachtelte Relationen achten. Es ist das eine sich eine mögliche Lösung auszudenken. In einem Mitmachprojekt wie diesem musst du aber immer die Idiotensicherheit ganz oben auf der Rechnung haben. Mit RTFM kommt man nicht weit. Es wird immer die geben die loslegen anstatt das fucking Manual zu lesen.

Was willst du jetzt eigentlich damit sagen? Ich wollte nur ausdrücken, dass das mit den from-to Relationen auch nicht so einfach (eher komplizierter) ist. Die zur Zeit noch fehlende Editorunterstützung ist nicht wirklich ein Argument, da sowas Einfaches sicherlich sehr schnell eingebaut ist, sobald solche Tags etwas weiter verbreitet sind (genauso wie es bei oneway ja schon ist). Und vor allem eben weil es bisher keine andere Möglichkeit gibt, die einfacher ist.

Solange es nicht eingebaut ist, ist das ein Argument. Schön wenn du mir jetzt sagst das es einfach umzusetzen ist. Das muss aber noch lange nicht heißen das es irgendwann auch wirklich umgesetzt wird. Ich höre das von dir zum ersten mal. Ist das jetzt nur deine persöhnliche Meinung oder steht das offiziell auf der todo? Auf prinzip Hoffnung tagge ich nicht. Da warte ich lieber auf eine vollständige Umsetzung und mache es einmal, dafür aber richtig. Im Gegensatz zum Oneway betrifft das einige Schnipsel mehr.

Nein, es ist kein Argument die Vorgehensweise deshalb abzulehnen. Was du taggst ist natürlich deine Sache, manche taggen auch nur Dinge die z.B. Mapnik darstellt (auch wenn es eigentlich logischere Tags gibt). Die Implementation ist sicherlich nicht schwer, da nur ein paar Strings verglichen und ausgetauscht werden müssen, wenn eine bestimmte Aktion ausgeführt wird. Für oneway und für left: und right: am Anfang des Tags ist das auch schon eingebaut und es sollte nicht schwer sein, das auf die benötigten zu erweitern. Und das wird es auch sicher wenn es großflächig benutzt wird. Bei OSM ist es doch eigentlich meistens so, dass vieles erstmal ausprobiert wird. Wenn man sich aber nur etwas sinnvolles vorschlagen darf, wenn man gleichzeitig den passenden Code mitbringt, dann finde ich das schade. Ich verstehe deine Bedenken, aber wenn man nichtmal damit anfängt oder wenigstens sich positiv dazu äußert (also zeigt dass die Nachfrage vorhanden ist), dann sieht vielleicht auch keiner die Notwendigkeit etwas in den Editoren zu verändern.

Es ist auch meine Zeit die da drauf geht. Und wenn du meine Ecke mal anschaust nicht wenig. Die Daten die ich hier verwurste sind teilweise über Jahre zusammen gekommen und waren mitunter nicht billig. 2001 fing ich an. Aus dem gleichen Grund wie Steve Coast. Ich brauchte Daten, die lassen sich die LVA aber bekannterweise gut bezahlen. Und wenn du damals nach Datenspenden gefragt hast, hat man dich zur Hand sprechen lassen. So locker wie das heute bei einigen anscheinend geht, damals undenkbar. Blieb also nur selber erfassen. Heute aktualisiere ich die dazu gekommenen Änderungen. Soweit daraus gleich eine Weltkarte zu machen, habe ich natürlich nicht gedacht. Mir ging es damals um die Umsetzung der Mitteldeutschen Bahnstrecken, dazu gehört genauso die Landschaft drumherum. Ich investiere dann nicht Stunden um soetwas genaustens umzusetzen, wenn der Ausgang völlig offen und die Arbeit dann vielleicht doch umsonst war. Andere können ja gerne probieren, ich möchte die Zeit aber Zielgerichtet einsetzen und nicht Betatester spielen. Auch ohne mich werden es genügend nutzen, oder eben auch nicht. Mir ging es nicht um hätte, könnte, möglich. In Zukunft ist alles möglich. Nur im Moment das so noch zu unsicher weil nur halb gelöst. Ich nutze auch gerne forward/backward, aber erst wenn es rund ist, sprich die Editoren die Fehlerquote minimieren.

Gut, ist ja deine Sache. Ich wollte dich nur darauf aufmerksam machen, dass es zur Zeit einfach keine bessere Lösung gibt. Ich tagge auch nicht die ganze Gegend damit. Aber wenn man wenigstens mal einen kleinen Bereich damit ausstattet (und wenn das jeder macht), dann ist das für den Einzelnen nicht viel Arbeit, man kann testen ob es sinnvoll funktioniert und man kann zeigen dass es viele Leute gut finden. Ich würde nie von dir verlangen deine ganze Arbeitsweise daran auszurichten, wenn es noch nicht im allgemeinen Gebrauch ist. Wiegesagt, wenn sich mal jemand dransetzen würde, der das kann, dann wäre es nicht nur in irgendeiner fernen Zukunft möglich, sondern quasi morgen. Das ist schon ein Unterschied zu so Dingen wie “irgendwann werden Router erkennen können ob man sich innerorts befindet” oder solche Scherze, wo selbst die Umsetzung noch etwas unklar ist. Aber eigentlich ist halt ganz OSM ein einziger Betatest und sicherlich nicht alles ideal. Aber da bist du nicht der Einzige, den da manche Dinge stören.