On Thursday, 10 July 2014 15:41:03 +0200,
Martin Koppenhoefer <dieterdre...@gmail.com> writes:
> Am 10. Juli 2014 14:55 schrieb Tobias Knerr <o...@tobias-knerr.de>:
>
> > Dein Beispiel mit den Verkehrsschildern ist zudem nicht sinnvoll,
> > da – wie bereits von anderen erwähnt – hier schon eine
> > dokumentierte Lösung existiert: Semikolons. Da ist die Nutzung
> > einer Relation keineswegs bequemer.
>
> Das Problem ergibt sich in der Tat nicht mit Objekten, die durch
> ein einziges tag beschrieben werden können, er ergibt sich aber,
> wenn man mehrere tags hat, die sich nicht auf alle sondern nur auf
> einen Teil der Objekte beziehen (z.B. Verkehrsschild und
> Tourismushinweiser am selben Mast, aber unterschiedlicher
> operator-tag, vermutlich gibt es bessere Beispiele, das
> Grundproblem sollte aber klar sein).
Das Problem hat man immer, wenn ich mehrere Tags zur Beschreibung
eines Objekts benoetige und diese Tags selbst noch einen "inneren"
Zusammenhang haben. Beispielsweise hat man dies bei den
Zusatzschildern von Verkehrszeichen wie ein allgemeines
Geschwindigkeitsbeschraenkungsschild "120" und ein zweites mit "100",
das nur von 22-6 Uhr gilt. Dies kann man alles irgendwie durch
Ergaenzung des Tag-Keywords (also durch ein neues Keyword) ausdruecken
oder durch eine Strukturierung des Tag-Wertes ... aber so richtig
"natuerlich" ist das alles bei etwas komplizierteren Beschraenkungen
nicht mehr.
In GDF gibt es hierzu die Unterscheidung zwischen Simple Attributes
und Composite Attributes. Dort wird einer Entitaet dann mehrere
Attribute zugewiesen, die wiederum entweder einzelne Simple-Attributes
sind oder die jeweils ein Composite-Attribute bestehend aus einigen
Simple-Attributes sind.
Mit so etwas wie "taggroup" (oder "tagset") als Strukturierung der
bisherigen "flachen" Tag-Menge zu einem Objekt koennte man dies
deutlich einfacher handhaben:
<way id="...">
<nd ref="...">
<nd ref="...">
<taggroup>
<tag k="maxspeed" v="120">
</taggroup>
<taggroup>
<tag k="maxspeed" v="80">
<tag k="time" v="22:00-06:00">
<tag k="vehicle_type" v="hgv">
</taggroup>
</way>
statt wie bisher dies in den Tag-Keys und Tag-Values zu kodieren, also
maxspeed=120
maxspeed:conditional:hgv=80 @ (22:00-06:00)
oder so aehnlich.
Taggroups, die nur aus einem Tag bestehen, kann man wie bisher ohne
die "taggroup" schreiben - das waere gleichzeitig der Weg um das
Protokoll aufwaertskompatibel zu halten.
Der Vorschlag deckt aber nur ab die Eigenschaft _eines_ Objekts zu
beschreiben und nicht die Eigenschaften zweier Objekte ...
> > Das ebenfalls genannte Beispiel, dass ein Objekt an einem Baum
> > (oder einem Mast, einer Mauer, ...) befestigt ist, deckt deine
> > Relation hingegen gar nicht zufriedenstellend ab – dafür bräuchte
> > man eher eine "befestigt an"-Relation mit entsprechender
> > Semantik.
>
>
> Dass beides am selben Mast hängt, könnte man z.B. dadurch mappen,
> dass der node man_made=pole bekommt, und alles was dran hängt dann
> über die Relation angehängt wird. Z.B. auch Ampeln, an denen
> Verkehrsschilder hängen (bzw. hängt Ampel und Schild am selben
> Mast). Ggf. ist die Relation hier noch nicht ausreichend
> spezifiziert/definiert.
... wenn man naemlich genauer hinsieht, redet ihr von zwei
unterschiedlichen Dingen:
1. Wollte ihr die semantische Bedeutung, also eher die Auswirkung von
Verkehrschildern, Ampeln etc. beschreiben, die sich auf die
jeweilige Kreuzung bzw. die nachfolgende Strasse beziehen?
Dann reicht die Repraesentation in einem Objekt (Kreuzung oder
Strasse) und eine Menge von Attributen dieses Objekts aus.
2. Wollt ihr die Existenz von mehren Objekten und deren raeumliche
Beziehung untereinander beschreiben?
Dann benoetigt ihr auch wirklich mehrere Objekte mit eigenen
Attributen und deren Beziehung ("haengt an", "ist oberhalb von")
wird durch eine Relation mit weiteren Attributen der Relation
beschrieben.
In den meisten Faellen reicht 1. aus.
Wenn man etwas detailreicher mappen will, geht es in Richtung 2.,
wobei ich bei den meisten Verkehrschildern auch die semantische
Bedeutung auf die nachfolgende Strecke mit mappen wuerde, da nicht
immer so eindeutig ableitbar ist, bspw. wie weit eine
Geschwindigkeitsbeschraenkung wirklich gilt.
> Mauern sind wieder ein anderes Thema, die werden bisher (und wohl
> auch auf absehbare Zeit) als Linien gezeichnet, mit dem Problem,
> dass die Seiten nicht klar sind (kann man abstrahieren, indem man
> einen leichten Versatz mappt für das gehängte Punkt-objekt, und auf
> die Information verzichten, ob es an der Mauer hängt oder kurz
> davor an einer eigenen Befestigung, meist dürfte das nicht
> interessieren).
Da jede Linie eine _Digitalisierungsrichtung_ aufweist und diese auch
in OSM existiert, gibt es auch hier ein Vorwaerts/Rueckwaerts und ein
Links/Rechts. Man kann also sehr wohl mappen, ob sich etwas links
oder rechts von einer Linie befindet. Nur bei Punkten wird es
schwieriger, aber auch hier koennte man einen Abstand und den
Kompasswinkel (analog zum Heading/Nordwinkel) angeben.
Gruss,
Bernd
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
