[Talk-de] Vorschlag neuer Geometrie (relationen)-Typ: node-relation

Bernd Raichle bernd at dante.de
Mo Jul 14 12:03:19 UTC 2014


On Thursday, 10 July 2014 15:41:03 +0200,
Martin Koppenhoefer <dieterdreist at gmail.com> writes:
 > Am 10. Juli 2014 14:55 schrieb Tobias Knerr <osm at 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




Mehr Informationen über die Mailingliste Talk-de