[Talk-de] "construction=yes" bitte nicht durch "highway=construction" ersetzen!!!

[qbert biker]

-------- Original-Nachricht --------
> Datum: Mon, 15 Sep 2008 17:33:00 +0200
> Von: Bernd Wurst <bernd at bwurst.org>
> An: Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> Betreff: Re: [Talk-de] "construction=yes" bitte nicht durch	"highway=construction" ersetzen!!!

> Das ist aber verständlich.
> Schau, die kommerziellen Kartenhersteller wollen ihre Daten für ein Auto-
> und 
> manchmal auch ein bisschen für ein Fahrrad-Navi produzieren.

Umso mehr wäre etwas Organisation von Nöten um dieses mehr besser
zu verwalten. Aber konkreter: Ich kann hier nicht mehr alles verfolgen,
aber weitestgehend pendelt sich OSM auf die üblichen Standards ein.
Die Erweiterung auf Fussgänger und Radfahrer fügt sich da ganz normal
ein. Bis auf diese ziemlich unnötigen Ausfransungen wie beim construction
eben. Die Abweichungen sind aber nur in der Beschreibung und nicht
im Modell. Also ein normaler Modellparameter wird über mehrere Wege
beschrieben. Daraus folgt Verwirrung und Mehrarbeit ohne 
Mehrnutzen.
 
> Bei OSM gibt es ganz viel mehr Menschen mit eigenen Zielen.
> Zum einen sind die, die eigentlich nur die physische Realität abbilden
> wollen 
> ("asphalt => straße"), ganz gleich ob das jetzt eine Hofeinfahrt oder ein
> Privatweg ist. 

Und genau auf das ist das Modell von OSM schlecht vorbereitet, weil
jeder etwas anderes in die Klassen reininterpretiert und diese das auch
nicht leisten können, im Beispiel ist 'service' zu schwach um die
Hofeinfahrt abzubilden. 

> Darum haben wir Wege in der Datenbank die in einem 
> kommerziellen Navi-Kartenmaterial überhaupt nicht drin wären weil sich
> das 
> Auto-Routing dafür nicht interessiert.

Man sollte die kommerziellen Datenabieter nicht so systenmatisch
unterschätzen. Nicht alles was die in der Datenbank haben, kann man
über Google & Co abrufen. Man kann sich auch sicher sein, dass
die nur einen Teil ihres Modells offenlegen. GDF ist nur ein Exportformat. 
 
> Konsequenz vor allem letzten Ansatzes ist, dass es eigentlich
> hunderttausende 
> verschiedene Wege-Typen geben müsste und auch dann gäbe es noch
> Grenzfälle. 

Dazu gibts eben die Modelle, die hier als Überbürokratisierung gescholten
werden - die können den Wust in Grenzen halten. 

> Daraus jetzt ein 2D-Matrix-Schema mit vielen Eigenschaften zu machen 
> (asphalt, 3 Meter breit, mit ein bisschen split, risse in der
> fahrbahndecke, 
> 10 Grashalme pro Meter wachsen durch) wurde schon viel zu oft als Ersatz
> z.B. 
> für die tracktypes vorgeschlagen. Ist aber für geschätzte 99,9% der 
> Anwendungsfälle schnurzegal, weil die 5-gradige Abstufung völlig
> ausreicht. 

Um es mal klarzustellen: Sieht man von den Relations ab, kann die API 
gar nicht mehr als ein 2-D-Schema. Ein Tag übernimmt die Grundeinteilung
highway, railway, und die vielen Flächen- und Grenztypen. Alle anderen 
übernehmen die nähere Beschreibung. Mehr gibt die API nicht her.

Die Probleme liegen beim Weglassen, weil man meint, etwas sei in der
Klasse ja schon enthalten. 'unclassified' für eine Sandpiste oder doch
track? Zustand und Funktion stören sich gegenseitig, wenn eine
Piste Verbindungsfunktion hat. Nicht nur LKW-Fahrer, auch der Radfahrer
wüsste gerne, auf was er da unterwegs ist, ganz zu schweigen vom
Rollstuhlfahrer. Die klassischen Modelle lösen das auf, indem sie
mehrere Klassifizierungen haben, z.B. eines für den Zustand und
eines für die Verbindungsfunktion. 

> Daher mappen es eben auch nur 0,1% der Mapper und es "setzt sich nicht
> durch" 
> weil alle die den Sinn darin nicht erkennen das für zu stressig halten.

Weil es zu stressig ist, bzw. zu unpraktisch. Man kann das weitgehend
automatisieren und das in zwei Richtungen. Mit 'secondary' kommt dann
ein Satz von Defaultvariablen mit, z.B. dass es eine Staatsstrasse ist,
dass sie einen gewissen Ausbauzustand hat (Pfosten, Mittelstreifen, etc),
und einen hohen Verbindungscharakter hat. Die Defaultvariablen 
können aber noch verändert werden. Hinterlegt man eine Logik, kann 
man umgekehrt Einzelvariablen in die Klasse abbilden. Man gibt z.B. die 
Einzelparameter ein und bekommt die Klasse geliefert.

> Im Vergleich zur Realität wird unser Datenmaterial immer schlechter sein.
> Im 
> Vergleich zu kommerziellen Karten sind wir schon jetzt in den meisten 
> Gebieten deutlich besser. 

Kann ich nicht nachvollziehen. Das Klassenkonzept ist viel zu schwach
und Zusatzinfos werden viel zu selten vergeben. Die typischen Vergleiche
mittels Google-Maps greifen zu kurz. Da sieht man keine fehlenden
Verbindungen, fehlende oder falsche Einbahnrichtungen seitens OSM und
schon gar nicht die Daten, die die Kommerziellen noch in der 
Hinterhand haben könnten. 

> Auch mit diesen "falsch" oder sehr unscharf 
> eingestuften Straßen, deren Definition manchmal weit gedehnt werden muss 
> damit es passt.

Mal konkret: Gute Erfassungen schaffen es, im Bereich primary bis
unclassified 5 bis 7 Klassen sauber zu trennen und das in zwei Bereichen
(Verbindungscharakter/Ausbau). 
 
OSM schafft es nicht mal, seine 4 Klassen diesem Bereich in den Griff zu 
kriegen. Da wird oft etwas zu früh gejubelt...

Grüsse Hubert
-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196