[Talk-de] addr:phone vs. phone

Mirko Küster webmaster at ts-eastrail.de
Mo Feb 8 01:53:45 UTC 2010


> m.E. rufst Du im Endeffekt nach einem einfachen Typ von Relation (der
> einfach ist, da er eingeschränkte Möglichkeiten hat, und z.B. nur eine
> feste Art von Rolle, um die man sich nicht kümmern braucht, weil der
> Editor das macht, könnte man z.B. "Gruppe" nennen) mit
> bedienerfreundlicher Editorunterstützung. Nichts dagegen, im
> Gegenteil, nur solange man das nicht programmiert bleibt es halt
> Wunschdenken.

Meine Überlegung hat so garnichts mit einer Relation zu schaffen. Das wäre 
eigentlich nur eine Erweiterung der Objekte die wir haben. Völlig unabhängig 
von Relationen. Die sollen ja vorhande Objekte ansich fassen. Ich will die 
Möglichkeiten des Objektes selbst etwas erweitern.

Wir haben jetzt z.B. ein Gebäude mit seinen üblichen Eigenschaften:

  <way id='123456' version='1'>
    <nd ref='1' />
    <nd ref='2' />
    <nd ref='3' />
    <nd ref='4' />
    <tag k='building' v='yes' />
    <tag k='addr:postcode' v=12345' />
    <tag k='addr:country' v='DE' />
    <tag k='addr:street' v='Straße' />
    <tag k='addr:city' v='Musterstadt' />
    <tag k='addr:housenumber' v='1' />
  </way>

Dieses Konstrukt ist natürlich begrenzt. Du kannst ihm nicht zweimal 
amenity, phone whatever verpassen. Ein Tag geht nur einmal, ein zweiter Wert 
würde den alten einfach überschreiben. Zu der Zeit wo man noch andere Sorgen 
und wenige Details hatte hats gereicht. Deswegen sind wir gezwungen alles 
einzeln abzulegen, gewisse Redundanzen zu schaffen, Krücken wie die 
Semikolongeschichte zu bauen und das dann ggf. wieder über ein neues Objekt, 
eben die Relation, wieder zu vereinen. Damit fahren wir aber eigentlich mit 
Kirche, Marktplatz und Rathaus ums Dorf.

Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst 
und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die 
Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und 
erschlagen Krücken durch Tagüberschneidungen?

Das könnte jetzt mal vereinfacht so aussehen:

  <way id='123456' version='1'>
    <nd ref='1' />
    <nd ref='2' />
    <nd ref='3' />
    <nd ref='4' />
    <tag k='building' v='yes' />
    <tag k='addr:postcode' v=12345' />
    <tag k='addr:country' v='DE' />
    <tag k='addr:street' v='Straße' />
    <tag k='addr:city' v='Musterstadt' />
    <tag k='addr:housenumber' v='1' />
      <object group id='123456.001' />
          <tag k='amenity' v='bank' />
      <object group id='123456.001' />
      <object group id='123456.002' />
          <tag k='amenity' v='bank' />
      <object group id='123456.002' />
  </way>

Ich weiß nun nicht wie schwierig das ist um es in einer zukünftigen API 
vorzusehen. Ansich wäre es ja nur eine neue Tagrule und eine Erweiterung der 
ID, um die Gruppen Sub ID anhängen zu können. Ich denke mal die IDs sind 
begrenzt, wo es haken wird. Das schwierigste wird die Umsetzung im Editor 
sein. Aber wenn ich den Relationseditor sehe, scheint es da fähige Leute zu 
geben die das können.

Dann ist natürlich auch die Frage wie Renderer das dann auswerten. Nur 
schlimmer kann es für die im Grunde auch nicht kommen. Die haben meist 
unzusammenhängende POI Wolken liegen und müssen herumrechnen, verdrängen 
etc. Vielleicht würde eine saubere Gruppierung sogar eine besser Grundlage 
schaffen.

> wenn man sich hier schon grundlegende Gedanken macht, kann man ruhig
> auch gleich sinnvolle Hierarchien vorschlagen, also z.B.
> Grundstück
> Gebäude
> Einheit (Laden, Wohnung, Büroeinheit)
> ggf. Untereinheit (Raum, Zimmer, Saal)

Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit 
dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben 
die damit auflaufenden Probleme. Grundstücke sind wieder ne andere 
Geschichte.

Gruß
Mirko 





Mehr Informationen über die Mailingliste Talk-de