[Talk-de] maxspeed=DE:Urban

qbert biker qbert1 at gmx.de
Fr Jan 8 12:12:42 UTC 2010


-------- Original-Nachricht --------
> Datum: Thu, 07 Jan 2010 23:13:59 +0100
> Von: Tobias Knerr <osm at tobias-knerr.de>
> An: Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> Betreff: Re: [Talk-de] maxspeed=DE:Urban

> qbert biker schrieb:

> Ich glaube, du hast das Problem nicht ganz getroffen. Die *Realität* ist
> dreidimensional, und wenn in der Realität die Straße auf einer Brücke
> zu
> einer anderen "Zone" gehört als die Straße unten drunter, dann kann man
> das nur mit zweidimensionalen Polygonen nicht abbilden.

Das Modell ist ausschlaggebend, der Rest ist Definition, wie
man bei Polygonen drin und draussen definiert, z.B. waybasiert
oder knotenbasiert. Damit kann man entsprechende Schlaufen 
ziehen, was zwar nicht elegant ist, aber technisch realisierbar.

Etwas einfacher ists natuerlich, wenn man eine Relation baut,
die das Polygon mit dem Exotenelement verbindet. Wenn diese 
Exotenkonstruktion ueberhaupt mal vorkommt, die Masse der 
Polygone ist problemlos definierbar.
  
> Was voraussetzt, dass zumindest beim Vorverarbeitungsschritt eben doch
> alle Daten zur Verfügung standen. Lösbar, aber eine kleine zusätzliche
> Auflage.

Eben, ich wende mich an dieser Stelle nur gegen ein plumpes
geht nicht. Ob man es macht und obs Vorteile bringt, ist
etwas anderes, aber die genannten Punkte sind alle technisch
loesbar.

> Ok, wir messen anscheinend den Aufwand unterschiedlich. 

Anwendungsentwickler gegenueber Tagger?

> Meine
> Betrachtung bezog sich hier auf eine "Fehler in den Daten werden in den
> Daten gefixt, nicht von mir"-Software. Wenn du dich natürlich noch für
> das Erraten von Fehlern zuständig fühlst, werden Tags in der Tat
> aufwendiger. Das halte ich aber nicht für die Aufgabe der meisten
> Datennutzer.

Als Anwendungsentwickler gehe ich prinzipiell von 
fehlerhaften Daten aus und versuche stabile Verfahren zu
bauen, die den Fehlereffekt von sich aus begrenzen. 

Kleines Beispiel: Ein potentielles Polygon umfasst 100 
ways. Die wiederum sind auf 10 verschiedene Arten
Limit-getaggt und bei einem ist der Schreibfehler passiert
und es steht statt 30km/h 300km/h drin. 2km mit 300kmh
statt 30 koennen das Routingergebnis ganz schoen verziehen.
Oder mir gehen 10 Strassen mit 30 durch die Lappen, weil
wieder mal jemand eine neue Schreibweise eingefuehrt hat
und die gehen auf den Default 100kmh oder 50kmh zurueck.
Die 50kmh kommen schon aus der Fehlerbegrenzung, wenn man
den Default fuer residential so setzt. Wird innerorts
unclassified verwendet (nicht verboten) und ich habe kein
Polygon, wird 100kmh draus. Da werte ich lieber Ortsgrenzen
aus und begrenze den moeglichen Fehler.

Wenn ich also einen Router baue und den einem Nicht-OSMler
zumuten will (also einer, der das Ding einfach benutzen 
will ohne Fehler zu berichtigen) werde ich versuchen,
diese Dinge zu stabilisieren, weil ich OSM und die 
Taggingkreativitaet der OSMler kenne.

Ein Polygon ist sehr stabil, weil es algorithmisch 
ausgewertet werden kann und visuell sehr einfach zu testen
ist. Einen Algo zu bauen, der alle in OSM verwendeten
Schreibweisen, Trenner usw. zu 100% auseinanderdroeselt,
ist da schon ein anderes Kaliber.

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