Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 19.02.2015 um 23:29 schrieb Florian Lohoff: Gibt es stand heute irgendeine Routingengine für OSM die Geometrien der Straße (Also ausser länge) auswertet? Ich kenne derzeit keine. Garmin mit OSM Karten macht das (Spitzwinkel-Malus). Defakto sind alle router heute total stumpf: switch(highway) trunk) avgspeed=75 residential) avgspeed=10 So zur Veranschaulichung. Selbst der Maxspeed wird nicht in jedem fall zu rate gezogen. Damit lassen sich auch für 90-95% aller fälle sehr passable resultate erzielen. Ja, für die Routenfindung reicht es die Straßenklassifikation heranzuziehen. Mehr Heuristik ist manchmal sogar kontraproduktiv. Die Ampelvermeidungsstategie von OSRM hat manchmal zu merkwürdigen Routen geführt. maxspeed-Auswertung ist aber nützlich zur Verbesserung der ETA (estimated time of arrival) Kalkulation. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 19. Februar 2015 um 23:06 schrieb Garry garr...@gmx.de: Am 19.02.2015 um 11:31 schrieb Martin Vonwald: Kein professioneller Router geht davon aus, dass man die maximal erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert einen professionellen Router die maximal Woher hat er die Information? Aus dem Preprocessing, Tags oder schaut er sich jedesmal den Verlauf an? Letzteres könnte langwierig werden, oder? Aus dem Preprocessing wo auch der Streckenverlauf ausgewertet wird. Tags wären völlig sinnlos, denn wofür sollen sie gelten: den Fußgänger, das Fahrrad, den Kombi, den Kleinlaster oder den Sattelschlepper? Nur falls das nicht offensichtlich ist: auf ein Fahrrad haben enge Kurven deutlich weniger Auswirkung als auf einen Sattelschlepper und einem Fußgänger ist es völlig egal. Auch das Höhenprofil wirkt sich unterschiedlich aus. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Alexander Lehner wrote on 19.02.2015 17:07: On Thu, 19 Feb 2015, Florian Lohoff wrote: Anliegerverbote sind ein extrem schwieriges Thema zu dem auch noch anderes gehört wie z.b. Tracks. Am Ende werden alle verbote zu einem access=destination. Selbst wenn auf einer Straße ein access=no oder das nur ein Fußweg ist muss der router das dingen benutzen wenn das Ziel an diesem Weg liegt. Deshalb macht OSRM auch murks wenn ich nach Hause möchte. Ich liege an einem Waldweg - nicht asphaltiert, forstwirtschaftlicher Verkehr frei - typ track/grade4. Ja - den muss man befahren um zu mir zu kommen. Dem kann ich mich nur anschliessen, ich wohne aehnlich 'privilegiert' (Sackgasse, Schotterweg, Privatweg). Bis vor ein paar Jahren haben kommerzielle Navis das ueberhaupt nicht gefunden, OSM schon. Inzwischen sagen sie 'die Route beinhaltet nicht-befestigte Teile' oder so... Wenn es keine alternative Zufahrt gibt, muss man da halt durch. Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? Ich will bei einem ein Meter breiten Trampelpfad nicht mit dem Auto geführt werden. Da fänd ich es sinnvoll, wenn ein Router fürs Auto sagt: Hier kommst/darfst du nicht hin, parke dein Auto entweder irgendwo (oder an dem Parkplatz xy) und geh den Rest zu Fuß (wenn die Daten das dann erlauben). Evtl ist bei euch ja auch folgendes Tagging richtiger: foot=yes bicycle=yes motorcar=private agricultural=yes -- Grüße Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 20. Februar 2015 um 00:32 schrieb Patrick Niklaus patrick.nikl...@student.kit.edu: Also: Bitte nicht Anfangen unnötig genaue Geometrien zu erfassen. Das führt nur zu unnötig großen Daten! das sehe ich evtl. anders (wobei, vielleicht auch nicht, unnötig genau will ich auch nicht, aber was damit gemeint ist, sollte man vielleicht vorher klären). Genaue Geometrien zu erfassen halte ich für wichtig, geometrische Details sind genauso Informationen wie tags auch, und man kann durchaus was damit anfangen. Ich will nicht dazu aufrufen, alle 5 cm einen Node zu setzen (da man Kurven ja beliebig fein in Linienzüge umwandeln kann, ist es natürlich immer möglich, die Nodeanzahl einer nicht geraden Strecke zu erhöhen und damit eine feinere Auflösung zu erhalten), sondern würde das eher an den Winkeln ausmachen, d.h. je stärker gekrümmt um so enger sollten auch die Nodes gesetzt werden. Wen unnötig große Daten stören, der kann sich die Daten ja wieder grob rechnen, das ist trivial, während es anders rum kaum geht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 20. Februar 2015 um 10:42 schrieb Holger Jeromin mailgm...@katur.de: Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? Ich will bei einem ein Meter breiten Trampelpfad nicht mit dem Auto geführt werden. das ist aber kein Problem, zumindest nicht so, evtl. tritt ein Problem bei sehr langen Fahrzeugen wie z.B. LKW auf. Prinzipiell ist doch aus unseren Daten klar, ob ein PKW von der Breite her durchkommt (highway path vs. track/service, im Zweifel kann man noch width angeben oder entsprechende legale Beschränkungen). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 20.02.2015 um 13:39 schrieb Martin Koppenhoefer: Am 20. Februar 2015 um 10:42 schrieb Holger Jeromin mailgm...@katur.de: Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? Ich will bei einem ein Meter breiten Trampelpfad nicht mit dem Auto geführt werden. das ist aber kein Problem, zumindest nicht so, evtl. tritt ein Problem bei sehr langen Fahrzeugen wie z.B. LKW auf. Prinzipiell ist doch aus unseren Daten klar, ob ein PKW von der Breite her durchkommt (highway path vs. track/service, im Zweifel kann man noch width angeben oder entsprechende legale Beschränkungen). track/service vs path funktioniert nur in eine Richtung. Ein highway=path kann auch 10 Meter breit sein und vehicle=private ist durch aus möglich. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SotM.us güstige Flüge
Am 19.02.2015 um 10:16 schrieb Christoph Hormann: On Thursday 19 February 2015, Peter Barth wrote: dass sich der Termin zig mal verschoben hat, hab ich mitbekommen. Aber woher hast du die Info, dass es gar keine SOTM geben wird? http://wiki.osmfoundation.org/wiki/Board/Minutes/2015-02-16 Dass man solche Informationen quasi Im Keller hinter einer Tür mit der Aufschrift 'Vorsicht, bissiger Leopard!' findet ist natürlich alles andere als eine kommunikative Meisterleistung... Wobei da ja auch klar steht dass das zu kommunizieren sei, was bis jetzt nicht gemacht wurde. Zitat: =Schnipp=== Board agrees that SotM-WG can and should announce ASAP that there is no SotM-2015, and commence work on the bid process for SotM 2016 =Schnapp=== OK, das F2F lief gerade erst diese Woche in Berlin = die Leute müssen auch erst mal wieder zuhaus ankommen. Aber es ist IMHO schon etwas irgendwie bezeichnend was die SOTM (bzw. im speziellen 2015) angeht... Wäre ja eigentlich sinnvoll, wenn es dann auch wieder 'ne SotM-EU gäbe, aber natürlich nicht wieder in Deutschland. +1 Grundsätzlich hätte ich mit einer SOTM-EU @DE kein Problem, aber die anderen Communities sollen auch Ihre Chance kriegen. ;-) Wobei: es ist etwas knapp (oder zumindest sportlich) jetzt noch eine Konferenz komplett aus dem Boden zu stampfen. Für die deutschsprachige Community somit ein Grund mehr die FOSSGIS zu besuchen. Grüße, Michael. PS: hatte vorgestern auch keine preiswerten Flüge gefunden, irgendwo ging es bei rund 600€ los. Selbst wenn man noch 15% abrechnen würde ist das viel Geld für Privatpersonen (da kommt ja noch Übernachtung @NYC dazu, auch kein Kindespiel)... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 20. Februar 2015 um 00:32 schrieb Patrick Niklaus patrick.nikl...@student.kit.edu: Also: Bitte nicht Anfangen unnötig genaue Geometrien zu erfassen. Das führt nur zu unnötig großen Daten! das sehe ich evtl. anders (wobei, vielleicht auch nicht, unnötig genau will ich auch nicht, aber was damit gemeint ist, sollte man vielleicht vorher klären). Genaue Geometrien zu erfassen halte ich für wichtig, geometrische Details sind genauso Informationen wie tags auch, und man kann durchaus was damit anfangen. Ich will nicht dazu aufrufen, alle 5 cm einen Node zu setzen (da man Kurven ja beliebig fein in Linienzüge umwandeln kann, ist es natürlich immer möglich, die Nodeanzahl einer nicht geraden Strecke zu erhöhen und damit eine feinere Auflösung zu erhalten), sondern würde das eher an den Winkeln ausmachen, d.h. je stärker gekrümmt um so enger sollten auch die Nodes gesetzt werden. Wen unnötig große Daten stören, der kann sich die Daten ja wieder grob rechnen, das ist trivial, während es anders rum kaum geht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Hola, On Fri, Feb 20, 2015 at 10:42:24AM +0100, Holger Jeromin wrote: Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? Ich will bei einem ein Meter breiten Trampelpfad nicht mit dem Auto geführt werden. Es gibt keinen alternativen weg. Es gibt keine Möglichkeit anders zu mir zu kommen. Soll also der Router 500m entfernt auf einer Service road (Die völlig abstrus liegt aber geometrisch am nächsten am ziel ist) stoppen und dir noch eine Luftlinie zeigen? So geschieht das im moment. Da fänd ich es sinnvoll, wenn ein Router fürs Auto sagt: Hier kommst/darfst du nicht hin, parke dein Auto entweder irgendwo (oder an dem Parkplatz xy) und geh den Rest zu Fuß (wenn die Daten das dann erlauben). Also das sollte man schon selber entscheiden können ob ich mit dem Auto noch irgendwo reinfahre oder nicht. Das ist so ein bischen wie die Leute die dem Navi hinterher hin den Fluß fahren. Evtl ist bei euch ja auch folgendes Tagging richtiger: foot=yes bicycle=yes motorcar=private agricultural=yes Der Punkt ist das OSRM stand heute KEINE tracks benutzt. Egal was passiert. Wenn es aber die einzige möglichkeit ist einen Ort zu erreichen ist die Nutzung legitim. MapQuest macht es vor. Mapfactor Navigator auch. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Florian Lohoff wrote on 20.02.2015 14:16: On Fri, Feb 20, 2015 at 10:42:24AM +0100, Holger Jeromin wrote: Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? Ich will bei einem ein Meter breiten Trampelpfad nicht mit dem Auto geführt werden. Es gibt keinen alternativen weg. Es gibt keine Möglichkeit anders zu mir zu kommen. Soll also der Router 500m entfernt auf einer Service road (Die völlig abstrus liegt aber geometrisch am nächsten am ziel ist) stoppen und dir noch eine Luftlinie zeigen? So geschieht das im moment. Da fänd ich es sinnvoll, wenn ein Router fürs Auto sagt: Hier kommst/darfst du nicht hin, parke dein Auto entweder irgendwo (oder an dem Parkplatz xy) und geh den Rest zu Fuß (wenn die Daten das dann erlauben). Also das sollte man schon selber entscheiden können ob ich mit dem Auto noch irgendwo reinfahre oder nicht. Das ist so ein bischen wie die Ein Navi/Karte ist eigentlich dazu da, dir von zuhause zu sagen, was geht und was nicht. Leute die dem Navi hinterher hin den Fluß fahren. Aber der Router kann nicht entscheiden, ob es sinnvoll ist den Track jetzt zu benutzen oder nicht. Oder willst du, dass der Router dich mit deinem Auto bis auf das Basislager des Mt.Everest lotst, da Wenn es keine alternative Zufahrt gibt, muss man da halt durch. auch hier gilt? Evtl ist bei euch ja auch folgendes Tagging richtiger: foot=yes bicycle=yes motorcar=private agricultural=yes Der Punkt ist das OSRM stand heute KEINE tracks benutzt. Egal was passiert. Wenn es aber die einzige möglichkeit ist einen Ort zu erreichen ist die Nutzung legitim. MapQuest macht es vor. Mapfactor Navigator auch. https://github.com/Project-OSRM/osrm-backend/issues/1219#issuecomment-59010196 -- Grüße Holger Jeromin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Falls du Abbiegerelationen findest die nicht funktionieren ... Mir ist das hier aufgefallen: https://www.openstreetmap.org/directions?engine=osrm_carroute=49.51347%2C8.54672%3B49.51337%2C8.54679#map=19/49.51335/8.54609 Am Kreuzungssternpunkt darf nicht gewendet werden (Relation: only straight forward) Gefährlich sind solche Streckenführungen, wo von einer trunk road in eine schmale Anliegerstraße (Schaafeckweg) geroutet wird, die man nicht benutzen darf und auf der trunk road niemand mit einem bremsenden Fahrzeug rechnet: https://www.openstreetmap.org/directions?engine=osrm_carroute=49.51705%2C8.54314%3B49.51503%2C8.54752#map=17/49.51708/8.54751 Normalerweise darf in einen Anliegerbereich nur dann eingefahren werden, wenn er bis zum Ziel nicht mehr verlassen wird. Das klappt aber nur, wenn destination im Anliegerbereich lückenlos eingetragen ist, was oft nicht der Fall ist. Das ist sicherlich schwierig auszuwerten. Seltsam finde ich auch solche Wendemanöver, wo man gar nicht wenden kann und hier dazu eine Straße mit access = private benutzen muss: https://www.openstreetmap.org/directions?engine=osrm_carroute=49.50801%2C8.53086%3B49.50812%2C8.53112#map=19/49.50800/8.53132 Bernhard -Ursprüngliche Nachricht- Von: Patrick Niklaus [mailto:patrick.nikl...@student.kit.edu] Gesendet: Freitag, 20. Februar 2015 00:32 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] heise berichtet ueber osm.org-Routing integration Ich würde OSRM von der Auswahl entfernen, bis sie z. B. auch Abbiegerelationen und Anliegerstraßen beachtet, die gehören meiner Meinung nach zu den Grundfunktionen. Falls du Abbiegerelationen findest die nicht funktionieren, dann poste das bitte hier [1]. Momentan nicht unterstützt werden lediglich Abbiegerelationen bei den via ein Way ist. Von daher sehe ich weniger die fehlenden maxspeed-Tags als Problem als vielleicht zu grob erfasste Straßenverläufe die den realen Verlauf zu sehr begradigen. Auf Grund der Größe der Daten verwerfen die meisten Router die geometrische Information schon beim Pre-Processing*. Das worauf der wirkliche Routing-Algorithmus ausgeführt ist deutlich abstrakter als das Straßennetzwerk das ein Mensch auf einer Karte wahrnimmt. (* zumindest für das eigentliche Routing, am Ende braucht man es schon wieder um eine Linie auf die Karte zeichnen zu können) Also: Bitte nicht Anfangen unnötig genaue Geometrien zu erfassen. Das führt nur zu unnötig großen Daten! (ein echtes Problem, zusehen auch bei den TIGER Imports in den USA) Um tatsächlich halbwegs verlässliche ETAs zu bekommen braucht es allerdings wirklich gemessene Daten von echten Fahrzeugen (kann aus hinreichend vielen GPS Traces berechnet werden). OSM kann einfach Dinge wie Verkehrsaufkommen u.Ä. nicht erfassen. Wenn man das nicht hat, muss man sich leider auf Heuristiken verlassen [2]. Hinreichende Abdeckung von maxspeed Tags kann da sicherlich nicht schaden. Wer wirklich helfen will die Daten zu verbessern sollte sich auf zwei Dinge konzentrieren: Konnektivität, Abbiegerelationen, Zugangsberschränkungen. Natürlich ist fehlende Straßen erfassen auch gut. :-) map.project-osrm.org hat ein Small Components Layer um das Konnektivität fixen etwas einfacher zu machen. Pinke Straßen sind nicht mit dem Rest des Straßennetzwerks verbunden. [1] https://github.com/Project-OSRM/osrm-backend/issues [2] https://github.com/Project-OSRM/osrm- backend/blob/develop/profiles/car.lua ... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Von: Bernhard Weiskopf [mailto:bweisk...@gmx.de] Gesendet: Freitag, 20. Februar 2015 22:50 An: 'Openstreetmap allgemeines in Deutsch' Betreff: AW: [Talk-de] heise berichtet ueber osm.org-Routing integration Falls du Abbiegerelationen findest die nicht funktionieren ... Mir ist das hier aufgefallen: https://www.openstreetmap.org/directions?engine=osrm_carroute=49. 51347%2C8.54672%3B49.51337%2C8.54679#map=19/49.51335/8.54609 Am Kreuzungssternpunkt darf nicht gewendet werden (Relation: only straight forward) Gerade bemerkt: Bei OSRM direkt stimmt die Streckenführung: http://osrm.at/b3P Die fehlerhafte Darstellung bei openstreetmap.org liegt vermutlich an der zu groben Auflösung der Streckenmarkierung. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Holger Jeromin wrote on 20.02.2015 15:21: Florian Lohoff wrote on 20.02.2015 14:16: On Fri, Feb 20, 2015 at 10:42:24AM +0100, Holger Jeromin wrote: Du sagst das, aber die Daten nicht. Sind dann nicht die Daten falsch? ... Evtl ist bei euch ja auch folgendes Tagging richtiger: foot=yes bicycle=yes motorcar=private agricultural=yes Der Punkt ist das OSRM stand heute KEINE tracks benutzt. Egal was passiert. Wenn es aber die einzige möglichkeit ist einen Ort zu erreichen ist die Nutzung legitim. MapQuest macht es vor. Mapfactor Navigator auch. https://github.com/Project-OSRM/osrm-backend/issues/1219#issuecomment-59010196 Danke, dass du mir die Stelle per Mail geschickt hast. Der Weg hat ja schon folgende Tags: hgv=destination highway=track motorcar=destination motorcycle=destination Ich hätte gedacht, dass osrm tracks nutzt, wenn der access richtig ist. Dann mach doch ein neues Ticket auf. Obige Kombi sollte definitiv im Auto-Profil erlaubt sein. -- Grüße Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am Freitag, 20. Februar 2015, 00:32:24 schrieb Patrick Niklaus: Ich würde OSRM von der Auswahl entfernen, bis sie z. B. auch Abbiegerelationen und Anliegerstraßen beachtet, die gehören meiner Meinung nach zu den Grundfunktionen. Falls du Abbiegerelationen findest die nicht funktionieren, dann poste das bitte hier [1]. Momentan nicht unterstützt werden lediglich Abbiegerelationen bei den via ein Way ist. Was schade ist, denn an dieser Stelle http://www.openstreetmap.org/directions?engine=osrm_carroute=53.60779%2C10.03524%3B53.60774%2C10.03872#map=18/53.60797/10.03697 gibt es dazu keine Alternative. Am Ende der Verkehrsinsel beginnt nahtlos eine Busspur, die nicht gequert werden darf. Rechtsabbieger müssen also rechts an der Verkehrsinsel vorbei fahren, alle anderen links. Google behilft sich mit falscher Straßendarstellung, die können es also auch nicht. Hätte OSM also die Nase vorn haben können... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de