Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Moin, Tirkon schrieb: Wie gehabt: Ich habe gerade das erste Mal etwas über XML gelesen. Was jetzt kommt, ist also mit Sicherheit nicht richtig. Aber entfernt könnte das Ganze dann so aussehen: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='-4' visible='true' lat='-1.3351572879110518' lon='-1.466542772416855' / node id='-2' visible='true' lat='-0.022631832319151942' lon='-0.21726559591360814' / node id='-1' visible='true' lat='0.31231774745922347' lon='-0.8962205831436337' / way id='-3' action='modify' visible='true' nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='70' / nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='50' / nd ref='-4' / nd ref='-2' / nd ref='-1' / /way /osm prinzipiell machbar (mit kleinen formalen Änderungen ;-) ). Du machst allerdings nichts anderes, als den öffentlichen Textzusatz :forward in einen internen versteckten Bereich zu verschieben - da könnte man dann z.B. genauso bei einem internen versteckten forward bleiben. Denn der Editor muss bei dieser Variante jetzt eh: - Dem Nutzer bei jedem richtungsbezogenen-Tag die Richtung 'visualisieren', damit der weiß, worauf sich der Tag bezieht, z.B. durch forward/backward? ;-) - und er muss eine entsprechende Eingabemöglichkeit anbieten. Zudem müsste er aber bei Deiner Version bei jeder Weg-Änderung (entfernen, hinzufügen, teilen, verbinden)alle entsprechenden Node-Referenzen bearbeiten - da kann er auch bei jeder Richtungsänderung die internen Tags anpassen, fragt sich, was einfacher ist bzw. öfter vorkommt ... Möglicherweise lässt sich das auch soweit eindampfen, dass man nur den ersten und den letzten Node angibt. Es könnte aber Gründe geben, warum man dies beim Way nicht getan hat. Dieselben Gründe könnten auch dagegen sprechen, beim Tag ebenso zu verfahren. Ein Way führt nunmal über alle Nodes (wo z.B. ja auch andere Wege abgehen können), daher müssen ja auch alle Nodes enthalten sein. Für die Richtung würden zwar die End-Notes ausreichen, dann muss aber bei jeder Node-Änderung entsprechender Zusatz-Aufwand betrieben werden - Alternative s. o.. Fazit: Der notwendige Editor-Aufwand wird nur vom Umdrehen der Tag-Richtung zur Visualisierung und Eingabe-Möglichkeit verlagert - erforderlich ist er immer. Das Verschieben der Richtungsinformation in den 'internen' Daten-Bereich erfordert aber wegen der Tag-Konzept-Änderung zusätzlich noch eine API-Änderung. Hat man damit viel gewonnen? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Erst einmal vielen Dank für die technischen Klärungen. :-) Georg Feddern ne...@bavarianmallet.de wrote: Wie gehabt: Ich habe gerade das erste Mal etwas über XML gelesen. Was jetzt kommt, ist also mit Sicherheit nicht richtig. Aber entfernt könnte das Ganze dann so aussehen: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='-4' visible='true' lat='-1.3351572879110518' lon='-1.466542772416855' / node id='-2' visible='true' lat='-0.022631832319151942' lon='-0.21726559591360814' / node id='-1' visible='true' lat='0.31231774745922347' lon='-0.8962205831436337' / way id='-3' action='modify' visible='true' nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='70' / nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='50' / nd ref='-4' / nd ref='-2' / nd ref='-1' / /way /osm prinzipiell machbar (mit kleinen formalen Änderungen ;-) ). Du machst allerdings nichts anderes, als den öffentlichen Textzusatz :forward in einen internen versteckten Bereich zu verschieben - da könnte man dann z.B. genauso bei einem internen versteckten forward bleiben. Du hast Recht. Eigentlich braucht man nur eine versteckte 1-bit Speicherstelle (Flag). Wie ich schon schrieb, war ich mir bloß nicht sicher, ob hinter der nochmaligen Aufzählung aller Nodes der Richtung beim Way ein Sinn steckt. Denn darüber sind sie schon einmal alle in der richtigen Reihenfolge aufgezählt. Diesen Gedanken habe ich für meinen Vorschlag fortgesponnen. Der Hintergedanke der Wiederholung könnte gewesen sein, dass die Datenbank erheblich häufiger gelesen, als in sie geschrieben wird. Demzufolge wäre es sinnvoll, wenn man dem Lesen alles möglichst mundgerecht macht - auch wenn das beim Schreiben einen erhöhten Aufwand verursacht. Besser den Aufwand einmal beim Schreiben machen, als bei jedem Abruf. Wenn dem nicht so ist, kann man natürlich das einzelne Flag verwenden, aber nur ungern forward nennen. Denn dies täuscht darüber hinweg, dass forward nicht immer forward bleiben muss. Die Bedeutung des Flags Richtung=forward/backward, Seite= rechts/links, Steigung=aufwärts/abwärts, Lage=innen/außen, Ortseingangsschild=A-Stadt oder A-Stadt/B-Stadt oder A-Stadt/B-Stadt x km (Relation) oder was auch immer, läßt sich durch das Tagging zuschreiben. Auch wegen dieser Doppeldeutigkeit von forward ist der Begriff als Flagbezeichnung problematisch, weil verwechslungsgefährdet. Man könnte sich in diesem Zusammenhang auch überlegen, ob man die Relation way1 - eingeschlossener Node - way2 nicht ähnlich instanzieren könnte, um auch einem Node eine Richtung geben zu können. Denn auch so etwas braucht man öfter. Allerdings ist mir mangels Kenntnisse vollkommen unklar, wie man das anstellen könnte. Dann hätten sowohl Nodes, Ways und Relationen eine Richtung. Denn der Editor muss bei dieser Variante jetzt eh: - Dem Nutzer bei jedem richtungsbezogenen-Tag die Richtung 'visualisieren', damit der weiß, worauf sich der Tag bezieht, z.B. durch forward/backward? ;-) - und er muss eine entsprechende Eingabemöglichkeit anbieten. In diesem Zusammenhang könnte man unabhängig von dem OP-Problem darüber nachdenken, dies mit einem Pfeil zu tun. Der könnte für forward/backward die Richtung vom ersten zum letzten Knoten zeigen. Bei rechts/links ergraut man ihn und fügt den zutreffenden senkrechten Pfeil hinzu. Und wenn wir schon dabei sind: Man könnte den User die Richtung von Node, Way oder Relation auch durch Mausziehen entlang des ways eingeben lassen. Zudem müsste er aber bei Deiner Version bei jeder Weg-Änderung (entfernen, hinzufügen, teilen, verbinden)alle entsprechenden Node-Referenzen bearbeiten - da kann er auch bei jeder Richtungsänderung die internen Tags anpassen, fragt sich, was einfacher ist bzw. öfter vorkommt ... Möglicherweise lässt sich das auch soweit eindampfen, dass man nur den ersten und den letzten Node angibt. Es könnte aber Gründe geben, warum man dies beim Way nicht getan hat. Dieselben Gründe könnten auch dagegen sprechen, beim Tag ebenso zu verfahren. Ein Way führt nunmal über alle Nodes (wo z.B. ja auch andere Wege abgehen können), daher müssen ja auch alle Nodes enthalten sein. Für die Richtung würden zwar die End-Notes ausreichen, dann muss aber bei jeder Node-Änderung entsprechender Zusatz-Aufwand betrieben werden - Alternative s. o.. Fazit: Der notwendige Editor-Aufwand wird nur vom Umdrehen der Tag-Richtung zur Visualisierung und Eingabe-Möglichkeit verlagert - erforderlich ist er immer. Das Verschieben der Richtungsinformation in den 'internen' Daten-Bereich erfordert aber wegen der Tag-Konzept-Änderung zusätzlich noch eine API-Änderung. Hat man damit viel gewonnen? Ja! Man würde die Richtung von Tags und Routen-Relationen von der Richtung des Weges (der Wege) abgekoppeln. Ein Umkehren des Weges dreht nicht gleichzeitig die Tags um und Relationen werden nicht mehr
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 19.07.2010 23:58, schrieb Tirkon: Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall helfen Nur mal aus Interesse (bitte nicht als Kritik missverstehen): würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann man ja in beiden Richtungen drauf.. Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und solchen, deren Mittellinie schon abgefahren ist? Es ist hier schwer die Grenze zu ziehen, denke ich. Angenehmer wäre ein definiertes Taggingschema für Richtungsabhängige Tags, z.B. durch vier Namensräume in den Tags: right, left, forward, backward. Die Tags könnten dann so aussehen: forward:maxspeed=30 right:parking=yes es ist dann klar, dass bei einer Richtungsänderung aus allem was mit forward: getaggt ist ein backward werden muss. Leider ist forward:maxspeed weiter von maxspeed entfernt als maxspeed:forward, weshalb das letztere häufige verwendet wurde. Generell wäre es möglich die definition von right, left, forward und backward von der Wegrichtung zu lösen: Wenn ein Tag direction vorhanden ist, wird der statt der eigentlichen Weg-Richtung verwendet. Was direction jetzt genau enthält bleibt zu Diskutieren: Eine Himmelsrichtung, eine Node-Nummer, einen Ortsnamen - sexy wäre das schon: direction=Mainz maxspeed:forward=120 maxspeed:backward=100 Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 21. Juli 2010 10:16 schrieb Peter Körner osm-li...@mazdermind.de: es ist dann klar, dass bei einer Richtungsänderung aus allem was mit forward: getaggt ist ein backward werden muss. Leider ist forward:maxspeed weiter von maxspeed entfernt als maxspeed:forward, weshalb das letztere häufige verwendet wurde. Ich glaube maxspeed:forward ist auch ein gutes Stück tagging nach dem Editor (JOSM). Dort sind die taggingvorschläge wenn man händisch arbeitet alphabetisch geordnet. Und irgendwie fange ich bei der Eingabe immer mit maxpeed an um dann eventuell eine Richtung zu ergänten. Außerdem bleibt so (aufgrund der alphabetischen Ordnung der Tags durch den Editor) Zusammen was zusammen gehört: maxspeed:forward und maxspeed:backward. Mittlerweile hängen an Elementen teilweise so viele Tags, dass es man leicht etwas übersieht, wenn der Namensraum die Dinge nicht zusammen hält. Deshalb werde ich, bis auf weiteres, das vorangestellte maxspeed: verwenden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Hallo. Am Mittwoch 21 Juli 2010, 10:16:26 schrieb Peter Körner: Am 19.07.2010 23:58, schrieb Tirkon: Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall helfen Nur mal aus Interesse (bitte nicht als Kritik missverstehen): würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann man ja in beiden Richtungen drauf.. Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und solchen, deren Mittellinie schon abgefahren ist? Es ist hier schwer die Grenze zu ziehen, denke ich. Ich hab keine praktischen Erfahrungen mit dem Linienbündel-Vorschlag, aber meine Trennung wäre in etwa so: Gibt es irgend etwas, das ich mit normalen Tags an einem normalen Way nicht darstellen kann, dann sollte man beide Richtungen erfassen. Ein Feldweg ist üblicherweise nichts wo es asymmetrische Geschwindigkeitsbeschränkungen gibt. Angenehmer wäre ein definiertes Taggingschema für Richtungsabhängige Tags, z.B. durch vier Namensräume in den Tags: right, left, forward, backward. Die Tags könnten dann so aussehen: forward:maxspeed=30 right:parking=yes Du hast wohl das überlesen was damals dazu geführt hat, dass man ein komplexeres Modell gebraucht hat: Mehrere Dinge entlang der Fahrbahn. Also sowas wie: zwei Fahrbahnen, eine Rechtsabbiegerspur, ein Parkstreifen und ein Radweg. Alles physisch auf der Fahrbahn, daher idealerweise ein Objekt. Nur wechselt der Radweg mal vor und mal hinter den Parkstreifen. Das wird mit den genannten Tags echt übel umständlich. Wenn ein Tag direction vorhanden ist, wird der statt der eigentlichen Weg-Richtung verwendet. Was direction jetzt genau enthält bleibt zu Diskutieren: Eine Himmelsrichtung, eine Node-Nummer, einen Ortsnamen - sexy wäre das schon: direction=Mainz maxspeed:forward=120 maxspeed:backward=100 Wir kommen an der Weg-Richtung nicht vorbei, auch das hatten wir schon mehrfach. Es gibt Ring-Straßen, die im Extremfall in alle Himmelsrichtungen führen und es ist wenig sexy, bei jedem Teilabschnitt einer Ringstraße eine andere Himmelsrichtung anzugeben. Das blickt auch keiner mehr. Gruß, Bernd -- I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex. - Jack Handey signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Peter Körner osm-li...@mazdermind.de wrote: Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall helfen Man beachte den Konjunktiv könnten. Nur mal aus Interesse (bitte nicht als Kritik missverstehen): würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann man ja in beiden Richtungen drauf.. Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und solchen, deren Mittellinie schon abgefahren ist? Es ist hier schwer die Grenze zu ziehen, denke ich. Man beachte den Konjunktiv könnten. Ich bin mir bewusst, dass Linienbündel nur in vielen, aber nicht in allen Fällen helfen und daher auch keine Allheilmittel sind, sondern nur eine Milderung des Problems darstellen. Zudem können sie die Sache durchsichtiger machen. Denn ein Tag auf der richtungsgebundenen Fahrspur ist suggestiver, als forward und backward. Es bleibt aber trotz Linienbündel nach einer Lösung zu suchen. Die komplexen Einzelheiten der Linienbündel bringen unser Kernproblem hier nicht weiter. Angenehmer wäre ein definiertes Taggingschema für Richtungsabhängige Tags, z.B. durch vier Namensräume in den Tags: right, left, forward, backward. Die Tags könnten dann so aussehen: forward:maxspeed=30 right:parking=yes es ist dann klar, dass bei einer Richtungsänderung aus allem was mit forward: getaggt ist ein backward werden muss. Leider ist forward:maxspeed weiter von maxspeed entfernt als maxspeed:forward, weshalb das letztere häufige verwendet wurde. Alles soweit klar. Nur hat das eben den Nachteil, dass dies Alles mit der Richtung des Ways steht und fällt mit allen Problemen, die ich schon im Ursprungsposting beschrieben habe. Darum wäre es sinnvoll, Folgendes zu tun: Generell wäre es möglich die definition von right, left, forward und backward von der Wegrichtung zu lösen: Wenn ein Tag direction vorhanden ist, wird der statt der eigentlichen Weg-Richtung verwendet. Was direction jetzt genau enthält bleibt zu Diskutieren: Genau, jedes Tag und jede Routen-Relation müsste seine eigene Richtung haben. Aber genau hier liegt der Hund begraben. Wie will man diese Richtung festlegen und in der Datenbank unterbringen? Eine Himmelsrichtung Himmelsrichtung habe ich auch drüber nachgedacht. Aber dann muss man eine Grenze setzen, wo die Richtung umkippt. Wenn ein Way nahe an dieser Grenze verläuft, dann kann die Richtung durch Ziehen von Knoten im Way umkippen. eine Node-Nummer Das ist es! :-) Bisher kannte ich von XML nur den Namen und habe gerade erst etwas darüber gelesen. Ich habe mit JOSM einen Way mit drei Nodes erstellt: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='-4' visible='true' lat='-1.3351572879110518' lon='-1.466542772416855' / node id='-2' visible='true' lat='-0.022631832319151942' lon='-0.21726559591360814' / node id='-1' visible='true' lat='0.31231774745922347' lon='-0.8962205831436337' / way id='-3' action='modify' visible='true' nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed:backward' v='70' / tag k='maxspeed:forward' v='50' / /way /osm und dann die Richtung umgedreht: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='-4' visible='true' lat='-1.3351572879110518' lon='-1.466542772416855' / node id='-2' visible='true' lat='-0.022631832319151942' lon='-0.21726559591360814' / node id='-1' visible='true' lat='0.31231774745922347' lon='-0.8962205831436337' / way id='-3' action='modify' visible='true' nd ref='-4' / nd ref='-2' / nd ref='-1' / tag k='maxspeed:backward' v='70' / tag k='maxspeed:forward' v='50' / /way /osm Das OSM Format gibt offenbar die Richtung eines Ways durch die Abfolge der Node-Nummern an. Denn das ist das Einzige, was sich bei einer Umkehr des Weges ändert. Jetzt müsste man statt backward und forward ebenfalls die Richtung durch die Abfolge der Node Nummern angeben. Ich will das Ganze mal mit Richtung eines Tags titulieren. Jetzt kann man die Richtung des Weges umdrehen, wie man lustig ist, ohne die Richtung des Tags zu ändern. Wie gehabt: Ich habe gerade das erste Mal etwas über XML gelesen. Was jetzt kommt, ist also mit Sicherheit nicht richtig. Aber entfernt könnte das Ganze dann so aussehen: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='-4' visible='true' lat='-1.3351572879110518' lon='-1.466542772416855' / node id='-2' visible='true' lat='-0.022631832319151942' lon='-0.21726559591360814' / node id='-1' visible='true' lat='0.31231774745922347' lon='-0.8962205831436337' / way id='-3' action='modify' visible='true' nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='70' / nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='50' / nd ref='-4' / nd ref='-2' / nd ref='-1' / /way /osm Ausgesagt werden soll, dass sich die jeweilige Maxspeed auf die jeweilige Richtung bezieht.
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 19. Juli 2010 18:38 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Ways werden ständig z.T. auch automatisch gedreht, z.B. auch beim Kombinieren von ways. Bei Fließgewässern braucht man die Richtung auch (neben oneways) und zumindest früher auch bei den coastlines und den Multipolygonen (ob das noch gilt weiss ich bei der coastline nicht). Vermutlich wird es noch mehr Szenarien geben wo die Richtung eine Rolle spielt. Zu versteckt sollte das also nicht sein. Auch Geschwindigkeitsbeschränkungen auf Straßen gelten nicht immer für beide Richtungen. Wie man hier ohne Richtungsangabe auskommen soll, sehe ich nicht. Veränderbarkeit der Richtung hin oder her. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Falk Zscheile falk.zsche...@googlemail.com wrote: Am 19. Juli 2010 18:38 schrieb M?rtin Koppenhoefer dieterdre...@gmail.com: Ways werden ständig z.T. auch automatisch gedreht, z.B. auch beim Kombinieren von ways. Bei Fließgewässern braucht man die Richtung auch (neben oneways) und zumindest früher auch bei den coastlines und den Multipolygonen (ob das noch gilt weiss ich bei der coastline nicht). Vermutlich wird es noch mehr Szenarien geben wo die Richtung eine Rolle spielt. Zu versteckt sollte das also nicht sein. Auch Geschwindigkeitsbeschränkungen auf Straßen gelten nicht immer für beide Richtungen. Wie man hier ohne Richtungsangabe auskommen soll, sehe ich nicht. Veränderbarkeit der Richtung hin oder her. Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall helfen, weil es dann nur noch Einbahnstraßen gibt. Die Maxspeed kann dann für jede Linie=Fahrtrichtung getrennt gemappt werden. Ein Tauschen dieser richtungsabhängigen Maxspeed ist dann durch Umkehren der Way-Richtung nicht mehr möglich. Auch der linke und rechte Fahrradweg ist damit kein Problem mehr. Ich sehe momentan - abgesehen von der Fahrtrichtung - nur noch sehr wenige und seltene notwendige Richtungseigenschaften. Aber bis zu einer praktikablen Lösung für die Linienbündel ist noch ein weiter Weg. Aber auch hier ein Argument mehr dafür, eine solche zu finden. Da die Richtung des Weges dann die Fahrtrichtung (oder Fließrichtung) angibt (wie jetzt auch schon bei Autobahnen), ist dies auch für einen Anfänger intuitiv einsehbar und er wird sie daher - abgesehen von Vandalismusabsichten - auch nicht umdrehen. Selbst eine versehentliche Umkehr fällt dann sofort auf und kann korriert werden. All dies ist bei Straßen mit zwei Fahrtrichtungen und ohne Linienbündel nicht der Fall. Und was für Anfänger gut ist, macht die Sache auch für Fortgeschrittene übersichtlicher. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 02:21, schrieb Tirkon: Zwei Lösungsvorschläge: Vorschlag 1: Bei jeder Umkehr der Straßenrichtung, sei es von Hand oder bei Vereinigungen gegenläufiger Straßen dreht der Editor automatisch auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Moinsen, dies macht JOSM bereits. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Hallo, Tirkon wrote: Wenn eine Funktion so zerstörerisch sein kann und sämtlichen sorgfältig erstellten Richtungstaggings und -Relationen quasi den Arsch unter den Füßen wegzieht Du meinst den Boden unter den Fuessen wegzieht? JOSM ist ja mittlerweile so schlau und empfiehlt beim Aendern der Richtung eines Ways, auch die entsprechenden richtungsabhaengigen Tags umzudrehen. Persoenlich finde ich, dass richtungsabhaengige Tags sowieso asking for trouble sind, insbesondere alles, was irgendwie left und right enthaelt. Auch dem backward und forward als Rollen in Relationen stehe ich eher kritisch gegenueber, ich finde, dadurch wird eine unnoetig hohe Komlpexitaet eingefuehrt. Mir waere es lieber, *wenn* man eine solche Unterscheidung unbedingt modellieren will, dass man dann fuer jede Richtung eine Relation anlegt, aehnlich bei beim OePNV. Schlimmer noch: Was ist, wenn nach einer versehentlichen Änderung jemand Anderes richtungsabhängige Dinge taggt. Dann sind die einen richtig herum und die anderen falsch. Deswegen sollten richtungsabhaengige Tags auf ein absolutes Minimum reduziert werden. oneway ist ok, das ist auch in der Karte durch einen Pfeil sichtbar, da passieren nicht so viele versehentliche Fehler. Bei allem anderen sollte man mal gruendlich nachdenken, ob es nicht andere Moeglichkeiten gibt, als sich an der Richtung des Ways zu orientieren. Vorschlag 1: Bei jeder Umkehr der Straßenrichtung, sei es von Hand oder bei Vereinigungen gegenläufiger Straßen dreht der Editor automatisch auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Wie gesagt, mit Ausnahme der forwards und backwards (glaub ich) tut JOSM das ja bereits. Wobei nicht in allen Edit-Szenarien sichergestellt ist, dass JOSM ueberhaupt Kenntnis von einer Relation hat, in der der Way enthalten ist. Vorschlag 2: Die Richtung der Straße könnte bei neuen way-Objekten - zweckmässigerweise zwischen zwei Knotenpunkten ohne Richtungsänderung - entweder vom Editor oder der Datenbank automatisch festgelegt werden und wäre dann für niemanden mehr umkehrbar. Bei einer Vereinigung von zwei gegenläufigen Straßen durch Auflösung einmes Knotenpunktes drehen Editor oder Datenbank (je nachdem, wer oben für diese Aufgabe zuständig war) auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Die Datenbank waere das bestimmt nicht, denn sie kuemmert sich nicht um den Inhalt von Tags. Automatisch festgelegte Way-Richtungen finde ich nicht so gut, weil das dazu fuehren wuerde, dass wir deutlich mehr oneway=-1 in der Datenbank haetten, und ich bin eigentlich ganz froh, dass das derzeit die absolute Ausnahme ist. Welcher von beiden wäre zu bevorzugen? Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die Editoren - von denen es viele gibt, und von denen nie alle sich einig sein werden - Benutzern Vorschriften machen, sollte man sich Methoden fuer das Tagging ueberlegen, die weniger fragil sind. Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, ist, die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. Vielleicht in einem Untermenue Advanced... oder sowas. Damit man nicht so leicht versehentlich draufklickt ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 um 07:36 schrieb fx99: In der OSM Darstellung müssen die Punkte in einem Weg eine Ordnung haben, damit man weiß, wie sie zu verbinden sind. Warum? Eigentlich benötigt man eine Richtung nur da, wo man eine Richtung benötigt ;-) Dabei gibt es bei einem nicht in sich geschlossenen genau zwei Möglichkeiten: A-B-C-D oder D-C-B-A, was dann als Richtung bezeichnet wird. Dort wo nötig, sicher sinnvoll, aber sonst? In vielen Fällen ist die Richtung ohne jede Bedeutung, s.o. in manchen Fällen (z.B. Flüsse) wird eine sinnvolle Konvention festgelegt. Soweit so gut. Was mich jetzt aber stört, ist, dass an eine oft willkürliche Richtung entscheidenen Eigenschaften durch forward oder backward gekoppelt werden. Dies führt dann zu den oben aufgezählten Problemen. Richtig. Es sollte Regeln geben, an denen man sich orientieren kann, in welche Richtung ein way gedreht sein muss, dass backward und forward richtig interpretiert werden können. Für den destination-Tag bin ich auch auf so ein Problem gestoßen und habe es so gelöst, dass der way immer in Richtung der bedeutsameren (hierarchisch höher stehenden) Straßenart zeigen sollte. Also im Falle einer residental zu einer secondary hin. Vielleicht ist das ein allgemein möglicher Vorschlag? Ich hielt es für wesentlich sinnvoller, diese Eigenschaften durch von der Richtung des Weges unabhängige, absolut gültige Beschreibungen ergänzt werden, wie z.B. Himmelsrichtung oder andere geographische Beschreibungen ( von A nach B etc. ). s.o. ich denke an die Richtung hin zum hierarchisch höher wertigen highway-Klassifizierung. (aber nur, wenn der forward-backward-tag überhaupt genutzt wird!) Wenn zwei gleichwertige ways aufeinander stoßen, dann sollte die Richtung _aus_ der Richtung kommen, die weniger bedeutsam ist. (Z.B. wenn eine secondary aus einem Wohnviertel herausführt und auf eine secondary-Bundesstraße führt) Bei der Bundesstraße bin ich mir nicht sicher, ob es wieder relevant ist... Damit wären auch die meisten Probleme der unkontrollierten Richtungsumkehr verschwunden. Solange man diese Regeln, wie der way auszurichten ist, kennt udn diese beachtet. Aber so ist es ja immer in OSM. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 um 10:47 schrieb Frederik Ramm: Vorschlag 2: Die Richtung der Straße könnte bei neuen way-Objekten - zweckmässigerweise zwischen zwei Knotenpunkten ohne Richtungsänderung - entweder vom Editor oder der Datenbank automatisch festgelegt werden und wäre dann für niemanden mehr umkehrbar. Bei einer Vereinigung von zwei gegenläufigen Straßen durch Auflösung einmes Knotenpunktes drehen Editor oder Datenbank (je nachdem, wer oben für diese Aufgabe zuständig war) auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Die Datenbank waere das bestimmt nicht, denn sie kuemmert sich nicht um den Inhalt von Tags. Automatisch festgelegte Way-Richtungen finde ich nicht so gut, weil das dazu fuehren wuerde, dass wir deutlich mehr oneway=-1 in der Datenbank haetten, und ich bin eigentlich ganz froh, dass das derzeit die absolute Ausnahme ist. +1 Welcher von beiden wäre zu bevorzugen? Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die Editoren - von denen es viele gibt, und von denen nie alle sich einig sein werden - Benutzern Vorschriften machen, sollte man sich Methoden fuer das Tagging ueberlegen, die weniger fragil sind. Stimmt auch wieder. Doch hast Du einen Vorschlag, wie dieses Tagging aussehen könnte? Und jetzt kommt nicht wieder mit Relationen um das einfache Taggging zu ersetzen. Bitte. Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, ist, die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. Vielleicht in einem Untermenue Advanced... oder sowas. Damit man nicht so leicht versehentlich draufklickt ;) +1 Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Erst einmal bin ich dankbar, dass das Problem von den bisher Mitpostenden als solches erkannt wurde. Beim ersten Anlauf hier vor einiger Zeit hatte ich es offensichtlich nicht deutlich machen können und war nicht erfolgreich. Frederik Ramm frede...@remote.org wrote: Wenn eine Funktion so zerstörerisch sein kann und sämtlichen sorgfältig erstellten Richtungstaggings und -Relationen quasi den Arsch unter den Füßen wegzieht Du meinst den Boden unter den Fuessen wegzieht? Eigentlich hätten es die Füße sein sollen, die - ähnlich wie bei Glatteis - unter dem Allerwertesten weggezogen werden. Aber Deine stubenreine Formulierung passt natürlich auch. Deswegen sollten richtungsabhaengige Tags auf ein absolutes Minimum reduziert werden. oneway ist ok, das ist auch in der Karte durch einen Pfeil sichtbar, da passieren nicht so viele versehentliche Fehler. Bei allem anderen sollte man mal gruendlich nachdenken, ob es nicht andere Moeglichkeiten gibt, als sich an der Richtung des Ways zu orientieren. Hmm, das klingt als ob Du da einen Ansatz im Ärmel hättest. Linienbündel würden in vielen Fällen helfan, aber da gibt es nur einige Ansätze mit teilweise aufwendigen Relationen aber kein zu Ende gedachtes Konzept. Und ohne entsprechenden Editor zum Zusammenklicken der Spuren nur ein Fall für Spezialisten. Welcher von beiden wäre zu bevorzugen? Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die Editoren - von denen es viele gibt, und von denen nie alle sich einig sein werden - Benutzern Vorschriften machen, sollte man sich Methoden fuer das Tagging ueberlegen, die weniger fragil sind. Das wäre natürlich viel besser, als meine Vorschläge. Auch das klingt, als wenn Du noch ein Ass auzuspielen hättest. Es könnte vielleicht ein durchsichtiges und einheitliches Mittel geben, das immer funktioniert und jedem Tag und jeder Relation eine Richtung aufprägen könnte. In der Praxis könnte das so aussehen, dass der Editor eine Richtung vorgibt, die man umdrehen kann - genau so, wie es derzeit bei den Wegen geschieht. Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, ist, die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. Vielleicht in einem Untermenue Advanced... oder sowas. Damit man nicht so leicht versehentlich draufklickt ;) Wobei zumindest Potlatch als verbreitet genutzter Editor da auch mitspielen müsste. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Frederik Ramm glaubte zu wissen: Tirkon wrote: Wenn eine Funktion so zerstörerisch sein kann und sämtlichen sorgfältig erstellten Richtungstaggings und -Relationen quasi den Arsch unter den Füßen wegzieht Du meinst den Boden unter den Fuessen wegzieht? JOSM ist ja mittlerweile so schlau und empfiehlt beim Aendern der Richtung eines Ways, auch die entsprechenden richtungsabhaengigen Tags umzudrehen. Vor einigen Wochen war JOSM dabei richtig konsequent und wollte mir aus uploaded_by ein downloaded_by machen ;-) flo -- Statt daß er endlich einmal ein friedliches Leben führen könnte, wird er immer wieder von ehrgeizigen und sich selbst überschätzenden Grünschnäbeln, die gerade mal gelernt haben einen Colt zu laden, dreist angemacht.[Sepp Neuper in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.07.2010 20:59, Florian Gross wrote: JOSM ist ja mittlerweile so schlau und empfiehlt beim Aendern der Richtung eines Ways, auch die entsprechenden richtungsabhaengigen Tags umzudrehen. Vor einigen Wochen war JOSM dabei richtig konsequent und wollte mir aus uploaded_by ein downloaded_by machen ;-) haha! Ähnliches hatte ich auch schon - aus der Westendstraße sollte eine Eastendstraße werden :-D Nicht schlecht ;-) - - Fips - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxDfEsACgkQnHVyAFIfTkEfTwCcDCbDLIrmUBqoXbBL/OLvGjch 8doAnRD/2S5hktl9f6YT22wS9xm83M8P =zVG5 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am Montag 19 Juli 2010, 00:12:27 schrieb Fips Schneider: Ähnliches hatte ich auch schon - aus der Westendstraße sollte eine Eastendstraße werden :-D Nicht schlecht ;-) Das widerrum wäre (wenn es denn stimmt) ein bösartiger Bug, denn die Himmelsrichtung eines Tags soll sich ja eben grade *NICHT* ändern. Wenn das von dir jetzt also nicht nur daher gesagt war um Öl ins Feuer zu gießen, mach dafür bitte ein Ticket auf, damit das geändert wird. Gruß, Bernd -- Lautsprecher verstärken die Stimme, aber nicht die Argumente. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Moin, welchen Sinn hat die Richtungsumkehrfunktion in OSM? Mit forward und backward im Gepäck kann jeder für jedes Element in OSM eine Richtung beschreiben - sei es durch Tagging oder Relationen. Ich frage mich aber, wieso es sinnvoll sein kann, alle sorgfältig zusammengetragenen richtungsabhängigen Dinge mit einem Schlag umzukehren? Zudem erkennen Anfänger die Richtungsfunktion anfänglich häufig nur als Fahrtrichtungsangabe, so dass sie diese nur für Einbahnstraßen und Kreisverkehre als relevant erkennen. Nun macht er seine ersten Gehversuche im OSM Editor durch Ändern der Fahrtrichtung. Die lässt sich so schön mit einem Klick auf das präsente Icon umkehren. Ahja, die Fahrtrichtung braucht man für Einbahnstra0en und für Kreisverkehre. Hmmm, bei Straßen mit Fahrbahnen für zwei Richtungen braucht man keine Fahrtrichtung. Also kann ich ich hier beliebig rumprobieren. Auch beim Vereinigen erklärt JOSM, dass er einige Richtungen umdreht. Hmmm, ist ja keine Einbahnstraße involviert, also soll er meinetwegen umdrehen. Erst im Stadium des fortgeschrittenen Taggings bemerkt der Anfänger bestürzt, dass der Richtungspfeil nicht nur zum Darstellen der Fahrtrichtung dient. Bis dahin hat er aber schon einige Straßen versehentlich umgedreht. Wenn eine Funktion so zerstörerisch sein kann und sämtlichen sorgfältig erstellten Richtungstaggings und -Relationen quasi den Arsch unter den Füßen wegzieht und zudem Anfänger dazu einlädt, es als erstes dankbares und meintlich harmloses Probierobjekt zu benutzen: Welchen Sinn kann so ein Instrument haben? Zudem fallen solche Richtungsänderungen erst nach eingehender Prüfung auf. Bei bloßen Drüberschauen nimmt man keinen Fehler wahr. Schlimmer noch: Was ist, wenn nach einer versehentlichen Änderung jemand Anderes richtungsabhängige Dinge taggt. Dann sind die einen richtig herum und die anderen falsch. Selbst der Ortskundige hat das Alles nicht im Kopf und kann in solch einem Falle die ganze Stra0e noch einmal in beiden richtungen abfahren und auf die Richtigkeit sämtlicher (nun beschädigter) Relationen und Tags überprüfen, wenn er den Fehler überhaupt wahrgenommen hat - und das wegen eines versehentlichen Klicks. Nein, momentan sehe ich für die Umkehrfunktion keine einzige sinnvolle Anwendung, die nicht mit forward oder backward zu erschlagen wäre - außer Vandalismus. Wenn der dann auch noch - insbesondere für Anfänger - so leicht versehentlich begangen werden kann, dann hat die Funktion jede Daseinsberechtigung verloren - und zwar für jeden User. Daher brauchen wir in diesem Zusammenhang nicht über Userlevel und Schreibrechte nachzudenken. Zwei Lösungsvorschläge: Vorschlag 1: Bei jeder Umkehr der Straßenrichtung, sei es von Hand oder bei Vereinigungen gegenläufiger Straßen dreht der Editor automatisch auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Vorschlag 2: Die Richtung der Straße könnte bei neuen way-Objekten - zweckmässigerweise zwischen zwei Knotenpunkten ohne Richtungsänderung - entweder vom Editor oder der Datenbank automatisch festgelegt werden und wäre dann für niemanden mehr umkehrbar. Bei einer Vereinigung von zwei gegenläufigen Straßen durch Auflösung einmes Knotenpunktes drehen Editor oder Datenbank (je nachdem, wer oben für diese Aufgabe zuständig war) auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Sieht jemand Fälle, in denen diese Lösungsmöglichkeiten versagen würden? Welcher von beiden wäre zu bevorzugen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
