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

[Georg Feddern]

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