[Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?

[Tirkon]

Erst einmal vielen Dank für die technischen Klärungen. :-)

Georg Feddern <news2 at 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 hierdurch
beschädigt. Zudem kann der User beim jetzigen System keine beliebigen
richtungsabhängigen Tags benutzen, wenn er die Konsistenz der
Datenbank nicht gefährden will. Er kann also auch keine neuen Tags
erfinden und ist damit in ein Korsett geschnürt. Das jetzige Umdrehen
von bekannten populären Tags durch den Editor kann daher nur eine
Notlösung sein. Denn sobald andere Tags verwendet werden, scheitert
das Ganze.

Egal ob man das Ganze nun Forward oder Flag nennen will oder ob man
eine Abfolge von Knoten verwendet: Alles ist dasselbe Prinzip und die
Art der Verwirklichung daher Schall und Rauch. Und das Prinzip ist es,
die Richtung des Tags und der Relationen von der Richtung des Weges
abzukoppeln. Und das ist der entscheidende Unterschied zum jetzigen
Verfahren. Siehst Du eine Möglichkeit, all dies ohne Verlagerung der
Tagrichtung in den internen Bereich zu realisieren? Vielleicht geht
das ja und ich sehe es nicht. 

Der von Dir ins Feld geführte Aufwand beim Ändern sollte auf jeden
Fall in eine Richtung zielen, welche das !!Lesen!! der Datenbank
optimiert. Insofern wäre er nicht vergeudet, sondern würde den
Gesamtaufwand verringern (siehe oben). Wie schon gesagt: Wegen
fehlender Hintergrundkenntnisse kann ich da bei der Ausführung nicht
mitreden. Insofern ist der von mir skizzierte Weg nur ein möglicher,
das Prinzip verdeutlichender und natürlich bezogen auf den Aufwand
möglicherweise suboptimal. Da hast Du vollkommen Recht.

Man könnte sich überlegen - sofern notwendig -, diese Implementierung
auf die Warteliste für API 0.7 zu setzen und somit eine eigene API zur
Lösung des Problems verhindern.