Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am 19. Oktober 2009 02:16 schrieb Garry garr...@gmx.de: qbert biker schrieb: Sehe ich ein bichen anderst... zwischen den Abbiegespuren darf nicht mehr so frei gewechselt werden wie zwischen normalen Fahrpuren - bei durchgezogener Linie darf ich die Spur gar nicht wecheln ..was üblicherweise kurz vor Beginn der eigenständigen Fahrbahn der Abfahrt der Fall ist, weshalb man hier m.E. auch problemlos den Punkt des Abzweigs der OSM-Ways an diese Stelle verschieben kann. Es gibt aber Leute, die die komplette Spur seit ihrem beginn als eigenständige Straße regelrecht malen, weil's in Mapnik so cool aussieht... Wann ein Navi Ansagen zum Abbiegen macht, sollte auch nicht an unseren Daten liegen - mein Vista Hcx sagt auf Autobahnen z.B. gut 1,2km vorher an, wenn ich mich recht erinnere. und bei getrichelter Linie darf ich eine Abbigespur nicht zum überholen missbrauchen... Führ das Routing sehe ich separate OSM-Ways für Abbiegepuren daher ehr als hilfreich an... Was hat routing mit Überholen zu tun? überholen sie *jetzt*, der Typ fährt zu langsam!? ;-) -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
On Mon, 19 Oct 2009 09:19:51 +0200, Martin Simon grenzde...@gmail.com wrote: und bei getrichelter Linie darf ich eine Abbigespur nicht zum überholen missbrauchen... Führ das Routing sehe ich separate OSM-Ways für Abbiegepuren daher ehr als hilfreich an... Inwieweit sollten sie hilfreich sein, solange sie von separaten Strassen nicht unterschieden werden können? (und jetzt bitte kein aber das ist doch offensichtlich wenn die alle parallel laufen.) Willst du ein bitte rechts abbiegen auf UNBENANNT und dann ein bitte rechts abbiegen auf Strasse XYZ wenn du eine Abbiege-Spur auf Strasse XYZ hast? Spuren sind was eigenes und brauchen ein Tagging-Schema. Das mit Wegen zu machen ohne diese irgendwie eindeutig mit einer allgemein bekannten und dokumentiertem Art zu taggen und in einer Weise mit der auch Navis ohne Unterstützung für Fahrspuren zurecht kommen (Garmin-Export z.B.) können macht nur bestehende Daten kaputt. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Original-Nachricht Datum: Mon, 19 Oct 2009 02:16:39 +0200 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise Sehe ich ein bichen anderst... zwischen den Abbiegespuren darf nicht mehr so frei gewechselt werden wie zwischen normalen Fahrpuren - bei durchgezogener Linie darf ich die Spur gar nicht wecheln und bei getrichelter Linie darf ich eine Abbigespur nicht zum überholen missbrauchen... Führ das Routing sehe ich separate OSM-Ways für Abbiegepuren daher ehr als hilfreich an... Der Unterschied besteht in der Unterscheidung von koennen und duerfen. Wer nur abbildet was der Autofahrer darf, verhindert damit eine realitaetsgetreue Abbildung der physischen Realitaet. Wenn z.B. jemand mit den OSM-Daten Verkehr unter realistischen Bedingungen modellieren will, will er vielleicht auch mit einbeziehen, dass Verbote auch misachtet werden, oder sogar exakt untersuchen, was passiert, wenn Verbote misachtet werden. Ein Datensatz der die physische Realitaet zugunsten der Abbildung von Regeln unterdrueckt, ist dafuer schlicht ungeeignet. Man ist gut beraten, wenn man sich beim Mapping nicht von einer einzigen Anwendung (== Verkehrsregeln fuer den motorisierten Verkehr) leiten laesst, sondern moeglichst anwendungsneutral mappt. Die Verkehrsregeln sehe ich als Ebene, die nicht ueber die Linkstruktur (OSM-speach: way) ausformuliert wird, sondern auf dieser aufbaut. Ich habe uebrigends im Modellierungsbereich mit Netzen zu tun gehabt, die jede Verbindung in der Kreuzung als eigenen Link ausformuliert haben. Das hat allerdings auch seine Tuecken und blaeht das Netz gewaltig auf. Fuers simple Routen ist sicher ein vermeidbarer Overhead. 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. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am 18. Oktober 2009 19:36 schrieb qbert biker qbe...@gmx.de: Zumal man ja schnell im Dilemma steht Mappe ich die Fahrspuren an großen Kreuzungen einzeln, damit wir irgendwann potentiell einen Fahrspurassistenten anbieten können. oder Ersaufe ich dann bei so vielen Spuren nicht irgendwann im Restriction-Relations-Gestrüpp. Und das absolut unnötig. Die normale Abbiegespur ist ein Bereich der Strasse und kann mit Attributen besser definiert werden als mit einzelnen ways. Zwischen Spuren einer Fahrbahn kann ich wechseln, was den fundamentalen Unterschied zu einem expliziten Link im Netz( == OSM way) ausmacht. diesen Unterschied koennte man angeben (zw. diesem und diesem Node kann ich zwischen diesem und diesem Way beliebig wechseln, da es sich um Spuren handelt), so dass das geloest waere. Ist m.E. intuitiver als komplexe Abbiegerestriktionen, und genauer, was die Lage (Beginn und Ende, Position) angeht. Ausserdem besser visuell kontrollierbar. Ein Renderer koennte ich auch ueberlegen, die Spuren im Rendering ggf. wieder zu einem Way zusammenzufassen. Fuer die Aussage 'von da nach dort ist die Fahrbahn um eine Spur erweitert und diese Spur hat eine Abbiegerestriktion' ist ein eigener link unnuetz oder sogar schaedlich, weil er die Natur der Spur, also die physikalische Wechselmoeglichkeit verbirgt. Ausser man fuehrt Linkpaare mit dynamischer Verbindung ein - *grusel* warum gruselt Dich da davor? Waere m.E. die fuer den Mapper einfachste und die geometrisch am naehsten an der Realitaet liegende Moeglichkeit. Wie soll ich eine Klasse im Reisezeitmodell attributieren, wenn nicht schluessig definiert ist, was diese Klasse aussagt? was meinst Du damit? Du koenntest auch mal konkrete Vorschlaege machen, als nur pauschal zu kritisieren. In anderen Systemen habe ich eine saubere Klassifizierung nach Strassenzustand und weitgehend unabhaengig davon eine weitere nach der Wichtigkeit, bzw. der Bedeutung im Grid. haben wir doch auch. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am 19. Oktober 2009 09:36 schrieb qbert biker qbe...@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 hat allerdings auch seine Tuecken und blaeht das Netz gewaltig auf. Fuers simple Routen ist sicher ein vermeidbarer Overhead. seit wann wollen wir nur simples Routen? Wer das will, kann die Spuren ja beim Konvertieren rauswerfen, in die Datenbank gehoeren sie m.E. 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. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Martin Simon schrieb: Am 19. Oktober 2009 02:16 schrieb Garry garr...@gmx.de: qbert biker schrieb: Sehe ich ein bichen anderst... zwischen den Abbiegespuren darf nicht mehr so frei gewechselt werden wie zwischen normalen Fahrpuren - bei durchgezogener Linie darf ich die Spur gar nicht wecheln ..was üblicherweise kurz vor Beginn der eigenständigen Fahrbahn der Abfahrt der Fall ist, weshalb man hier m.E. auch problemlos den Punkt des Abzweigs der OSM-Ways an diese Stelle verschieben kann. Es gibt aber Leute, die die komplette Spur seit ihrem beginn als eigenständige Straße regelrecht malen, weil's in Mapnik so cool aussieht... Bei autobahn(ähnlichen) Abfahrten ja, bei Ampelkreuzungen bin ich mir nicht sicher ob man da nicht vielleicht doch mit separat getaggten Abbiegespuren was vereinfachen kann. Wann ein Navi Ansagen zum Abbiegen macht, sollte auch nicht an unseren Daten liegen - mein Vista Hcx sagt auf Autobahnen z.B. gut 1,2km vorher an, wenn ich mich recht erinnere. Sehe ich auch so... und bei getrichelter Linie darf ich eine Abbigespur nicht zum überholen missbrauchen... Führ das Routing sehe ich separate OSM-Ways für Abbiegepuren daher ehr als hilfreich an... Was hat routing mit Überholen zu tun? überholen sie *jetzt*, der Typ fährt zu langsam!? ;-) Damit will ich sagen dass es nicht besonders stört wenn hier die Abbiegespur schon als separater Way getaggt ist die ich in der Realität physikalich vielleicht noch wechseln kann, laut Router aber nicht mehr. D.H man mus sich hier in der Software nicht unbedingt einen abbrechen um unbedingt darzutellen dass es diese physikaliche Möglichkeit noch gibt - Das kann man dann dem Strassenflächenmappen vorbehalten... ;-) Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Original-Nachricht Datum: Mon, 19 Oct 2009 11:51:28 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@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 qbe...@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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am 19. Oktober 2009 12:42 schrieb qbert biker qbe...@gmx.de: 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. einfacher fuer die Auswertung oder fuer den Mapper? Auswertung hinsichtlich Flaechen und Lagegenauigkeit oder nur Abbiegerestriktionen? Uebersichtlicher und fehlersuchenfreundlicher? M.E. sind das alles Punkte, die gegen Attribute sprechen. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am 19. Oktober 2009 12:46 schrieb Garry garr...@gmx.de: Martin Koppenhoefer schrieb: Am 19. Oktober 2009 09:36 schrieb qbert biker qbe...@gmx.de: Warst das nicht Du der sich für ein Mappen der Fahrbahnflächen ausgesprochen hat? mit niedriger Prioritaet, wird aber m.E. eines Tages kommen, spaetestens, wenn man alle Flaechen drumrum schon hat und nur die Strassen noch fehlen. In dem Fall kann man die Informationen (way) fürs routen icher einfacher halten. das halte ich allerdings nicht fuer so einfach: Routing ueber Flaechen, das meinst Du doch, oder? Fuers routing ist ein abstrahierter Graph sicherlich einfacher. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Original-Nachricht Datum: Mon, 19 Oct 2009 14:39:47 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: qbert biker qbe...@gmx.de CC: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise einfacher fuer die Auswertung oder fuer den Mapper? Auswertung hinsichtlich Flaechen und Lagegenauigkeit oder nur Abbiegerestriktionen? Uebersichtlicher und fehlersuchenfreundlicher? M.E. sind das alles Punkte, die gegen Attribute sprechen. Soll bis in alle Ewigkeiten jeder Mapper jede Bedeutung einer Node bis ins Detail verstehen muessen, damit er Trivialitaeten wie eine Abbiegespur eintragen kann? Das ist eine Frage der Werkzeuge, das fuer Otto Normalmapper anwenderfreundlich hinzubekommen. Ansonsten halte ich das Gewurrle von vielen ways fuer alles andere als uebersichtlich und anwenderfreundlich. Ich fasse sowas nicht mehr an, besonders wenn da dann noch ein paar relations als Garnierung drin haengen, um auszudruecken, dass die getrennten Spuren eigentlich zusammengehoeren. Aber das ist jetzt wirklich nur meine ganz persoenliche Meinung - meine Erfahrungen aus der Praxis sind im Thread, und wer sie wie nutzt, ist nicht mehr unter meinem Einfluss. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Martin Koppenhoefer schrieb: In dem Fall kann man die Informationen (way) fürs routen icher einfacher halten. das halte ich allerdings nicht fuer so einfach: Routing ueber Flaechen, das meinst Du doch, oder? Fuers routing ist ein abstrahierter Graph sicherlich einfacher. Nein, vereinfachte ways fürs Routen, detailierte Informationen durch Flächen die man ehr nicht für routen heranzieht, aber vielleicht für so was ind der letzten Zeit als reality-view vermarktet wird, kurz vor der Kreuzung gibt es davon eine Detailansicht auf der die zu wählende Spur markiert ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am 19. Oktober 2009 16:07 schrieb qbert biker qbe...@gmx.de: einfacher fuer die Auswertung oder fuer den Mapper? Auswertung hinsichtlich Flaechen und Lagegenauigkeit oder nur Abbiegerestriktionen? Uebersichtlicher und fehlersuchenfreundlicher? M.E. sind das alles Punkte, die gegen Attribute sprechen. Soll bis in alle Ewigkeiten jeder Mapper jede Bedeutung einer Node bis ins Detail verstehen muessen, damit er Trivialitaeten wie eine Abbiegespur eintragen kann? Das ist eine Frage der Werkzeuge, das fuer Otto Normalmapper anwenderfreundlich hinzubekommen. jaja, sehe ich auch so. Ansonsten halte ich das Gewurrle von vielen ways fuer alles andere als uebersichtlich und anwenderfreundlich. wieso? Wo eine Spur ist, ist auch ein Way, wo die Spur eine Kurve hat, hat auch der way eine, wo er sich gabelt ist auch im Modell eine Gabelung, etc., direkter geht es doch gar nicht. Ich fasse sowas nicht mehr an, besonders wenn da dann noch ein paar relations als Garnierung drin haengen, um auszudruecken, dass die getrennten Spuren eigentlich zusammengehoeren. das koennte man relativ einfach visualisieren, z.B. durch eine transparente Fläche zwischen den beiden (so wie bei area-Flächen auch) wo der Übergang möglich ist. (s.o.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Original-Nachricht Datum: Sat, 17 Oct 2009 02:06:22 +0200 Von: Johann H. Addicks addi...@gmx.net An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise die Abbiegerelationen werden nicht immer richtig interpretiert Wenn auch Potlach einen Abbiegerrestriction-Editor bekäme (und der in Josm die ganzen Relation-Sachen komplett vom potentiell verwirrten Gelgenheitseditor verbergen würde), dann kämen wir auch in der Richtung weiter. Mal schaun - da scheint sich was bei Cloudmade zusammenzubrauen. Ich habe keine Lust mich fuer ne Beta anzumelden, aber die Screenshots des neuen Editors sehen interessant aus. Zumal man ja schnell im Dilemma steht Mappe ich die Fahrspuren an großen Kreuzungen einzeln, damit wir irgendwann potentiell einen Fahrspurassistenten anbieten können. oder Ersaufe ich dann bei so vielen Spuren nicht irgendwann im Restriction-Relations-Gestrüpp. Und das absolut unnötig. Die normale Abbiegespur ist ein Bereich der Strasse und kann mit Attributen besser definiert werden als mit einzelnen ways. Zwischen Spuren einer Fahrbahn kann ich wechseln, was den fundamentalen Unterschied zu einem expliziten Link im Netz( == OSM way) ausmacht. Fuer die Aussage 'von da nach dort ist die Fahrbahn um eine Spur erweitert und diese Spur hat eine Abbiegerestriktion' ist ein eigener link unnuetz oder sogar schaedlich, weil er die Natur der Spur, also die physikalische Wechselmoeglichkeit verbirgt. Ausser man fuehrt Linkpaare mit dynamischer Verbindung ein - *grusel* Und bevor man sich dranmacht, einfache Zusammenhaenge ueber ein permanentes Verkomplizieren des Netzes abzubilden, sollte man erst mal an die grundlegenden Dinge rangehen: Wie soll ich eine Klasse im Reisezeitmodell attributieren, wenn nicht schluessig definiert ist, was diese Klasse aussagt? In anderen Systemen habe ich eine saubere Klassifizierung nach Strassenzustand und weitgehend unabhaengig davon eine weitere nach der Wichtigkeit, bzw. der Bedeutung im Grid. Schafft die Stolpersteine fuer die Entwickler aus dem Weg und gebt denen saubere Definitionen und dann hat auch die Evolution eine Chance, das Routing zu verbessern. Wenn muehsam erarbeitete Routingregeln durch nachtraegliches Umdefinieren der Tagbedeutungen zunichte gemacht werden, gibt es bei den Routern keine Evolution, sondern nur Stagnation. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im?Vergleich bei Heise
Longbow4u 2long...@gmx.de wrote: Leider wird der Vergleich der Navigationssoftware, so er denn kommt, wahrscheinlich nicht besonders erfreulich ausfallen (was nicht ausschließlich am zugrundeliegenden Kartenmaterial liegt). Einige der Routenvorschläge sind noch ziemlich buggy. So wird häufig auf Feld-oder Waldwegen zum Ziel geleitet, obwohl die befestigte Hauptstraße nur unwesentlich länger ist Sowas liegt aber ja wohl ausschließlich am Routingsalgorithmus. Feld- oder Waldwege sind nunmal nichts für Autofahrer. Spätestens wenn man die Geschwindigkeit hier auf max 5km/h setzt dürfte da nix mehe von übrig bleiben. der Garmin hat ja auch gerne mal solche Probleme. Ich nehme an, das liegt schlichtweg daran, dass solche Wege bei kommerziellem Kartenmaterial überhaupt nicht existieren. Gruss Sven -- Thinking of using NT for your critical apps? Isn't there enough suffering in the world? (Advertisement of Sun Microsystems in Wall Street Journal) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
qbert biker schrieb: uren nicht irgendwann im Restriction-Relations-Gestrüpp. Und das absolut unnötig. Die normale Abbiegespur ist ein Bereich der Strasse und kann mit Attributen besser definiert werden als mit einzelnen ways. Zwischen Spuren einer Fahrbahn kann ich wechseln, was den fundamentalen Unterschied zu einem expliziten Link im Netz( == OSM way) ausmacht. Fuer die Aussage 'von da nach dort ist die Fahrbahn um eine Spur erweitert und diese Spur hat eine Abbiegerestriktion' ist ein eigener link unnuetz oder sogar schaedlich, weil er die Natur der Spur, also die physikalische Wechselmoeglichkeit verbirgt. Ausser man fuehrt Linkpaare mit dynamischer Verbindung ein - *grusel* Sehe ich ein bichen anderst... zwischen den Abbiegespuren darf nicht mehr so frei gewechselt werden wie zwischen normalen Fahrpuren - bei durchgezogener Linie darf ich die Spur gar nicht wecheln und bei getrichelter Linie darf ich eine Abbigespur nicht zum überholen missbrauchen... Führ das Routing sehe ich separate OSM-Ways für Abbiegepuren daher ehr als hilfreich an... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Und die Idee, Routen live vom Server über Mobilfunk nachzuladen, ist auch mutig. Bei kleineren Abweichungen von der vorgeladenen Route steht man schnell ohne Routing da. Der Vorteil von OSM ist, wie wir alle wissen, das sie wesentlich aktueller sein kann als tomtomco. Es ist die Frage wie man dies dann auf seinem Navi nutzbar macht. - Aktuelle Kartendaten (komplett D etc.) nachladen und auf dem Navi speichern und immer onboard (auf dem Navi)berechnen. (Update von Kartendaten auf dem Navi= ? ) - offboard (auf dem server) berechnen und die entsprechenden Karten bevor oder während man schon losfährt entlang der Route nachladen so das sie auf dem Navi gespeichert werden Bei Andnav2 (für Android Handgurken) wird soweit ich das sehe immer auf dem server von openrouteservice.org gerechnet. Mann kann aber die kartendaten von komplett D vorher installieren oder dann entlang der route downloaden. Aber gerechnet wird wohl immer online auf dem openrouteservice.org server (???). (Ich konnte das noch nicht komplett testen, auch was passiert wenn man sich verfährt). Ideal wäre eigentlich: Gelegentliche die komplette Karte downloaden so das auf dem Navi gerechnet werden kann wenn keine Datenverbindung da ist oder gewollt ist (!). Also mal ein gewisser Grundbestand da ist. Ist eine Datenverbindung möglich wird (wenn gewünscht) die Route auf dem Server gerechnet und dann die neuen Kartendaten entlang der Route (korridor) übertragen so das die alten Kartendaten entlang der Route im Grundbestand ausgetauscht werden. Wie das dann am Übergang von alten und neuen Daten funktionieren soll ist mir dann aber ein Rätsel... Deswegen wird wohl nur beides parallel laufen können. (?). Also auf dem server rechnen und karten übertragen entlang der gewählten Route oder Karten gelegentlich komplett aktualisieren und auf dem Navi rechnen. Auf dem Navi rechnen dürfte immer schneller und für die meisten praktikabler sein. In dem Fall versucht das Programm nämlich, sich eine neue Route vom Server zu ziehen, was über Mobilfunk einige Zeit in Anspruch nehmen kann. Routenberechnung zu Beginn der tour online hätte Vorteile betreffs Aktualität der Karte. Korrektur während man unterwegs ist sollte imho aber _immer_ auf dem Navi und nicht online erfolgen wg. Zeitfaktor. Also Kartendaten werden entsprechend nur nach Bedarf geladen, gerechnet wird wenn möglich immer auf dem Navi. Als Fallback bzw. Alternative die komplette offlinevariante mit vorinstallierten karten und Rechnung auf dem Navi. Gerade die onlineberechnung und kartendaten laden ist das was bei andnav2 Zeit kostet ohne ende, auch wg. der fehlenden autovervollständigung bei straßennamen und deswegen nicht so praktikabel ist. Aber wenn man das so trickst das man möglichst direkt losfahren kann. also eine Kombination aus offboard und onboard wäre das genial da man schnelle Berechnung mit Aktualität der Kartendaten verbinden könnte. Nein ich kann das nicht umsetzen. Mein getippse ist also mehr was für meinen Weihnachtswunschzettel. ;) Muss nachher nochmal mit andnav2 rumspielen. Außerdem fehlen bekanntlich zum Teil noch viele Straßen, besonders in Dörfern. Wir arbeiten dran. ;) Eine große Hilfe ist mir : http://svenanders.openstreetmap.de/SV-stat/Rheinland-Pfalz/ Leider gibt es davon keine Gesamtstats für Rhld-Pflz., so das einem der Gesamtfortschritt nicht bekannt ist. Würde evtl die Motivation deutlich heben. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Am Samstag 17 Oktober 2009 glaubte Longbow4u zu wissen: Außerdem fehlen bekanntlich zum Teil noch viele Straßen, besonders in Dörfern. Es fehlen auch noch komplette Dörfer, vor allem in ländlichen Bereichen. flo -- Mit freundlichen Grüßen Günter Frhr. v. Gravenreuth willkommen! Beim Sitzpinkeln bitte um ca. 90° nach vorne beugen. Pass' auf, er mahnt dich bestimmt wegen Missbrauchs der Marke 90° ab! kein Problem, dann kommt er einfach in die Kochwäsche. [Hajo Pflueger und Christopher Splinter in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Moin Johann, die Abbiegerelationen werden nicht immer richtig interpretiert Wenn auch Potlach einen Abbiegerrestriction-Editor bekäme Es geht ja irgendwie. Aber ich glaube, bei meiner ersten etwas komplexeren Kreuzung habe ich ne Stunde drangesessen, bis ich es verstanden habe und mir sicher war, daß das nu auch alles korrekt und vollständig eingetragen war. Für den Unnaer Verkehrsring werde ich wohl einen Urlaubstag einplanen müssen, das ist alles viel zu umständlich. Man will ja auch nicht versehentlich andere, schon vorhandene (Radweg-)Relationen zerdengeln. Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
Peter Körner osm-lists at mazdermind.de writes: werden Produkte auf OSM-Basis bereits als vergleichbare alternativen erkannt: Leider wird der Vergleich der Navigationssoftware, so er denn kommt, wahrscheinlich nicht besonders erfreulich ausfallen (was nicht ausschließlich am zugrundeliegenden Kartenmaterial liegt). Einige der Routenvorschläge sind noch ziemlich buggy. So wird häufig auf Feld-oder Waldwegen zum Ziel geleitet, obwohl die befestigte Hauptstraße nur unwesentlich länger ist, die Abbiegerelationen werden nicht immer richtig interpretiert etc. Und ich warte noch auf ausgesprochene Hinweise wie In zweihundert Meter rechts abbiegen auf x-Straße. Und die Idee, Routen live vom Server über Mobilfunk nachzuladen, ist auch mutig. Bei kleineren Abweichungen von der vorgeladenen Route steht man schnell ohne Routing da. In dem Fall versucht das Programm nämlich, sich eine neue Route vom Server zu ziehen, was über Mobilfunk einige Zeit in Anspruch nehmen kann. Außerdem fehlen bekanntlich zum Teil noch viele Straßen, besonders in Dörfern. Man sollte deshalb das absehbar kritische Urteil als wichtigen Markstein betrachten, der irgendwann zu einem verbesserten Routing auf OSM-Basis führt. Ich habe Roadee und bin nicht enttäuscht, da ich von Anfang an wußte, dass es erst am Anfang steht. Man sollte allerdings keine Wunder erwarten. Longbow4u ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigations-Software Roadee mit OSM-Datenbasis im Vergleich bei Heise
die Abbiegerelationen werden nicht immer richtig interpretiert Wenn auch Potlach einen Abbiegerrestriction-Editor bekäme (und der in Josm die ganzen Relation-Sachen komplett vom potentiell verwirrten Gelgenheitseditor verbergen würde), dann kämen wir auch in der Richtung weiter. Zumal man ja schnell im Dilemma steht Mappe ich die Fahrspuren an großen Kreuzungen einzeln, damit wir irgendwann potentiell einen Fahrspurassistenten anbieten können. oder Ersaufe ich dann bei so vielen Spuren nicht irgendwann im Restriction-Relations-Gestrüpp. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
