[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