On Mon, 19 Jan 2009, Bernd Wurst wrote:
ja, am besten waere wohl ein preprocessing, das erkennt, welche Flaeche von
welcher umschlossen ist, und das dafuer sorgt, dass zuerst die groessere
(untere/aeussere) Flaeche gerendert wird und darueber die
kleinere/eingeschlossene. Das man damit keine Flaechenstatistiken machen
kann, ist natuerlich klar.
Der JOSM-Multipolygon-Code enthält entsprechendes. Natürlich greift er auf
Java-Polygon-Funktionen zurück.
Nein, das meine ich nicht.
Im Fall des Garmin kann man z.B. nicht pro Objekt bestimmen in welcher
Reihenfolge so etwas gerendert werden soll. Und man kann ja nicht alle Seen
über Wälder oder andersrum legen, sonst hat man genau das aktuelle
Verhalten. :)
Ich dachte an einen Algorithmus, der aus
,--------------.
| |
| ,----. |
| | | |
| `----' |
`--------------'
dann sowas macht:
,--------------.
| |
| ,----. |
+---+ | |
| `----' |
`--------------'
Mit einem solchen Polygon könnte dann auch ein einfacher Renderer umgehen. In
den Daten gefällt mir so etwas nicht, aber es ist ein probates Mittel wenn
man für diese Anwendung nur eine Malvorlage braucht und keine "korrekten"
Daten.
Auch das ist in JOSM so umgesetzt.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
