Martin Koppenhoefer schrieb:
>
>     vielleicht habe ich mich unklar ausgedrückt. aber dass, was du
>     jetzt als großen Tagurwald siehst, steht doch in der jeweiligen
>     Relation drin?
>
>
> das aendert doch nichts, der Urwald steht dann halt in der Relation 
> drin, grafisch anschaulicher und besser bearbeitbar wird es IMHO 
> dadurch aber nicht. Aber das was oben beschrieben ist, geht auch ohne 
> Relation. Die braucht man fuer Restrictions natuerlich trotzdem (kann 
> ich mir uebrigens nur schwer vorstellen, wie man z.B. virtuelle Wege 
> in Turn-Restriction-Relations aufnehmen will). 
Is ja nicht nur eine Relation, sondern viele Relations (für jede Lane ja 
mindestens 1). Das heißt die Daten stehen punktgenau da, wo sie 
hingehören. Eine Turn-Restriction könnte z.B. so lauten. FROM lane-(wo 
ich herkomm) VIA KReuzungsnode TO lane-(wo es hingeht). Wird also nicht 
schwerer als eine normale Restriktion.
>
>
>     und wie willst du bitte einzeichnen, ob parking-abschnitt parallel
>     oder orthogonal parken vorsieht? 
>
>
> das muss ich gar nicht einzeichnen, wenn ich lediglich die Wege mappe, 
> die es gibt, zeichne ich das Parken halt ein, anstatt tags mit 
> Lane45=parking, Lane45:width=5m
> zu vergeben.
der Vorteil daran, wenn du die Parkzone mit in die Relation reinpackst 
ist, dass du einen Bezug der Elemente der "Straße im Ganzen" hast. Wenn 
du alles mit Ways zeichnest hast du dies nicht. (Dieses Verhältnis zu 
einander würde auch den Renderern ein deutlich besserer Ergebnis 
abringen. Routen wäre dadurch auch "lane-genau"
>  
>
>     von oben betrachtet ist der eine parkstreifen einfach etwas
>     breiter als der andere. Und die Art und Weise wie geparkt werden
>     soll müsstest du also eh über ein Tag regeln. 
>
>
> naja, das ist ja eine Info, die man nicht unbedingt als erstes braucht 
> ;-), worauf ich hinaus wollte war, dass man, wenn man ein Schema 
> favorisiert, das im Idealfall nur noch 1 gezeichneten way hat, und der 
> Rest wird ueber tags geregelt, dass man in diesem Fall dann auch 
> solche Dinge wie Breite der Parkplaetze angeben muss. Ausserdem 
> muesste man wohl irgendwie angeben, welche (virtuelle) Spur mit 
> welcher verbunden ist, weil das dann nicht mehr automatisch 
> topologisch enthalten ist (Anzahl der Spuren aendert sich laufend, s. 
> Beispiel).
Im allgemeinen werden wir ohne Breitenangeben der Ways oder Lanes auf 
Dauer nur pseudogenau sein. Was allerdings die Übergänge von einem Way 
mit Lanes zu einem anderen angeht, so existiert bestimmt noch 
Klärungsbedarf.
>  
>
>     Ob du das aber jetzt an einen eigenen gezeichneten Weg hängst,
>     oder in die entsprechende parking-lane, spielt doch für den gehalt
>     des Tags keine Rolle. Ein seperater Weg sugerriert jedoch dass es
>     etwas autarkes sei. wenn aber der Übergang von Straße zu Parkbucht
>     zu Fussweg fließend ist, dann ist ein seperat gezeichneter Way IMO
>     falsch.
>
>
> naja, darum geht es ja gerade. Je laenger ich ueber die Konsequenzen 
> dieses Vorschlags nachdenke, um so mehr komme ich zu dem Schluss, dass 
> der Ansatz tags statt Spuren gar nicht funktioniert. Ich lasse mich 
> aber gern vom Gegenteil ueberzeugen, macht einfach mal Vorschlaege, 
> wie man die betreffende Situation mit der Tag-Methode mappen koennte.
>  
> PS am Rande: sowas wie "autark" gibt es in der Stadt sowieso nicht 
> (evtl. von Militaereinrichtungen abgesehen), der Uebergang Strasse zu 
> Fussweg ist selten fliessend, sondern meist durch Grenzen 
> gekennzeichnet (Bordstein, Leitplanke, Absperrgitter, je nachdem).
IMO sind Grenzen etwas anderers als ein simpler Bordstein


Gruß
 Mario


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

Antwort per Email an