Hallo, durch Urlaub meinen eigenen Senf hierzu mit einem Monat Verspaetung :-)
On Friday, 22 August 2008 12:48:13 +0200, Bernd Wurst <[EMAIL PROTECTED]> writes: [...] > Wir haben jetzt diverse Dinge, die wir mit dem aktuellen Tagging-Schema > nicht > richtig abbilden koennen. Seien es Verbote, die gezielt fuer einzelne > Gruppen > gelten oder aufgehoben werden (maxweight=6 / "Anlieger frei"), > Unterschiedliche Hoechstgeschwindigkeiten fuer unterschiedliche Fahrzeuge > (Autos 80, LKW 60) oder aehnliches. > > All das wird dann mit abenteuerlichen Konstruktionen geloest, die oft damit > arbeiten, dass ein Schluessel oder Wert in mehrere Teile zerlegt werden > soll. > Dass das Fehleranfaellig und ungleich schwieriger zu verarbeiten ist, ist > wohl > klar. > > > Die Loesung der Probleme waere IMHO damit getan, dass man Tags > Baumstruktur-artig setzen kann. Damit waere es moeglich, z.B. ein > access=destination unterhalb eines maxweight=6 zu setzen. Oder ein > maxspeed=60 unterhalb eines hgv=yes/destination. Statt gleich ganze Baeume und damit Hierarchien aufzumachen, wuerde ich es bei einer Tag-Gruppe belassen. Sieht man sich einmal GDF an, so werden dort die Attribute in "Simple Attribute" und "Composite Attributes" unterschieden, d.h. man hat eine einzige Ebene. Und wenn ich die obigen Beispiele sehe, reicht eine Gruppierungsebene aus. Und gegen die Hierarchie von Attributen spricht auch, dass es nicht eindeutig ist, welches Attribut nun unter welches gehoert. Kommen nun die Zusatzschilder "fuer Lkw ab 7,5t" (hgv) _unter_ das maxspeed=60 oder so wie im obigen Beispiel das maxspeed=60 unter das "fuer Lkw ab 7,5t"? ;-} Wenn man sich auf eine Ebene beschraenkt und man die momentanen einfachen Tags als Sonderfall einer Tag-Gruppe mit einem einzelnen Tag auffasst, ist die Erweiterung der API als auch der Schnittstelle deutlich einfacher durchzufuehren. Uebrigens kann man Attributgruppen bereits mit dem momentanen Datenmodell angeben, indem man eine oder mehrere Relationen erstellt, dort hinein den Node bzw. Way packt und dann bei dieser Relation nur die jeweiligen Attribute hinschreibt. Aber nachdem ich dies einmal sowohl mit Potlatch (im Spielemodus) als auch mit JOSM versucht habe, habe ich diesen Weg schnell wieder aufgegeben, da diese per Relation zugeordneten Tag-Gruppen momentan nicht sehr prominent und uebersichtlich dargestellt werden und somit von einem selbst als auch von anderen Mappern sicher uebersehen und somit zerstoert werden. [...] On Friday, 22 August 2008 13:07:38 +0200, Frederik Ramm <[EMAIL PROTECTED]> writes: > > Bernd schrieb: > > Da die API 0.6 seit einer kleinen Ewigkeit vorbereitet wird und man > > aufgrund > > der nicht vorhandenen Fortschrittsbekundungen von einem Rohrkrepierer > > ausgehen muss (Sorry, Frederik), waere das IMHO eine Sache, die > > eingefuehrt > > werden sollte. > > Du meinst, wenn es eh nix wird, kann man es auch noch mit komplizierten > Features ueberfrachten ;-) "Il semble que la perfection soit atteinte non quand il n'y a plus rien `a ajouter, mais quand il n'y a plus rien `a retrancher." "Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufuegen gibt, sondern wenn man nichts mehr weglassen kann." (Antoine de Saint-Exupery) > Ich sehe bei Baumstruktur-Tags einen Editor-Alptraum voraus. Ich will > auf jeden Fall nicht der sein, der das implementieren muss ;-) Daher wuerde ich das auch nicht als Baum(-Hierarchie), sondern nur als Tag-Gruppe mit genau einer (weiteren) Ebene aufziehen. Dies duerfte IMHO voll ausreichend sein ... zumindest lebt GDF mit diesem Konstrukt schon viele Jahre ganz gut und ausreichend, um Beschraenkungen bzgl. Transportmittel, Zeit, Richtung etc. oder Plazierungen von Objekten bzgl. anderer zu beschreiben. Gruss, -bernd _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
