-------- Original-Nachricht -------- > Datum: Wed, 06 Jan 2010 18:34:24 +0100 > Von: Tobias Knerr <[email protected]> > An: Sascha Silbe <[email protected]>, Openstreetmap > allgemeines in Deutsch <[email protected]> > Betreff: Re: [Talk-de] maxspeed=DE:Urban
Hallo, als ob die Arbeit mit Polygonen ein Hexenwerk waere... > > Why don't you use polygons for this? > > * Polygons are two-dimensional. There are situations where bridges > > or similar three-dimensional structures cause "zones" to vertically > > overlap, which cannot be represented by polygons. Das Datenmodell von OSM ist zweidimensional, daran aendern auch die Ebenen nix. Die OSM-Datenverarbeitung kennt keine echte Z-Ebene, sondern nur Kreuzungen, die keinen Knoten bilden mit der Erklaerung dazu, dass sie sich eben in einer anderen Ebene befaenden, hauptsaechlich als Hinweis an die Visualisierung. Ein zweidimensionaler Algorithmus wird also alle Elemente finden. > > * Downloading only a part of the map (e.g. a part of a city) can > > result in polygons missing from the download, despite ways from > > inside the polygon being part of the downloaded data. Ein einfacher Loesungsansatz dafuer: Jedes Polygon bekommt ein umschreibendes Rechteck, das sich leicht zuordnen laesst, auch wenn kein einziges Element des Polygons heruntergeladen wird, z.b. weil das Polygon viel groesser ist als der geladene Bereich. Der Rest ist, die Beziehung der Polygone und des geladenen Bereichs zu klaeren (alle drin, alle draussen, Schnittmenge) > > * A mapper will often know that a certain way is part of a zone > > without knowing where the zone boundaries are. Da kann ja 'is_in' als Uebergangsloesung verwendet werden, oder es wird eine Teilgrenze eingetragen und ein anderer macht das polygon dann zu. > > * Tags on ways are easier to evaluate for applications. Polygons > > require more advanced programming techniques to reduce performance > > problems from inclusion tests. Da bin ich durchaus anderer Meinung. Was hier immer wieder an Beschreibungsvarianten auftaucht ist durchaus vielfaeltig und ein Algo muss die alle fehlerfrei erkennen koennen und auch ob ein Geasschen vergessen wurde. Ein Polygon hingegen ist geometrisch stabil und wenn die Algorithmen dazu sauber durchgetestet ist, laeuft das erstmal. Fehler in einem Polygon zuzuordnen (nicht geschlossen, etc.) ist auch sicherer und stabiler als sicherzustellen, dass alle Einzelelemente des Bereichs auch richtig ausgewertet werden. Letzteres ginge uebrigends am einfachsten, indem man ein Poygon erzeugt und alle Elemente innerhalb des Polygons ueberprueft (Katze, Schwanz, beissen...). > > * it's very incorrect, because only the roads themselves are part of > > any kind of traffic-zone and not the whole area; e.g. roads in parcs > > or on private property or even tracks. Stimmt, wie will man sicherstellen, dass ein Baum in einem Park sich beim davonlaufen ans Tempolimit haelt :) Etwas Logik in die Auswertung und das Thema ist gegessen: private schlaegt public, explizites Schild schlaegt Zone, usw. Es gibt auch noch die Moeglichkeit, eine Zone ueber den Graphen selber zu beschreiben, indem man alle begrenzenden Knoten markiert und mit den Mitteln des Graphen in das Gebiet hineinscannt. Diese Methode erfasst nur Elemente des Graphen selber (also i.A. 'highway'), erfordert aber ein gehoeriges Mass an Disziplin und ist etwas sensibel gegen das 'Auslaufen', z.B. wenn eine Node nicht erfasst ist. Auch das kann man abfangen aber fuer die technisch robusteste Loesung halte ich das echte Flaechenpolygon. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
