[Talk-de] maxspeed=DE:Urban

qbert biker qbert1 at gmx.de
Do Jan 7 13:58:04 UTC 2010


-------- Original-Nachricht --------
> Datum: Wed, 06 Jan 2010 18:34:24 +0100
> Von: Tobias Knerr <osm at tobias-knerr.de>
> An: Sascha Silbe <sascha-ml-reply-to-2009-4 at silbe.org>, Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> 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




Mehr Informationen über die Mailingliste Talk-de