[Talk-de] Navigations-Software "Roadee" mit OSM-Datenbasis im Vergleich bei Heise

[qbert biker]

-------- Original-Nachricht --------
> Datum: Mon, 19 Oct 2009 11:51:28 +0200
> Von: Martin Koppenhoefer <dieterdreist at gmail.com>
> An: Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> Betreff: Re: [Talk-de] Navigations-Software "Roadee" mit OSM-Datenbasis im	Vergleich bei Heise

> Am 19. Oktober 2009 09:36 schrieb qbert biker <qbert1 at gmx.de>:
> > Ich habe uebrigends im Modellierungsbereich mit Netzen zu
> > tun gehabt, die jede Verbindung in der Kreuzung als
> > eigenen Link ausformuliert haben.
> 
> weil es anders im Endeffekt gar nicht halbwegs uebersichtlich und praezise
> geht.

Das Feld der Verkehrsmodellierung ist weit gestreut, allerdings
kenne ich niemanden, der bei diesem Konstrukt geblieben waere.
Die hoechste Detailschaerfe, die ich kenne, ist die exakte 
Abbildung von Abbiegeflaechen von Kreuzungen, wenn Ampeleffekte
simuliert werden sollen. 

Aber da geht man dann wieder anders vor und modelliert 
konkrete Puffer, die ausserhalb der Simulantenszene keiner
versteht.
  
> seit wann wollen wir nur "simples Routen"? Wer das will, kann die
> Spuren ja beim Konvertieren rauswerfen, in die Datenbank gehoeren sie
> m.E.

Simples Routen ist nun mal ein konzeptuebergreifendes Ziel,
ganz im Gegensatz zu komplexen Verkehrssimulationen. Und ich
widerspreche ja auch nicht im geringsten, dass Spuren, auch
Abbiegespuren in die Datenbank reingehoeren. Aber dazu gibts
einen effektiven Weg mit wenig Nebenwirkungen und das ist
die Attributsebene. Wenn ich jeder Spur einen way spendiere,
ist das Handling ungleich komplexer.

Als Beispiel ein Simulationsprojekt, bei dem es um
Verflechtungen an Einfaedelspuren ging. Da haben wir damals
komplette Autobahnkreuze in Einzelfahrzeugaufloesung simuliert,
ohne dass die Spuren einzeln abgebildet waren. Ganz im 
Gegenteil heatten wir da ganz schoen rumwuergen muessen,
um die Verbindung der Spuren wieder hinzubekommen.
 
> > Meistens gehts
> > ja nur darum, dem Teilnehmer mitzuteilen, dass er sich
> > bitte einordnen soll und das geht viel effektiver und
> > einfacher. Man kann z.B. in einer Node vor der Kreuzung
> > die Info hinterlegen, die dann als Nachricht beim
> > Ueberfahren ausgegeben wird.
> 
> wie gesagt: beim Aufbereiten der Daten fuer eine konkrete Anwendung
> kann man das gerne machen, in den (Haupt-)Daten waeren richtige und
> vollstaendige Informationen sinnvoller. "Meistens" ist ueberhaupt kein
> Argument.

Die Information: Dieser Link (way) hat von A nach B 2 Spuren,
und von B nach C 2 Spuren + eine Linksabbiegerspur ist 
vollstaendig. Wenn man eine Beziehungsrichtung fuer die Spuren
(z.B. von links nach rechts in Fahrtrichtung) einfuehrt, kann 
man das auch noch vertiefen. Man kann problemlos definieren,
dass man in einem Bereich zwar von Spur 1 nach 2 aber nicht 
umgekehrt wechseln darf. 

Und dein Einwand, dass die Anwendung das ummodeln kann wie
sie es braucht, funktioniert auch andersrum: Man kann auch
Querschnittsinformation in einzelne Links umwandeln, deshalb
muss man sie noch lange nicht aufgedroeselt in der DB
ablegen.

Gruesse Hubert

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser