[Talk-de] addr:phone vs. phone

Johannes Huesing johannes at huesing.name
Mo Feb 8 20:08:44 UTC 2010


Mirko Küster <webmaster at ts-eastrail.de> [Mon, Feb 08, 2010 at 02:53:45AM CET]:
[...]

> 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>

Mal vorsichtig gefragt. Redest Du hier einer syntaktisch bedeutsamen 
Einrückung wie bei Python das Wort oder wolltest Du nicht hier ein 
paar Tags offen lassen/schachteln? Ist mir ja schon klar, dass OSM
nicht streng XML folgt, aber sowas wie mehrere Tags mit identischem
Inhalt/identischer ID finde ich schon ungebräuchlich.

> 
> 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. 

Als Erweiterung der bestehenden Syntax kann das gehen und es kann dann 
nützlich sein, wenn das Gesamtgebilde nicht eine Relation sein soll (wie
ein landuse=farmland mit mehreren Gebäuden drin). Man muss aber bedenken,
dass durch so eine Schachtelung nicht so leicht m:n-Relationen abbildbar
sind wie bei ... naja ... Relationen. Deshalb sehe ich sie nur als 
Ergänzung und nicht als Ersatz.

[...]
> 
> 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.

Das bisherige Vorgehen ist ja, das über räumliche Zugehörigkeit zu regeln, also
ein Gebäudeumriss mit verschiedenen Knoten für die Bäckere^H^H^H^H^H^H^HTeig-
warenfiliale, Pos^H^H^HSchreibwarenladen mit gelber Theke, Spielhölle und
Boutique.

Natürlich stößt das an Grenzen, aber ich bin nicht überzeugt, dass die 
Repräsentation in der Datenstruktur, die Du vorschlägst (so ich sie richtig
verstanden habe) gegenüber räumlicher Ordnung und Relationen einen wesentlichen
Vorteil bietet. Wenn die Editorschnittstelle davor das Entscheidende ist, ist
das Datenmodell dahonter doch ohnehin zweitrangig (zumindest wenn es zu
wenig anfängerfreundlich erscheint).

-- 
Johannes Hüsing               There is something fascinating about science. 
                              One gets such wholesale returns of conjecture 
mailto:johannes at huesing.name  from such a trifling investment of fact.                
http://derwisch.wikidot.com         (Mark Twain, "Life on the Mississippi")




Mehr Informationen über die Mailingliste Talk-de