Am 18.07.2010 um 13:36 schrieb Markus:

> Hallo ... ,
> 
>>>>> Hier scheint die Meinung anders zu sein:
>>>>> http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations
>> 
>> Die meisten anderen Proposed_uses_of_relations beziehen sich tatsächlich 
>> auch Relationen, wie sie eigentlich gemeint sind, nicht der blosen 
>> Zusammenfassung von Daten einer Kategorie.
> 
> Ok, dann habe ich das englische Zeug falsch verstanden.

Hey, ganz OSM ist englisch. :-)

> Aber auch das ist für mich nicht wirklich verständlich:
> 
>> Laut dieser Definition sollen verschiedene Elemente auch in OSM 
>> zusammengebracht werden, die mit einer bestimmten Rolle auch in der 
>> Wirklichkeit untereinander in Beziehung stehen. Sie sind nicht nur in 
>> Beziehung untereinander, weil sie der selben Kategorie angehören. Das ist 
>> der Unterschied.
> 
> Hier würden Beispiele helfen für:
> a) gute Relation

O.k. ein paar Beispsiele für Dich:

Beispiel Abbiegerelation. Hier wird die Beziehung eines was über einen 
gemeinsamen Knoten zum nächsten way abgebildet. Z.B. als "Nicht von diesem way 
1 über diesen Knoten auf den anderen way 2 fahren"- Regel. In diesem Beispiel 
stehen die beteiligten beiden ways über den gemeinsamen Knoten in direkter 
Beziehung zueinander - auch in der Wirklichkeit, darf man nicht von dem 
Straßenteil (way 1) über den Schnittpunkt beider beteiltigter Straßenteile 
(node) in den anderen Straßenteil (way 2) abbiegen.

> b) schlechte Relation --> alternative Lösung

Alle Gebäude, die amentiy=fuel und operator=BP im tag haben innerhalb eines 
bestimmten Gebietes in einer Relation zusammenfassen. Hier gibt es ausser den 
abstrakten Beziehungen der Funktion und des Betreibers keine Beziehung in der 
Wirklichkeit zueinander, noch haben die Elemente eine bestimmte Rolle in dieser 
Relation/Beziehung.Es ist einfach nur eine Sammlung dieser Kategorie
 --> Alternative: Ein Programm schreiben/nutzen, das nach diesen Tags suchen 
und diese dann ausgeben kann. Da man mit der XAPI IMHO nur nach einem Tag 
suchen kann, kann man aber im Ergebnis der ersten Suche (amenity=fuel) nach 
einem weiteren Tag suchen (operator=BP).

> Dabei sollte der Grenzbereich deutlich werden.

Wurde er anhand der Beispiele jetzt auch, oder?

> Und vielleicht kann man dann für die wichtigsten Fälle sogar Regeln 
> formulieren :-)

Das geht doch schon aus dem bestehenden Wiki hervor. Ableiten muss man vieles 
in OSM.

> In einem anderen Thread wird gerade diskutiert, ob man Häuser, deren Adresse 
> zu einer Strasse gehört, in einer Relation zusammengefasst werden soll? Oder 
> PLZ, Ort, Land als Relation? (wurde dort mehrheitlich verneint, aber steht 
> nicht im Wiki).

Natürlich steht im Wiki (genau: im Proposal), dass es drei Arten der Erfassung 
von Hausnummern gibt: Einzelnode, Interpolation und Relation. Doch wie und wann 
diese zu verwenden seien haben wir in dem von Dir genannten Thread besprochen 
und wurde von mir auch im Proposal als Fazit der Diskussion eingetragen. Es 
steht doch noch drin , oder? ;-)

> Oder die Frage, ob gesetzliche Regelungen in Relationen zusammengefasst 
> werden sollen (Geschwindigkeitbegrenzung, Rauchverbot).

Das wäre wiederum eine Sammlung von Elementen in einer Kategorie, womit Du 
wieder bei "Relations ar not Categories" bist. Doch davon abgesehen: warum 
sollten einfache tags, die als Eigenschaft eines Objekts getaggt wurden, in 
einer Relation zusammengefasst werden? Warum möchtest Du alle ways die den 
maxspeed-tag :DE:urban tragen in einer Liste haben, und dann noch eine mit 
maxspeed=100? Und selbst wenn Du es möchtest: diese ways findet man auch über 
die XAPI mit der Suche nach allem ,was den entsprechenden Tag hat udn kannst es 
selbst in eine DB schreiben.

> Oder Verkehrssignale (da ist es "established").

welche Verkehrssignale meinst Du z.B.? Auch da muss man unterscheiden, welches 
Verhalten/Regel sich davon ableiten lässt und wie diese am sinnvollsten und 
einfachsten abzubilden ist:

Du kannst eine Richtungsschild in einer Relation packen, indem Du sagts, von 
dem way, über den node auf den way geht es zum Schwimmbad. Du kannst auch einem 
Einfahrtverbotsschild in eine Relation packen: von dem way über den node auf 
den way darf man nicht hinein fahren. Und Du kannst einen Ampelblitzer als 
Relation eintragen: Wenn Du von dem way über den node auf den way fährst kann 
es sein, dass Du geblitzt wirst, weil aus dieser Richtung die Einhaltung des 
roten Ampelsignals überwacht wird.

Ein Parkverbotsschild musst Du aber keine Relation abbilden, dazu genügt es den 
enstprechenden way entsprechend zu taggen. Dazu gibts übrigens auch eine 
hochqualitatives Proposal: "Parking". Auch ein Stopschild benötigt keine 
Relation, denn das gilt für alle ways, die direkt nach dem node des Schildes 
folgen. Da muss ich das von wo über welchen node nach "wohin" nicht noch in 
Relationen packen. Das gleiche gilt für das Achtung Bahnübergang, oder oder 
oder ...

Du siehst, dass es immer darauf ankommt, welche Regel/Verhalten aus dem Schild 
abgeleitet werden muss, um zu bestimmen, welche der Möglickeiten die einfachste 
oder nötige Art ist, das abzubilden, was die Regel aussagt. Theoretisch lässt 
sich alles mit Relationen abbilden (fast). Doch sinnvoll ist es nicht immer, 
wie der umgekehrte Fall auch.

steffterra
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Antwort per Email an