Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Am Montag 28 Januar 2008 schrieb Bernd Raichle: > > > Ok, aber welche Attribute willst du denn genau, die ein Routing mit > > > brauchbaren Ergebnissen erst ermoeglichen sollen? > > > > ich bin kein routing-experte, drum kann ich das nicht wirklich > > beurteilen. aber um eine strasse einigermassen realistisch abzubilden > > wuerde ich auf jeden fall folgende tags als "minimalen standard" > > verlangen wollen: > > > > highway:width = breite der strasse (nicht in zentimetern, sondern in ein > >paar definierten abstufungen) > > Hast du fuer diese Abstufungen einen Vorschlag? Unter "width" wuerde > ich als Anfaenger jedoch annehmen, dass ich hier die tatsaechliche > (befahrbare) Breite in Meter oder Zentimeter angebe, evtl. halt auch > geschaetzt. > eine unterteilung in mehrere breitenbereiche, aber schon auch abbildbar als breite in metern. eine alternative angabe in metern fuer die die gut schaetzen koennen oder mit meterstab unterwegs sind, sollte natuerlich auch moeglich sein. > > highway:lanes = anzahl der fahrspuren pro richtung (default-wert = 1) > > Das Tag "lanes=..." gibt es. (Mir fehlt da eher noch eine das tag meinte ich auch damit. > Moeglichkeit zu sagen, dass in eine Fahrtrichtung nur eine, in die > andere 2 Spuren zur Verfuegung stehen. Was gebe ich denn bei einer > Bundesstrassen mit zusammen 3 Spuren, wobei die mittlere wechselweise > zum Ueberholen verwendet wird, fuer "lanes" an? "lanes=1.5"? Sollte > aber wohl eher die "minimal number of lanes" sein.) > da muss man sich was ausdenken, ja. > > highway:ref_loc = laenderspezifische zuordnung, wie z.B. "Kreisstrasse" > > in deutschland, um z.B. eine augsburger kreisstrasse (A123) nicht als > > autobahn zu sehen. > > Man wird hoffentlich nie anhand des Praefixes der Strassennummer auf > die Art schliessen, oder? Hierfuer ist "highway" eindeutiger! > das bisherige highway tag will ich ja ersetzen, das gibts in dem system nicht mehr.und die kategorisierungen sind nunmal laenderspezifisch. > Statt "ref_loc" wuerde ich eher "ref_type" bzw. "ref_level" mit Werten > > >= 1 verwenden (entsprechend "nat_ref_type" etc. fuer die anderen > > "*_ref"-Tags). Werte fuer D: 1=E, 2=BAB, 3=B, 4=L+St, 5=K, evtl. 6 > und groesser fuer andere Laender. In einem Vorschlag sollte man > zumindest fuer die wichtigsten Laender eine Zuordnung zu den > nationalen Bezeichnungen aufnehmen, um ein stimmiges Bild zu bekommen. > ob man das jetzt numerisch oder als test schreibt, ist ja egal. nur sollte es festgelegtg werden, wie. > > optional noch folgende: > > > > highway:ref = administrative bezeichnung, wie z.B. "B22" > > Es gibt bereits das "ref"-Tag. > genau das meine ich auch damit. die idee ist nur, die tags unter dem namespace highway zusammenzufassen, damit man einerseits sieht, dass es hier um eine strasse geht, andererseits, damit man sieht, dass die tags zusammengehoeren. > > highway:surface = Oberflaechenbeschaffenheit, angegeben in definierten > >kategorien, um zu unterscheiden ob die strasse z.B. schoen eben ist, > >oder nur aus schlagloechern oder kies besteht. > > Die Vorschlage "Road Surface", "surface values" gibt es schon im Wiki. > Ausserdem gibt es eine Key-Beschreibung fuer "surface=..." mit den > Werten "paved", "cobblestone", "unpaved". Bitte sich dort > einzubringen, die Vorschlaege ergaenzen und dann darueber eine > Abstimmung herbeifuehren. > wiki ist nicht mein fall. aber ja, in diese richtung geht das. > > und dann natuerlich die nicht immer benoetigten aber durchaus > > notwendigen wie oneway, maxspeed, maxheight, ... > > "oneway" ist notwendig, wo gegeben, und "maxspeed" ist wuenschenswert > und sollte man IMHO immer mit aufnehmen, da man das bereits gut > auswerten kann und man damit auch spaeter andere Dinge (wie > Ortsgrenzen) auf Konsistenz ueberpruefen kann. > ganz genau. wo vorhanden, sollte das eingetragen sein. aber eine strasse kann auch keines davon haben. > > damit sollte man eigentlich alle strassen ausreichend und vor allem > > einigermassen eideutig beschreiben koennen. das klassische highway-tag > > ist dann nicht mehr noetig. > > IMHO wird es notwendig bleiben, um eine erste Grobklassifikation zu > haben. > die kann man sich dann eigentlich sparen, weil durch die drei basistags eigentlich alles gesagt ist. > > meinetwegen kann man noch ein tag hinzufuegen, dass die relative lokale > > wichtigkeit angibt, damit ein router eben solche strassen bevorzugt. > > Was ist eine "relative lokale Wichtigkeit"? Das waere ja noch > schwammiger als jetzt ... :-) > z.B. dass die umgehungsstrasse "besser" ist, als die genauso gut ausgebaute strasse durch die stadt. also wo eine route einer anderen eigentlich gleichwertigen oder besseren vorzuziehen ist. das soll ja auch nur sehr sparsam und wie gesagt nur lokal eingesetzt werden. man kann's aber auch ganz weglassen. signature.asc Description: This is a digitally signed message part. _
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Moin, > Ich sehe es inzwischen eigentlich auch so dass der highway-tag wegen > der Schwammigkeit und den vielen unterschiedlichen Meinungen zum > Aussterben verurteilt ist. sure. Kann aber noch ein bischen dauern. > Nur ist derzeit eben die gesamte gerenderte > OSM weltkarte darauf aufgebaut und eine schnelle Umstellung auf irgendwas > präziseres ist momentan undenkbar. Darauf zu hoffen dass die Leute > übergangsweise konsequent die alte und die neue Klassifizierung eingeben > ist auch ehr utopisch. Lass halt den Mappern die Wahl. > Um sowohl zu einem übergangslos durchgehenden > Kartenbild als auch langsam zu einem präzisem Abbild der Strassen nach > Routingkriterien zu kommen muss man dafür sorgen dass das fortan nach dem > "neuen" System eingegeben wird, dies aber gleichzeitig auch in das alte > System hinreichend genau umgesetzt wird. Dafür ist JOSM das richtige > Werkzeug, dass diebezüglich angepasst werden müsste. Bau doch ein paar Presets für JOSM, die beides optional abfragen und stell sie zur Verfügung. Wenn die Leute das cool finden werden sie es auch nutzen. Sie werden wohl vorübergehend mehr zu den highwaytags tendieren, aber wenn Du dann zeigen kannst welchen Nutzen man vom neuen Taggingschema hat werden die Leute bei Bedarf darauf reagieren. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo,
on Monday, 28 January 2008 11:53:19 +0100,
Guenther Meyer <[EMAIL PROTECTED]> writes:
> Am Montag 28 Januar 2008 schrieb Bernd Raichle:
> > on Sunday, 27 January 2008 17:09:03 +0100,
> > qbert biker <[EMAIL PROTECTED]> writes:
[...]
> > 'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich
> > mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite
> > ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder
> > hoch gekommene _administrative_ Zuordnung ignoriert habe (die gehoert
> > IMHO in's "ref"-Tag bzw. einem weiteren noch nicht beschriebenen Tag
> > wie "ref_admin_level" o.ae.). Aehnlich wie in GDF die Functional-
> > Road-Class (FRC) ist "highway" halt auch ein Kuddelmuddel und
> > schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden
> > grossen Kartenhersteller miteinander, die sind sich auch nicht immer
> > einig!
> >
> > Ok, aber welche Attribute willst du denn genau, die ein Routing mit
> > brauchbaren Ergebnissen erst ermoeglichen sollen?
>
> ich bin kein routing-experte, drum kann ich das nicht wirklich beurteilen.
> aber um eine strasse einigermassen realistisch abzubilden wuerde ich auf
> jeden fall folgende tags als "minimalen standard" verlangen wollen:
>
> highway:width = breite der strasse (nicht in zentimetern, sondern in ein
>paar definierten abstufungen)
Hast du fuer diese Abstufungen einen Vorschlag? Unter "width" wuerde
ich als Anfaenger jedoch annehmen, dass ich hier die tatsaechliche
(befahrbare) Breite in Meter oder Zentimeter angebe, evtl. halt auch
geschaetzt.
Du meinst da wohl eher so etwas wie "width_class" o.ae. Hier koennte
man dann beschreiben, ob die Spuren volle Breite haben ("lkw-faehig"),
ob es einen befestigten Seitenstreifen oder gar eine komplette
Standspur gibt. Dabei waere ein Blick ueber die Grenzen auch noch
wichtig, da ein Vorschlag auch fuer andere Laender passend sein
sollte.
> highway:lanes = anzahl der fahrspuren pro richtung (default-wert = 1)
Das Tag "lanes=..." gibt es. (Mir fehlt da eher noch eine
Moeglichkeit zu sagen, dass in eine Fahrtrichtung nur eine, in die
andere 2 Spuren zur Verfuegung stehen. Was gebe ich denn bei einer
Bundesstrassen mit zusammen 3 Spuren, wobei die mittlere wechselweise
zum Ueberholen verwendet wird, fuer "lanes" an? "lanes=1.5"? Sollte
aber wohl eher die "minimal number of lanes" sein.)
> highway:ref_loc = laenderspezifische zuordnung, wie z.B. "Kreisstrasse" in
>deutschland, um z.B. eine augsburger kreisstrasse (A123) nicht als
>autobahn zu sehen.
Man wird hoffentlich nie anhand des Praefixes der Strassennummer auf
die Art schliessen, oder? Hierfuer ist "highway" eindeutiger!
Statt "ref_loc" wuerde ich eher "ref_type" bzw. "ref_level" mit Werten
>= 1 verwenden (entsprechend "nat_ref_type" etc. fuer die anderen
"*_ref"-Tags). Werte fuer D: 1=E, 2=BAB, 3=B, 4=L+St, 5=K, evtl. 6
und groesser fuer andere Laender. In einem Vorschlag sollte man
zumindest fuer die wichtigsten Laender eine Zuordnung zu den
nationalen Bezeichnungen aufnehmen, um ein stimmiges Bild zu bekommen.
> optional noch folgende:
>
> highway:ref = administrative bezeichnung, wie z.B. "B22"
Es gibt bereits das "ref"-Tag.
> highway:surface = Oberflaechenbeschaffenheit, angegeben in definierten
>kategorien, um zu unterscheiden ob die strasse z.B. schoen eben ist,
>oder nur aus schlagloechern oder kies besteht.
Die Vorschlage "Road Surface", "surface values" gibt es schon im Wiki.
Ausserdem gibt es eine Key-Beschreibung fuer "surface=..." mit den
Werten "paved", "cobblestone", "unpaved". Bitte sich dort
einzubringen, die Vorschlaege ergaenzen und dann darueber eine
Abstimmung herbeifuehren.
> und dann natuerlich die nicht immer benoetigten aber durchaus notwendigen
> wie
> oneway, maxspeed, maxheight, ...
"oneway" ist notwendig, wo gegeben, und "maxspeed" ist wuenschenswert
und sollte man IMHO immer mit aufnehmen, da man das bereits gut
auswerten kann und man damit auch spaeter andere Dinge (wie
Ortsgrenzen) auf Konsistenz ueberpruefen kann.
> damit sollte man eigentlich alle strassen ausreichend und vor allem
> einigermassen eideutig beschreiben koennen. das klassische highway-tag ist
> dann nicht mehr noetig.
IMHO wird es notwendig bleiben, um eine erste Grobklassifikation zu
haben.
> meinetwegen kann man noch ein tag hinzufuegen, dass die relative lokale
> wichtigkeit angibt, damit ein router eben solche strassen bevorzugt.
Was ist eine "relative lokale Wichtigkeit"? Das waere ja noch
schwammiger als jetzt ... :-)
[...]
> > Eine Heuristik a la ``ich bleibe zuerst auf der Strasse mit "hoeherem"
> > "highway"-Tag'' fuehrt einen auf alle Faelle in die Irre, da ich dann
> > in deinem Beispiel zuerst mal von Sueden her kommend auf der B15 bis
> > zum Eisstadion und evtl. noch weiter durchfahren werde, so dass ich
> > dann bereits in der Stadt bin.
>
> aber meist hast du keine andere moeglichkeit
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Original-Nachricht
> Datum: Mon, 28 Jan 2008 11:14:31 +0100
> Von: Bernd Raichle <[EMAIL PROTECTED]>
> An: Openstreetmap allgemeines in Deutsch
> Betreff: Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo,
> 'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich
> mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite
> ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder
> hoch gekommene _administrative_ Zuordnung ignoriert habe
Und das ist der Punkt. Der eine ignorierts, der andere nicht. Ich
hab ja die deutsche Übersetzung (german_road_tagging) selber
überarbeitet und damals versucht, die englische Beschreibung
so genau wie möglich abzubilden. Und auf der englischen Liste
stehen schöne Dinge wie dass eine secondary größere Orte
verbindet. Der Kompromissvorschlag, dass secondary als
Hauptverbindungsstraße _typischerweise_ eine Staatsstraße wäre
wurde kommentarlos gestrichen. Jetzt steht wieder etwas drin,
was meiner Erfahrung nach faktisch falsch ist, also dass eine
Staatsstraße immer eine Hauptverbindungsstraße sein muss.
> schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden
> grossen Kartenhersteller miteinander, die sind sich auch nicht immer
> einig!
Schon klar, die frc ist ja auch ansich eine schwammige Sache.
Der Unterschied ist nur, dass man bei der frc gar nicht versucht,
den Spagat hinzubekommen, für die schwammige frc ein einzelnes alleingültiges
Merkmal zu finden, denn das gibts einfach nicht.
Die frc ist ein Ergebniswert aus mehreren konkreten Parametern,
die ihrerseits wieder weniger schwammig sind.
> Ok, aber welche Attribute willst du denn genau, die ein Routing mit
> brauchbaren Ergebnissen erst ermoeglichen sollen?
Die hatte ich doch schon genannt: Kreuzungsfreiheit, bzw Vorfahrt,
Limits, Ausbauzustand. Bei letzterem könnte man sich direkt
man bei der BAST schlau machen, denn die Querschnitte sind
zumindest in Deutschland ja genormt.
> In den GDF-Daten finde ich weder Ausbauzustand, noch Vorfahrt, noch
> Geschwindigkeitsbeschraenkungen _flaechendeckend_ vor. Wieso koennen
> dann alle Router/Navis darauf brauchbar routen?
Ich weiss nicht, wie die intern ihre Datenbanken halten, aber
ich gehe schon davon aus, dass die viel mehr vorhalten, als
sie über GDF konkret ausliefern. Die konkreten Daten werden dann
eben in einen schwammigen Wert wie die frc verrechnet, der
dadurch in Wirklichkeit gar nicht mehr so schwammig ist.
> Was braucht man zum Routen?
Ein Graph und einen Algorithmus der den kürzesten Weg rechnen
kann, sind schon mal der Anfang. Hier gehen Einbahnsituationen
schon mit ein. Das ist der Pflichtteil - die Kür ist die
Optimierung auf die Reisezeit hin. Die ist kein Hexenwerk, aber
sie braucht einen Minimalset an Informationen, damit sie
funktioniert.
> Dann ist die Ableitung deine Kantengewichte (sprich
> Kanten-Reisezeiten) schlecht. Die Umgehungsstrasse (du meinst du ihm
> Sued-Osten?) hat kaum Kreuzungen, und selbst die sind per
> "oneway"-Verbindungen also Auffahrten angelegt, ausserdem sollte sie
> ein entsprechendes "maxspeed"-Tag besitzen, das mit einem Wert >>50
> km/h eine Ausserorts-Klassifizierung zulaesst.
Wenn ich die das nächste mal fahre, schreib ich mir das
Limit auf. Sehr oft ist das bei solchen Straßen auf 60km/h und
daher kaum über den 50km/h in der Stadt. Der Rest ist sehr
schwierig für den Router zu erkennen. Ein divider-Tag über
die kreuzungsfreie Strecke kann da helfen, aber das muss
auch mal gesetzt und ausgewertet werden.
> Damit sollten die
> Reisezeiten hierauf entsprechend kleiner sein, so dass die
> inneroertlichen Strassen beim Routing schlechter abschneiden. Wo
> liegt da das Problem? ... ausser dass man halt etwas Hirnschmalz in
> eine passende heuristische Zuordnung von Kanten- Durchschnitts-
> geschwindigkeiten legen muss. Aber dies _muss_ man bei einer GDF-
> Karte (und auch bei den AND-Karten) auch tun.
Und dazu ist das highway-Tag eben nicht zu gebrauchen und
eine saubere innerorts/ausserorts-Steuerung gibts ja auch nicht.
Ich habe da eben ein Henne/Ein-Problem und werde deshalb
vorerst auf die AND-Daten ausweichen, weil bei denen bei der
Parametrisierung flächendeckend von ähnlichen Voraussetzungen
ausgegangen wurde. Damit kann man die Heuristik mal vernünftig
ansetzen. Spannend wirds dann, wenn man die dann auf OSM
ansetzt.
> Mmmh, wie klassifizierst du so etwas? "verkehrswichtig={1,2,3,4,5}"?
> Die eine Strasse ist verkehrswichtiger als die andere? ...
Ein Kriterium ist z.B. die Vorfahrt...
> ... und dann bist du auch bei "highway={primary,secondary,tertiary}".
Ohne das harte Mapping auf die administrativen Klassen schon,
aber derzeit macht es jeder bei highway anders. Die einen
pfeiffen auf die Kreisstraße und die anderen bilden das sklavisch
gena
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Am Montag 28 Januar 2008 schrieb Bernd Raichle: > Hallo, > > > on Sunday, 27 January 2008 17:09:03 +0100, > > qbert biker <[EMAIL PROTECTED]> writes: > > > Jupp, auch die GDF-Daten der beiden Grossen lassen von der "Functional > > > Road Class" nicht direkt auf Geschwindigkeiten bzw. Reisezeiten > > > ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im > > > Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine > > > eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur > > > zusammen mit anderen Attributen (Form-of-Way, innerorts vs. > > > ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute > > > Kanten-Reisezeiten. > > > > Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute > > einzuführen, die im Gegensatz zu 'highway' einigermassen exakt > > definiert sind und sich mit diesen Punkten beschäftigen. > > 'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich > mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite > ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder > hoch gekommene _administrative_ Zuordnung ignoriert habe (die gehoert > IMHO in's "ref"-Tag bzw. einem weiteren noch nicht beschriebenen Tag > wie "ref_admin_level" o.ae.). Aehnlich wie in GDF die Functional- > Road-Class (FRC) ist "highway" halt auch ein Kuddelmuddel und > schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden > grossen Kartenhersteller miteinander, die sind sich auch nicht immer > einig! > > Ok, aber welche Attribute willst du denn genau, die ein Routing mit > brauchbaren Ergebnissen erst ermoeglichen sollen? > ich bin kein routing-experte, drum kann ich das nicht wirklich beurteilen. aber um eine strasse einigermassen realistisch abzubilden wuerde ich auf jeden fall folgende tags als "minimalen standard" verlangen wollen: highway:width = breite der strasse (nicht in zentimetern, sondern in ein paar definierten abstufungen) highway:lanes = anzahl der fahrspuren pro richtung (default-wert = 1) highway:ref_loc = laenderspezifische zuordnung, wie z.B. "Kreisstrasse" in deutschland, um z.B. eine augsburger kreisstrasse (A123) nicht als autobahn zu sehen. optional noch folgende: highway:ref = administrative bezeichnung, wie z.B. "B22" highway:surface = Oberflaechenbeschaffenheit, angegeben in definierten kategorien, um zu unterscheiden ob die strasse z.B. schoen eben ist, oder nur aus schlagloechern oder kies besteht. und dann natuerlich die nicht immer benoetigten aber durchaus notwendigen wie oneway, maxspeed, maxheight, ... damit sollte man eigentlich alle strassen ausreichend und vor allem einigermassen eideutig beschreiben koennen. das klassische highway-tag ist dann nicht mehr noetig. meinetwegen kann man noch ein tag hinzufuegen, dass die relative lokale wichtigkeit angibt, damit ein router eben solche strassen bevorzugt. > > Ich baue keinen Router auf der highway-Info auf, weil ich nicht > > weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die > > statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von > > drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen > > wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz > > spezielle Geschichte und geht ja direkt aus dem Verlauf hervor. > > In den GDF-Daten finde ich weder Ausbauzustand, noch Vorfahrt, noch > Geschwindigkeitsbeschraenkungen _flaechendeckend_ vor. Wieso koennen > dann alle Router/Navis darauf brauchbar routen? > ich nehme an, dass deren daten im detail vollstaendiger sind. ausserdem: je mehr informationen vorhanden sind, desto mehr laesst sich so ein routing optimieren. wer weiss, vielleicht geht das mit unseren daten irgendwann besser als mit deren... > Eine Heuristik a la ``ich bleibe zuerst auf der Strasse mit "hoeherem" > "highway"-Tag'' fuehrt einen auf alle Faelle in die Irre, da ich dann > in deinem Beispiel zuerst mal von Sueden her kommend auf der B15 bis > zum Eisstadion und evtl. noch weiter durchfahren werde, so dass ich > dann bereits in der Stadt bin. > aber meist hast du keine andere moeglichkeit bei dem aktuellen datenbestand. und wenn dann eben einen dieses schwammige highway-tag in die irre fuehrt, hat man halt pech gehabt... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, on Sunday, 27 January 2008 17:09:03 +0100, qbert biker <[EMAIL PROTECTED]> writes: > > Jupp, auch die GDF-Daten der beiden Grossen lassen von der "Functional > > Road Class" nicht direkt auf Geschwindigkeiten bzw. Reisezeiten > > ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im > > Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine > > eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur > > zusammen mit anderen Attributen (Form-of-Way, innerorts vs. > > ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute > > Kanten-Reisezeiten. > > Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute > einzuführen, die im Gegensatz zu 'highway' einigermassen exakt > definiert sind und sich mit diesen Punkten beschäftigen. 'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder hoch gekommene _administrative_ Zuordnung ignoriert habe (die gehoert IMHO in's "ref"-Tag bzw. einem weiteren noch nicht beschriebenen Tag wie "ref_admin_level" o.ae.). Aehnlich wie in GDF die Functional- Road-Class (FRC) ist "highway" halt auch ein Kuddelmuddel und schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden grossen Kartenhersteller miteinander, die sind sich auch nicht immer einig! Ok, aber welche Attribute willst du denn genau, die ein Routing mit brauchbaren Ergebnissen erst ermoeglichen sollen? > Ich baue keinen Router auf der highway-Info auf, weil ich nicht > weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die > statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von > drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen > wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz > spezielle Geschichte und geht ja direkt aus dem Verlauf hervor. In den GDF-Daten finde ich weder Ausbauzustand, noch Vorfahrt, noch Geschwindigkeitsbeschraenkungen _flaechendeckend_ vor. Wieso koennen dann alle Router/Navis darauf brauchbar routen? In den im Markt befindlichen Releases sind Speed-Limits nur fuer die Hauptverkehrsstrassen aufgenommen, alle anderen werden aus der Inner-/Ausserorts-Beziehung abgeleitet (sprich: 50 bzw. 100 in D). Vorfahrts-Beziehungen sind nur vereinzelt vorhanden. Ausbauzustand gibt's neben den FRC und getrennte Richtungsfahrbahnen direkt nur ein "paved"/"unpaved". Was braucht man zum Routen? Zum einen eine Optimierungsfunktion, die fuer die schnellste Route eben die aufsummierten Kanten-Reisezeiten minimiert. Zum anderen fuer jede Kante eine Reisezeit ... und genau die kann ich mit ein paar Heuristiken, sprich angenommenen Geschwindigkeiten aus den vorhandenen GDF-, aber auch aus den vorhandenen OSM-Attributen und -Relationen mir erstellen. Dazu gibt der FRC bzw. "highway" aber nur eine erste Grobklassifikation, die aber durch andere Attribute wie "oneway" (deutet bei langen Kanten auf getrennte Richtungsfahrbahnen hin), "maxspeed" (daraus bekommt man momentan ausserorts, innerorts, 30er-Zone), "roundabout" und Dingen wie kurze Kantenstuecke/viele Kreuzungen (mit/ohne Ampeln), Kreuzungen mit "*_link" etc. ganz gut ergaenzt einem eine Durchschnitts- geschwindigkeit ableiten lassen, die gut genug zum Routen ist! > Im derzeitigen Zustand der Karte findet der Router wichtige > Verkehrsbeziehungen nicht, weil sie aus der administrativen > Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die > Umgehung von Rosenheim (OBB). Die ist derzeit als secondary > drin und war schon mal tertiary. Damit ist sie nicht mehr > aus dem normalen Hauptstraßengewirr herausgehoben und der > Router schickt die Leute auf dem kürzesten Weg durch die > Stadt, also mitten durch den Rummel mit vielen Ampeln. Dann ist die Ableitung deine Kantengewichte (sprich Kanten-Reisezeiten) schlecht. Die Umgehungsstrasse (du meinst du ihm Sued-Osten?) hat kaum Kreuzungen, und selbst die sind per "oneway"-Verbindungen also Auffahrten angelegt, ausserdem sollte sie ein entsprechendes "maxspeed"-Tag besitzen, das mit einem Wert >>50 km/h eine Ausserorts-Klassifizierung zulaesst. Damit sollten die Reisezeiten hierauf entsprechend kleiner sein, so dass die inneroertlichen Strassen beim Routing schlechter abschneiden. Wo liegt da das Problem? ... ausser dass man halt etwas Hirnschmalz in eine passende heuristische Zuordnung von Kanten- Durchschnitts- geschwindigkeiten legen muss. Aber dies _muss_ man bei einer GDF- Karte (und auch bei den AND-Karten) auch tun. Eine Heuristik a la ``ich bleibe zuerst auf der Strasse mit "hoeherem" "highway"-Tag'' fuehrt einen auf alle Faelle in die Irre, da ich dann in deinem Beispiel zuerst mal von Sueden her kommend auf der B15 bis zum Eisstadion und evtl. noch weiter durchfahren werde, so dass ich dann bereits in der Stadt bin. > Alles was ich will ist, dass der Mapper (und damit auch ich ;)) > ein W
Re: [Talk-de] Reisezeiten
Original-Nachricht > Datum: Mon, 28 Jan 2008 05:33:52 +0100 > Von: [EMAIL PROTECTED] > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Reisezeiten > > Im derzeitigen Zustand der Karte findet der Router > > wichtige Verkehrsbeziehungen nicht, weil sie aus der > > administrativen Zuordnung nicht hervorgehen. Ein schönes > > Beispiel ist die Umgehung von Rosenheim (OBB). Die ist > > derzeit als secondary drin und war schon mal tertiary. > > > Was ich immer sage: die administrativen Zuordnung wird > überbewertet. An Deiner Stelle würde ich die Umgehung > eine Stufe höher und die Bundesstraße eine Stufe niedriger > zu taggen. Und zwar jetzt sofort. Hab sie ursprünglich mal als trunk eingetragen und damals passte das wie die Faust aufs Auge. Dann kam eine Diskussion auf, was trunk wohl wäre und manche sehen da bauliche Trennung drin, was die Umgehung nicht hat. Jemand hat sie dann ein paar mal umgewidmet und das Ding hat die Farbe gewechselt wie ein Chamelion. Natürlich könnte ich ein anderes highway-tag vergeben, aber in Kürze wär das dann wieder überschrieben und in gewissem Sinne hätte der damit sogar recht. Wenn er das Schildchen abliest und da steht ROxxx drauf ists nunmal ein tertiary. Der Fehler liegt im System und damit darin, dass jeder in das highway-tag etwas anderes interpretiert. Ich sehe nur einen Lösungsansatz und der ist zu fixieren, was highway aussagen soll und wenns fix die administrative Zuordnung ist, ists auch OK. Nur dann ist eben ein zusätzliches Tag wie functional road class (frc) zwingend notwendig und das nicht als 'jeder macht was er will'-Ansatz sondern als übergreifende Vereinbarung. Seit hier rumgeistert, dass das ganze Abstimmungssystem für die Katz ist, weil ja sowieso nicht bindend, weiss ich nur nicht, man das auf die Reihe bekommen könnte. Grüsse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten
> Im derzeitigen Zustand der Karte findet der Router > wichtige Verkehrsbeziehungen nicht, weil sie aus der > administrativen Zuordnung nicht hervorgehen. Ein schönes > Beispiel ist die Umgehung von Rosenheim (OBB). Die ist > derzeit als secondary drin und war schon mal tertiary. Was ich immer sage: die administrativen Zuordnung wird überbewertet. An Deiner Stelle würde ich die Umgehung eine Stufe höher und die Bundesstraße eine Stufe niedriger zu taggen. Und zwar jetzt sofort. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Am Sonntag 27 Januar 2008 schrieb qbert biker: > Hallo, > > > Jupp, auch die GDF-Daten der beiden Grossen lassen von der "Functional > > Road Class" nicht direkt auf Geschwindigkeiten bzw. Reisezeiten > > ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im > > Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine > > eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur > > zusammen mit anderen Attributen (Form-of-Way, innerorts vs. > > ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute > > Kanten-Reisezeiten. > > Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute > einzuführen, die im Gegensatz zu 'highway' einigermassen exakt > definiert sind und sich mit diesen Punkten beschäftigen. > der sinn und das schoene am highway-tag ist ja eigentlich, mit einem tag eine strasse kategorisieren zu koennen. dass das immer irgendwie schwammig bleiben wird, sist eigentlich klar. auch ein neues definiertes tagging-schema wuerde da warscheinlich bei vielen strassen an seine grenzen stossen, wenn auch die zuordnung wohl genauer werden wuerde. inzwischen werden ja immer wieder irgendwelche zusatztags und attribute verwendet, um die gegebenheiten besser abzubilden. vielleicht waere es da nicht mal so verkehrt, generell etwas von dem "ein tag beschreibt alles" schema etwas wegzukommen. d.h. es gibt nicht mehr ein highway-tag, sondern ein paket von drei oder vier genau definierten attributen, die die strasse beschreiben, und dies wesentlich genauer koennen. > Im Fall der Umgehung von Rosenheim bedeutet die derzeitige > Einordnung, dass alle Routen die Rosenheim queren nicht die > sind, die ein Anwender erwartet, der auf schnellstem Weg > weiter will. Kleine Ursache, grosse Wirkung. > > Konkreter Vorschlag: > highway bleibt secondary > frc beschreibt die Wichtigkeit und > divider beschreibt die kreuzungsfreiheit. > sowas in der richtung... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, > Jupp, auch die GDF-Daten der beiden Grossen lassen von der "Functional > Road Class" nicht direkt auf Geschwindigkeiten bzw. Reisezeiten > ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im > Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine > eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur > zusammen mit anderen Attributen (Form-of-Way, innerorts vs. > ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute > Kanten-Reisezeiten. Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute einzuführen, die im Gegensatz zu 'highway' einigermassen exakt definiert sind und sich mit diesen Punkten beschäftigen. Ich baue keinen Router auf der highway-Info auf, weil ich nicht weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz spezielle Geschichte und geht ja direkt aus dem Verlauf hervor. Im derzeitigen Zustand der Karte findet der Router wichtige Verkehrsbeziehungen nicht, weil sie aus der administrativen Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die Umgehung von Rosenheim (OBB). Die ist derzeit als secondary drin und war schon mal tertiary. Damit ist sie nicht mehr aus dem normalen Hauptstraßengewirr herausgehoben und der Router schickt die Leute auf dem kürzesten Weg durch die Stadt, also mitten durch den Rummel mit vielen Ampeln. Alles was ich will ist, dass der Mapper (und damit auch ich ;)) ein Werkzeug an die Hand bekommt um auf die Straße zu schauen und die in OSM beschreiben: Das ist eine etwas breitere Kreisstraße die in diesem Bereich kreuzungsfrei ausgebaut ist und sehr verkehrswichtig ist. Solange er sich entscheiden muss, ob der jetzt trunk, secondary oder tertiary ist und jeweils wichtige Detailinfo auf der Strecke bleibt, ist das Verfahren suboptimal. Im Fall der Umgehung von Rosenheim bedeutet die derzeitige Einordnung, dass alle Routen die Rosenheim queren nicht die sind, die ein Anwender erwartet, der auf schnellstem Weg weiter will. Kleine Ursache, grosse Wirkung. Konkreter Vorschlag: highway bleibt secondary frc beschreibt die Wichtigkeit und divider beschreibt die kreuzungsfreiheit. > Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise > nur einige Prozent von der real benoetigten Reisezeit abweichen, > solange man keine Staus und andere Stoerungen hat. Will man bessere > Werte, d.h eine geringere Abweichung muss man so oder so dynamische > Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien, > um so die ueblichen Pendlerstroeme mit einzubeziehen ... so wie dies > auch (alle? die meisten?) aktuellen Router/Navis machen. Na ja, über die Qualität des dynamischen Routings kann man sich streiten. Da ist wohl auch bei den grossen mehr Schein als Sein. Statistische Verfahren funktionieren so la la und die direkte Ableitung aus den Verkehrsmessgrößen (Induktionsschleifen/'Ufos') ist auch nicht viel besser. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Am Sonntag, 27. Januar 2008 12:23:04 schrieb Bernd Raichle: > Das groesste Problem aber ist leider immer noch, dass ich sehr haeufig > nicht verbundene Way-Kreuzungen vorfinde, d.h. wo die Endknoten von > zwei oder mehr Ways nicht verbunden sind, sondern nur knapp > nebeneinander liegen. Und dies ist fuers Routing nun wirklich > problematisch, da damit gerade die Routen im "Nahbereich", also beim > Start oder Ziel, oft "unsinnige" Ergebnisse liefern. Hier waere ein > "maplint"- bzw. Josm-Validator-Test wirklich hilfreich, auch wenn ein > solcher Test oefters "false positives" liefern wird, wo Wegenden sehr > nahe beieinander liegen, aber eben doch (durch Mauern, Zaeune, > unterschiedliche Hoehen) unueberwindbar getrennt sind. Das wäre wirklich eine große Hilfe! Ich hatte hier bei mir in der Umgebung auch einen Neuling, der komplette Stadtteile mit Potlach gezeichnet hat und dabei kaum eine Kreuzung verbunden hat. Es hat wahnsinnig lange gedauert, das alles zu korrigieren - und selbst jetzt bin ich mir nicht 100% sicher, daß alles OK ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
