-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

der Diskussion fehlt mir irgend wie ein System.

Ich habe in meiner Umgebung nur Parkplätze und diese sind in der Natur
baulich von der Straße abgegrenzt. Und wenn es nur ein paar Meter sind.
Entweder endet die Straße im Parkplatz oder geht daneben vorbei, besitzt
dann aber eine separate Zufahrt zum Parkplatz. Ich erstelle erst einmal den
Parkplatz ganz isoliert aus den vier Eckpunkten. Es ist mir kein Parkplatz
bekannt, bei dem die Zufahrt direkt auf einem Eckpunkt liegt. Also mache ich
ein paar Meter neben der Ecke eine weitere Node in die Parkplatzumgrenzung
und lasse die Straße/Zufahrt dann dort enden. Das Ergebnis sieht dann wie in
der Realität aus. Habe ich hier einen Denkfehler?

Ganz anders sieht die Sache bei einem (historischen) Marktplatz aus, in den
mehrere Straßen münden und der eigentlich kein richtiger Platz (wie z. B.
der Parkplatz) ist. Da müsste man eher so eine Art Kreisverkehrskonstukt
erstellen. Mancher Marktplatz besitzt ja auch eine Mittelinsel (mit Brunnen
oder Kriegerdenkmal). Echte Marktplätze sind im Augenblick für mich zu weit
weg. Irgendwann werde ich mich auch damit befassen müssen, aber noch nicht
gleich heute.

Rolf

> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Im Auftrag von Bernd Wurst
> Gesendet: Donnerstag, 5. Juni 2008 10:31
> An: Openstreetmap allgemeines in Deutsch
> Betreff: Re: [Talk-de] Overlapping ways bei einer area
> 
> 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
> 


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.5.3 (Build 5003)
Charset: iso-8859-1

wj8DBQFIR+fRX/cdferISG0RAoRWAKDwH79uXFO0ZdPe4izAfY/texwwIACgmu9S
uN4ldgKXua1hF9277R8N6c0=
=Q5cJ
-----END PGP SIGNATURE-----

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

Antwort per Email an