[Talk-de] Overlapping ways bei einer area

[Bernd Wurst]

Hallo.

Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer:
> > Genauso könntest du argumentieren, dass eine Querstraße am Rand der
> > Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten
> > ziemlich sinnlos, wenn die nicht verbunden wären.
> Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im
> Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in
> der Mitte wie auch am Rand :)

Die Aussage dreht sich im Kreis.

Also ich verstehe was du sagen willst.
Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße 
einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. 
Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied.

Eben grade *weil* die Straße (nicht die Einmündende sondern die 
Ausgangsstraße) nicht zweidimensional erfasst wird.

Fall 1:

--------------------------
-   -   -   -  -  -  -  -
---+  +-------------------
   |  |
   |  |


Fall 2:

--------------------------
-   -   -   -  -  -  -  -
----+                 +---
    |                 |
    |                 |
    +-----------------+

Für mich sieht die obere Straße auch unterhalb der Mitte noch identisch aus 
bei beiden Szenarien. Nur der Rand der Straße (der gar nicht erfasst ist) 
ändert sich.


Wenn du den Platz jetzt unabhängig erfassen würdest, wäre das Datenmodell so:

--------------------------
-   -   -   -  -  -  -  -
--------------------------
    +-----------------+
    |                 |
    |                 |
    +-----------------+

Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und 
Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass 
es hier überhaupt eine Einfahrt in den Platz gibt.

Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es 
natürlich was anderes. Aber das war nicht die Ausgangslage.


> > 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben,
> > wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden
> > ohne dass es die semantische Abbildung der Welt stört.
> Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht
> nicht berurteilt werden.

Mag sein, seh ich anders.


> > 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße
> > gerendert wird. Wir werden später immer wieder die Situation haben, dass
> > Straßen unterschiedlich dargestellt werden sollen oder sogar minimal
> > verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn
> > der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch
> > optisch nicht damit verbunden. Das ist in der Regel falsch. Durch
> > Benutzung der selben Nodes wird das Problem grundsätzlich umgangen.
> Grundsatz: Mappe nicht für den Renderer!!

Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. 

In der Realität würde man sagen: "Der Platz schließt sich direkt an die Straße 
an." Man sagt nicht: "Der Platz beginnt 3 Meter vom Mittelpunkt der Straße 
entfernt". 

Daher komme ich zu dem Schluß, dass verbundene Elemente für jede Nutzung und 
für jede Art von Renderer die mir einfällt leichter zu verarbeiten bzw. 
einzustufen ist. Weil es eine semantische Abbildung ist.


Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch 
auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus 
unserem Datenbestand exakt bestimmen kann) oder ob die Karten primär dafür 
gedacht sein sollen, semantisch die Realität abzubilden damit man einzelne 
Objekte in Relation zu anderen Objekten setzen kann.

Ich sehe unsere gesamte Genauigkeit als so grob an, dass wir ersteren Anspruch 
niemals erfüllen können. Daher mappe ich semantisch. Sonst müsste man ja auch 
jede Kurve mit tausenden von Nodes machen, um das genau genug abzubilden.


> Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht?

Wieso sollte das so sein? Flächen verschieben sich nicht einfach so. Also 
zumindest nicht in der Realität. :)
Bei baulichen Veränderungen muss man ggf. die Karte korrigieren, das ist aber 
logisch.

Und ich will ja grade vermeiden, dass Straße und Platz in irgendwelcher 
Darstellung auseinander gezogen werden obwohl sie in Wahrheit direkt 
aneinander grenzen.


> Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst
> werden und Flächen 2 Dimensional nicht.

Das "nicht" ist zu viel, oder? ;-)
Ich finde nicht, dass das was ändert.


> Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die
> Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation
> zu packen.

Man kann laut Duden beides benutzen. ;-)

Da stimme ich dir zu. 


Die Frage von oben ist IMHO aber auch, wie man es z.B. handhabt, wenn eine 
Straße links Wald und rechts Wohngebiet hat. Für mich ist die Antwort 
hierrauf die selbe wie für den Platz oben.

Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald 
unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen 
Seite dann ebenfalls ganz grob frei Hand. Die Ways schneiden sich in den 
OSM-Daten vor allem in Kurven recht unkoordiniert und dass das in der Karte 
nachher nicht scheisse aussieht liegt nur daran, dass der Renderer der Straße 
eine gewisse Breite gibt, sodass beide Flächen auf dem Bild nachher genau an 
die Straße angrenzen.

*DAS* finde ich völlig falsch. Ich finde, der Renderer soll die Straße so 
breit rendern wie er denkt und die Flächen sollten "direkt daran 
angeschlossen" werden. Das sage ich ihm, indem ich die selben Nodes nutze.

Gruß, Bernd

-- 
Wenn man bedenkt, dass die Leute vor 150 Jahren ihre E-Mails
noch bei Kerzenlicht geschrieben haben...
  -  Marianne Kestler, de.admin.net-abuse.mail, 6.5.2000
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 835 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20080605/ae07808b/attachment.sig>