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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
