<div dir="ltr">Hi,<br><br><div class="gmail_quote">2008/10/19 Tordanik <span dir="ltr"><<a href="mailto:osm@tobias-knerr.de" target="_blank">osm@tobias-knerr.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Bernd Wurst schrieb:<br>
<div>> Entweder ein geeigneter Weg lässt sich algorithmisch finden oder nicht. Ich<br>
> finde es ist möglich, also muss man keine Fake-Lösungen einbauen.<br>
<br>
</div>Nebenbei: Hat das schon mal jemand algorithmisch gemacht? </blockquote><div><br></div><div>Das ist algorithmisch ein alter Hut: Im einfachsten Fall kann man den kürzesten Weg (Dijkstra) auf dem Sichtbarkeitsgraphen aller Punkte des Polygons berechnen. Wenn zwei Polygone an einer Seite aneinander grenzen, dann betrachtet man das als ein großes Polygon.</div>

<div><br></div><div>Aber die Diskusion läuft schön langsam wieder darauf hinaus, worauf mir die meisten OSM-Diskussionen hinauslaufen zu scheinen: "Wir mappen nicht für Renderer". Dabei ging mir die Frage doch gar nicht darum. Natürlich ist wichtig, dass das ganze irgendwann mal richtig gerendert wird. Aber das war nicht meine Frage.</div>

<div><br></div><div>Schon auf der rein logischen Ebene stellt sich doch die Frage wie das zu mappen ist. Es ist eben nicht der ganze Platz Bestandteil der Route, sondern nur der Teil, auf dem die Route verläuft. Damit hat der Teil worüber die Route verläuft eine andere Semantik (etwa den zusätzlichen Namen der Route!). Wenn ein Teil eines Weges andere Eigenschaften hat, dann beginnt man ja auch einen neuen Weg.</div>


<div><br></div><div>Und, wenn wir schon über den Renderer reden müssen: Ein Render kann genauso einen Weg ignorieren wie einen Weg über den Platz finden. Dazu müsste man nur den Weg mit einem entsprechenden Tag versehen oder gemeinsam mit dem Polygon in eine Relation für den Platz packen.</div>

<div><br></div><div>Mike <br></div></div></div>