> Ich denke, man könnte es noch wuppen, da mit der API 0.6 alle > Basisvoraussetzungen vorhanden sind, die wir bräuchten. Man müsste sich > lediglich > darauf einigen, dass man keine Ways mehr in die Relationen packt, sondern nur > noch Nodes. Die Verbindung dieser Nodes wird dann über die Wegteile, die > dazwischenliegen, automatisch vorgenommen.
So einen ähnlichen Vorschlag hat glaub ich Stefan de Koning schon mal auf osm-talk/osm-dev gemacht. WIMRE ging er sogar soweit, die Wege komplett abzuschaffen, und stattdessen auch über Relationen darzustellen. > > Und Geschwindigkeitsbegrenzungen wären dann sogar gerichtet möglich, > weil man die nicht mehr an den Way packt, sondern in eine Relation mit > "type=maxspeed" mit "maxspeed=70" und mindestens den Knoten "from" und "to" > und > sämtliche Knoten, an denen Wege einmünden, als "via". Oder sowas in der > Richtung. Die Richtungsabhängigkeit haben wir ja jetzt auch schon; man kann ja maxspeed:forward/backward verwenden und sich auf die Richtung des Wegs beziehen. Außerdem sollte bei Geschwindigkeiten die Richtungsabhängigkeit nicht der Normalfall sein, weil man sonst für die meisten Geschwindigkeitsbegrenzungen zwei Relationen bräuchte. > > Komplett umgesponnen könnte man sogar fast sagen, dass Ways immer > attributlos sein könnten oder zumindest nur essentielle Attribute wie > "highway=primary" enthalten müssten, während alles andere wie z. B. Namen > eigentlich > nichts an Ways, sondern nur an Relationen wie oben beschrieben hängen > müssten. In meinen Augen würde ein solches Schema die Datenbank richtig > aufräumen, weil pro Relation immer nur ein Attribut bzw. nur zusammenhängende > Attribute gelten würden. > > Eine mögliche Modellierung mal am Beispiel Brücken: > > A---B-C---D > > Nach diesem Schema müsste ein Way nicht auf drei Ways aufgeteilt werden, > nur weil mittendrin (zwischen Node B und Node C) eine Brücke ist. Einfach > eine Relation "type=bridge","level=1", die die Knoten B und C enthält, > fertig. > > X > | > A--B---C--D > | > Y > > (A-D überquert X-Y). Hier genauso: Nur die Relation > "type=bridge","level=1". Dass man nicht vom Weg AD auf XY abbiegen kann, ist > durch einen > fehlenden gemeinsamen Knoten ausreichend modelliert. Hmm... das würde auch keine Probleme machen, wenn man zwischendrin neue Nodes einfügt, solange es sich um einen zusammenhängenden Weg handelt, oder? Es wird ja nur "from" und "to" angegeben, und nicht alle Knoten in dem Weg. > > Eine Umstellung des bisherigen Schemas wäre gar nicht so aufwändig, wenn > ich sehe, wie viele Robots schon herumschwirren, dürfte sich sicherlich > jemand finden, der auch hierfür einen Robot schreibt. Ich glaube, dass das soviele Umstellungen erfordern würde (Renderer/Router anpassen, einfache Editiermöglichkeiten für "Streckenbezogene Attribute" schaffen, evtl. auch Optimierungen in der Datenbank für die dann viel häufigeren Relationen), dass man das am besten nicht schrittweise umstellen würde, sondern in einem Rutsch, wie bei der Umstellung von API 0.5 auf 0.6. > > Grüße > Andreas > > > P.S.: Um es vorwegzunehmen: Das von mir geschriebene ist kein ausgefeilter > Plan, aber da ich diesen Gedanken schon häufiger hatte, weil Wege immer > kleiner und kleiner werden, was ich für sehr ungünstig halte, würde ich > das trotzdem gern als Diskussionsgrundlage mal hier in den Raum werfen. Was > haltet ihr davon, wo würdet ihr weitere Verbesserungen sehen? Ich finde das einen interessanten Ansatz, der auch helfen würde, die Trennung zwischen logischen und physikalischen Attributen voranzutreiben. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
