Navigator 10 free von Mapfactor ... nutzt OSM-Daten

hurdygurdyman · 2013-08-19 13:50:27

tob39 wrote:

...
Ich hoffe ihr könnt mir helfen, die Fahrzeiten zukünftig realistisch angezeigt zu bekommen.

Nach meinen Erfahrungen kalkuliert der navigator free immer nach der iom Fahrzeugprofil eingestellten Höchstgeschwindigkeit der Straßenkategorie, die im Fahrzeugprofil hinterlegt sind, ohne z.B. Ampeln oder so zur Erhöhung der Reisezeit zu berücksichtigen. Ich habe bei mir z.B. innerorts auf 35 km/h in einem eigenen Profil für "meine Rostlaube" geändert und komme damit gut hin. Du weißt am besten, wie du fährst und kannst so deine individuelle Geschwindigkeit festlegen.
Wenn du mal die Applikationssprache auf "Englisch" umstellst, wirst du bei den Fahrzeugeinstellungen plötzlich statt zweimal "Hauptstraße" dann "Primary-" und Major road" sehen.

tob39 · 2013-08-19 14:55:37

Ich habe die Diskussion hier weitergeführt:

http://forum.mapfactor.com/discussion/2 … eed-limits

Ich bin nun für meine 10km-Strecke im navigator bei 14Minuten (realistisch 17-18; Google Maps: 19-20)

Thomas8122 · 2013-09-22 11:03:15

Der Spurassistent funktioniert ja an einfachen Kreuzungen schon ganz gut. Allerdings hier will MF mich erstmal in die Geradeausspur schicken, obwohl ich die erste kreuzende Straße ja offensichtlich nicht benutzen kann da Einbahnstraße. Ist das schon anderen aufgefallen oder ist dort bloß was falsch gemappt?

Screenshot:

Gruß Thomas

chris66 · 2013-09-22 18:51:15

Ich vermute mal, dass Navigator diesen Fall (erste Kreuzung muss ignoriert werden, da man nicht nach links darf) nicht beachtet.

Emploi · 2013-09-22 21:41:51

Der Naviagtor (Android) wollte mich neulich an der zweiten Kreuzung nach der Carolabrücke (Südseite) auf die Gegenfahrbahn (Richtung Norden) navigieren. In Dipps steigt er fast aus, da liegen Straßen übereinander... Ansonsten eigentlich ganz zu frieden. Vielleicht läuft da was bei Konvertierung schief?

EvanE · 2013-09-22 22:21:51

chris66 wrote:

Ich vermute mal, dass Navigator diesen Fall (erste Kreuzung muss ignoriert werden, da man nicht nach links darf) nicht beachtet.

Im Prinzip ist dieser Fall (Geradeaus, dann zwingend Links) bei den Turn-Lanes nicht existent. Müsste man im konkreten Fall prüfen, wie es dort eingetragen ist und vor allem, wie die Straßen aufgeteilt sind.

Man müsste wohl den Flügelweg zwischen den beiden Richtungsfahrbahnen der Hamburger Straße aufteilen. Den südlichen Teil mit turn:lanes=through|through|through und das Stück zwischen den Richtungsfahrbahnen mit turn:lanes=left|left|through taggen. Dann sollte auch ein Routing-Programm eine Chance haben die richtige Spur anzuzeigen.

Gerade mal nachgesehen: Der Flügelweg südlich der Hamburger Straße ist mit turn:lanes= left|left|through;right
getaggt, obwohl man dort nicht gegen die Einbahnstraße abbiegen darf.
Das Stück zwischen den Richtungsfahrbahnen ist korrekt mit turn:lanes=left|left|through erfasst.

In diesem Fall zeigt Navigator genau das an, was ihm die OSM-Daten vorgeben. Er kann erst auf dem kurzen Stück zwischen den Fahrbahnen die Abbiegespur verwenden. Ob die eingetragenen Spuren sinnvoll sind oder nicht, kann das Programm nicht mehr entscheiden. Es wird schlicht das ausgewertet, was an den einzelnen Wegstücken steht. Leider müssen wir wegen unserer Wegstückelung (hier z.B. wegen dem Rechtsabbieger) manchmal etwas anderes eintragen, als das, was auf der Straße markiert ist.

Edbert (EvanE)

rayquaza · 2013-09-22 23:35:30

Aber dann stimmen doch die angezeigten Abbiegepfeile für die Fahrspuren nicht mehr? Gibt es da echt keine schönere Lösung?

EvanE · 2013-09-23 00:13:41

rayquaza wrote:

Aber dann stimmen doch die angezeigten Abbiegepfeile für die Fahrspuren nicht mehr? Gibt es da echt keine schönere Lösung?

Damit hast du wohl Recht.
Menschen sind wohl doch noch intelligenter als Programme.

Der Fall des 'verzögerten' Abbiegens bei getrennten Fahrwegen der Querstraße wird in keiner der "turn" Seiten behandelt und ist wohl bisher nicht bedacht worden. Von daher gibt dafür auch keinen Lösungsansatz.

Ich habe selber keine Idee, wie man die Angabe von turn:lanes und die Markierungen bzw. die Schilder auf/neben der Straße miteinander in Einklang bringen kann. Bei Menschen als Fahrzeugführer wird einfach davon ausgegangen, dass sie die Situation per se richtig interpretieren.

Edbert (EvanE)

Thomas8122 · 2013-09-23 15:32:16

Emploi wrote:

In Dipps steigt er fast aus, da liegen Straßen übereinander...

Du meinst bestimmt hier oder dort. Das ist mir auch schon so gegangen bei schlechtem Gps-Empfang oder wenn auf Straßen wie in Dippoldiswalde jede einzelne Spur als way gemappt sind.

Ich habe selber keine Idee, wie man die Angabe von turn:lanes und die Markierungen bzw. die Schilder auf/neben der Straße miteinander in Einklang bringen kann. Bei Menschen als Fahrzeugführer wird einfach davon ausgegangen, dass sie die Situation per se richtig interpretieren.

Also nur das letzte Spurtagging drin lassen, damit es keine Missverständnisse gibt?

Gruß Thomas

geri-oc · 2013-09-23 16:31:02

Thomas8122 wrote:

Emploi wrote:
In Dipps steigt er fast aus, da liegen Straßen übereinander...
Du meinst bestimmt hier oder dort. Das ist mir auch schon so gegangen bei schlechtem Gps-Empfang oder wenn auf Straßen wie in Dippoldiswalde jede einzelne Spur als way gemappt sind.

Liegt das nun an den ways? Bestimmt nicht, da graphhopper und auch MapQuest richtig routen.

Das ist das was ich testen kann und als Mensch aus der Karte lesen kann.

Und hier wurde mit lanes korrigiert - ist aber als Auto verboten. Oder von B nach Oberbärenburg oder von A nach Altenberg - verboten. Mit den getrennten ways hat es funktioniert - da hat man auch gesehen, dass es getrennte Fahrbahnen sind.

Thomas8122 · 2013-09-23 17:04:27

geri-oc wrote:

Liegt das nun an den ways?

Nein, es liegt am Empfang des Smartphones, weil es nicht 100-prozentig weiß auf welcher Spur er sich befindet und dann erstmal eine Ansage kommt: "Route wird neu berechnet" und er dich von hinten durch die Brust ins Auge schicken will.

Gruß Thomas

EvanE · 2013-09-23 17:15:01

geri-oc wrote:

Und hier wurde mit lanes korrigiert - ist aber als Auto verboten. Oder von B nach Oberbärenburg oder von A nach Altenberg - verboten. Mit den getrennten ways hat es funktioniert - da hat man auch gesehen, dass es getrennte Fahrbahnen sind.

Und der Parkplatz nord-östlich der B 170 ist immer noch nicht an das Straßennetz angeschlossen.
Ein Link auf Bing oder auf die OSM-Karte wäre nützlich, um sich diese Situation aus der Ferne ansehen und damit einschätzen zu können.

Gegen falsches Überqueren (der B 170) helfen nur Abbiege-Restriktionen. Also von A zur B 170 restriction=only_right in der Abbiege-Relation. Welche Router Abbiege-Relation beachten und ihren Routing-Graph zügig aktualisieren ist natürlich eine andere Frage.

Edbert (EvanE)

rab · 2013-09-23 17:30:12

Es ist jetzt einfach mal geändert.
Wenn du in Josm den Map paint style "lane and road atributes" aktivierst, wird die Straße auch entsprechend dargestellt.
rab

Emploi · 2013-09-23 17:55:12

Thomas8122 wrote:

geri-oc wrote:
Liegt das nun an den ways?
Nein, es liegt am Empfang des Smartphones, weil es nicht 100-prozentig weiß auf welcher Spur er sich befindet und dann erstmal eine Ansage kommt: "Route wird neu berechnet" und er dich von hinten durch die Brust ins Auge schicken will.
Gruß Thomas

Jepp, es kommen dann völlig wirre Ansagen raus, wie "weiter gerade aus fahren", oder "leicht rechts halten und dann weiter gerade aus"... (weiß gerade nicht ob das wirklich der Navigator war). Aber Ortseingang von Dipps von DD aus ist das schon die Kreuzung die du gefunden hast. Aber das zieht sich durchs die ganze Stadt. Eine normale Straße die als zwei gegenläufige Einbahnstraßen, noch dazu mit separaten Fußwegen die eigentlich an der Straße sind gemappt wurde, ist schon sehr falsch. Ich habe mich an das Chaos noch nicht gewagt.

Das GPS (mit Glonass) im Note 2 ist schon recht empfindlich, so das u.U. beim Überholen oder auf gerader Strecke die Route spontan neu berechnet wird.

lg

Last edited by Emploi (2013-09-23 17:58:51)

hurdygurdyman · 2013-09-24 08:09:32

Thomas8122 wrote:

Der Spurassistent funktioniert ja an einfachen Kreuzungen schon ganz gut. Allerdings hier will MF mich erstmal in die Geradeausspur schicken, obwohl ich die erste kreuzende Straße ja offensichtlich nicht benutzen kann da Einbahnstraße. Ist das schon anderen aufgefallen oder ist dort bloß was falsch gemappt?
Screenshot:
http://img33.imageshack.us/img33/2729/cenp.jpg
Gruß Thomas

Für mich sieht das so aus, als ob Navigator free die fehlende Möglichkeit des Abbiegens in den südl. Teil der Hamburger Straße nicht erkennt oder ignoriert. Da müsste der Algorismus dahingehend geändert werden, dass turn:lanes immer im Bezug auf die nächste Abbiegemöglichkeit in die entsprechende Richtung angezeigt werden.

Eine Änderung unserer Daten, indem wir die turn:lanes südlich der "unteren" Hamburger Straße weglassen, wäre gegen die Realität, die wir ja nun mappen, und ist somit abzulehnen.

Ich habe Mapfactor mal ein Mail deswegen geschickt und gefragt, ob die Programmlogik entsprechend geändert werden kann.

EvanE · 2013-09-24 14:35:18

hurdygurdyman wrote:

Thomas8122 wrote:
Der Spurassistent funktioniert ja an einfachen Kreuzungen schon ganz gut. Allerdings hier will MF mich erstmal in die Geradeausspur schicken, obwohl ich die erste kreuzende Straße ja offensichtlich nicht benutzen kann da Einbahnstraße. Ist das schon anderen aufgefallen oder ist dort bloß was falsch gemappt?
Screenshot:
http://img33.imageshack.us/img33/2729/cenp.jpg
Für mich sieht das so aus, als ob Navigator free die fehlende Möglichkeit des Abbiegens in den südl. Teil der Hamburger Straße nicht erkennt oder ignoriert. Da müsste der Algorismus dahingehend geändert werden, dass turn:lanes immer im Bezug auf die nächste Abbiegemöglichkeit in die entsprechende Richtung angezeigt werden.
Eine Änderung unserer Daten, indem wir die turn:lanes südlich der "unteren" Hamburger Straße weglassen, wäre gegen die Realität, die wir ja nun mappen, und ist somit abzulehnen.
Ich habe Mapfactor mal ein Mail deswegen geschickt und gefragt, ob die Programmlogik entsprechend geändert werden kann.

Für uns Menschen ist bei obiger Kreuzung alles klar, da wir sie als eine Einheit wahrnehmen. Allerdings wird dieser Zusammenhang durch unsere Mapping-Praxis aufgelöst, sobald wir getrennte Richtungsfahrbahnen verwenden. Von daher ist es für Routing-Programme schwierig, solche Situationen im Sinne der menschlichen Wahrnehmung zu interpretieren.

Es wäre natürlich wünschenswert, wenn Routing-Programme diese Situation wie ein Mensch interpretieren könnte. Allerdings stellt sich die Frage, wie ein Routing-Programm die Situation Großkreuzung bei getrennten Richtungsfahrbahnen erkennen kann, da wir in der OSM Daten-Realität diesen Zusammenhang durch getrennte OSM-Wege ja gerade aufgelöst haben.

Es stellt sich nun die Frage, ob wir für die Realität dort draußen unsere Daten erfassen, oder ob wir unser Lanes-Tagging an der Realität, wie sie durch die OSM-Daten gegeben ist, ausrichten. Solange wir große Kreuzungen nicht auf eine allseits akzeptierten Weise als eine Einheit abbilden können, würde ich zweiteres vorschlagen.

Edbert (EvanE)

Thomas8122 · 2013-09-24 15:52:57

hurdygurdyman wrote:

Ich habe Mapfactor mal ein Mail deswegen geschickt und gefragt, ob die Programmlogik entsprechend geändert werden kann.

Vielen Dank dafür.

hurdygurdyman wrote:

Eine Änderung unserer Daten, indem wir die turn:lanes südlich der "unteren" Hamburger Straße weglassen, wäre gegen die Realität, die wir ja nun mappen, und ist somit abzulehnen.

Dann bleibt es erstmal wie es ist, ist ja bestimmt nicht die einzige Kreuzung. Hoffen wir mal das Mapfactor das hinkriegt. Ist das bei OSMAnd eigentlich besser gelöst?

EvanE wrote:

...oder ob wir unser Lanes-Tagging an der Realität, wie sie durch die OSM-Daten gegeben ist, ausrichten.

Wie meinste das jetzt?

Gruß Thomas

hurdygurdyman · 2013-09-24 16:20:55

Für uns Menschen ist bei obiger Kreuzung alles klar, da wir sie als eine Einheit wahrnehmen. Allerdings wird dieser Zusammenhang durch unsere Mapping-Praxis aufgelöst, sobald wir getrennte Richtungsfahrbahnen verwenden. Von daher ist es für Routing-Programme schwierig, solche Situationen im Sinne der menschlichen Wahrnehmung zu interpretieren.
Es wäre natürlich wünschenswert, wenn Routing-Programme diese Situation wie ein Mensch interpretieren könnte. Allerdings stellt sich die Frage, wie ein Routing-Programm die Situation Großkreuzung bei getrennten Richtungsfahrbahnen erkennen kann, da wir in der OSM Daten-Realität diesen Zusammenhang durch getrennte OSM-Wege ja gerade aufgelöst haben.
Es stellt sich nun die Frage, ob wir für die Realität dort draußen unsere Daten erfassen, oder ob wir unser Lanes-Tagging an der Realität, wie sie durch die OSM-Daten gegeben ist, ausrichten. Solange wir große Kreuzungen nicht auf eine allseits akzeptierten Weise als eine Einheit abbilden können, würde ich zweiteres vorschlagen.
Edbert (EvanE)

Auch wenn ich eim Fan dieser Routing-Software bin: Ich lehne es ab, Ausnahmen vom Erfassen der Realität auch in diesem Fall zuzulassen. Durchgängige Eigenschaften von getrennten Wegstücken muss eine Auswertung wieder zusammensetzen können. Außerdem wäre bei deinem Vorschlag das verbleibende turn:lanes viel zu kurz, um noch mit Spurwechsel reagieren zu können.
Warten wir doch ab, ob Mapfactor das lösen kann.
Unabhängig davon kann man ja schon mal nachdenken, ob ein Zusatz-Tag oder eine Relation in diesen Fällen helfen könnte.

Last edited by hurdygurdyman (2013-09-24 16:22:22)

EvanE · 2013-09-24 16:22:47

Thomas8122 wrote:

EvanE wrote:
...oder ob wir unser Lanes-Tagging an der Realität, wie sie durch die OSM-Daten gegeben ist, ausrichten.
Wie meinste das jetzt?

Hallo Thomas

Das Problem ist darin begründet, dass ein Mensch eine Kreuzung als eine Einheit wahrnimmt. Die Daten bei OSM enthalten bei getrennten Richtungsfahrbahnen diese Einheit als ein Objekt Kreuzung nicht mehr. Daraus resultieren die Probleme.

Es gibt nun drei Mögliche Ansätze für eine Lösung:
- Ein allseits akzeptiertes Konzept für einen Kreuzungsbereich in OSM einführen.
Ansätze dazu gibt es, allerdings hat sich (geringe Akzeptanz!) noch nichts durchgesetzt.
Durch turn:lanes=* gibt es jetzt ein Problem, das von einer Lösung real profitieren würde.
- Routing-Programme müssen aus den vorhandenen OSM-Daten Kreuzungsbereiche
selber finden. Das dürfte sehr schwierig sein und ob Programm-Autoren sich auf dieses
unklare Gebiet begeben, ist durchaus fraglich. (Mit Punkt 1 sähe das evtl. anders aus)
- Wir passen unser Lanes-Tagging an die in OSM existierende Datenstruktur an.
Sprich, wir erledigen die Arbeit bei Kreuzungen mit getrennten Richtungsfahrbahnen
das Lane-Tagging so zu gestalten, dass ein Router bessere Spur-Hinweise erzeugen kann.

Punkt drei meinte ich mit der zitierten Aussage.
Klar wäre Punkt 2 in Verbindung mit Punkt 1 die bessere Lösung, aber das wird noch lange dauern.
Von daher ist Punkt drei in der reinen Lehre unschön, aber lässt sich heute ohne weitere Voraussetzungen realisieren.

Edbert (EvanE)

TOGA · 2013-09-24 16:34:32

EvanE wrote:

...
- Wir passen unser Lanes-Tagging an die in OSM existierende Datenstruktur an.
Sprich, wir erledigen die Arbeit bei Kreuzungen mit getrennten Richtungsfahrbahnen
das Lane-Tagging so zu gestalten, dass ein Router bessere Spur-Hinweise erzeugen kann.
...

Muss ein Router nicht aber so oder so den Zusammenhang zwischen Zufahrt und dem Teilstück innerhalb der Kreuzung herstellen? Angenommen man würde das so wie von Dir vorgeschlagen taggen und möchte dann z.B. nicht links abbiegen, sondern geradeaus fahren. Der Router würde mich dann doch möglicherweise erst auf die rechte Spur lotsen, wenn es schon viel zu spät ist, nämlich im Kreuzungsbereich selbst, oder?

EvanE · 2013-09-24 16:42:09

hurdygurdyman wrote:

Auch wenn ich eim Fan dieser Routing-Software bin: Ich lehne es ab, Ausnahmen vom Erfassen der Realität auch in diesem Fall zuzulassen. Durchgängige Eigenschaften von getrennten Wegstücken muss eine Auswertung wieder zusammensetzen können. Außerdem wäre bei deinem Vorschlag das verbleibende turn:lanes viel zu kurz, um noch mit Spurwechsel reagieren zu können.
Warten wir doch ab, ob Mapfactor das lösen kann.
Unabhängig davon kann man ja schon mal nachdenken, ob ein Zusatz-Tag oder eine Relation in diesen Fällen helfen könnte.

Was ist denn genau die Realität für Linksabbiegen im Falle von getrennten Richtungsfahrbahnen?
- Die Markierung auf der Straße / das Schild neben der Straße?
- Die Tatsache, dass man am ersten Kreuzungspunkt nicht gegen die
Einbahnstraße links abbiegen darf, also gerade aus fahren muss?

Wie gesagt, die Verkehrsteilnehmer betrachten eine Kreuzung als eine Einheit, In den OSM-Daten existiert bei getrennten Fahrbahnen dieses Einheit schlicht nicht mehr.

Da wir die Gesamtheit einer Kreuzung nicht als eine Einheit in unseren Daten haben, sollten wir nach meiner Meinung das Lanes-Tagging der Abbildung in den OSM-Daten anpassen.

PS:
Eine Möglichkeit zur Lösung des Problems, die ich noch nicht erwähnt hatte, wäre es, bei den turn:lanes Werte für 'verzögertes' Abbiegen einzuführen. Die Angabe bezieht sich nicht auf den nächsten Kreuzungspunkt sondern erst auf den übernächsten. Keine Ahnung wie man das nennen soll. Etwas wie left_postponed käme mir in den Sinn, aber bei den Werte-Namen bin ich flexibel.

Edbert (EvanE)

EvanE · 2013-09-24 16:54:57

TOGA wrote:

EvanE wrote:
- Wir passen unser Lanes-Tagging an die in OSM existierende Datenstruktur an.
Sprich, wir erledigen die Arbeit bei Kreuzungen mit getrennten Richtungsfahrbahnen
das Lane-Tagging so zu gestalten, dass ein Router bessere Spur-Hinweise erzeugen kann.
Muss ein Router nicht aber so oder so den Zusammenhang zwischen Zufahrt und dem Teilstück innerhalb der Kreuzung herstellen? Angenommen man würde das so wie von Dir vorgeschlagen taggen und möchte dann z.B. nicht links abbiegen, sondern geradeaus fahren. Der Router würde mich dann doch möglicherweise erst auf die rechte Spur lotsen, wenn es schon viel zu spät ist, nämlich im Kreuzungsbereich selbst, oder?

Richtig und falsch zugleich.
Das augenblickliche Problem beruht gerade darauf, dass aus Sicht des Routers die beiden linken Spuren erst im Kreuzungsbereich laut den OSM-Daten für die geplanten Route geeignet sind. Sagt man vor der Kreuzung "Alle Spuren geradeaus", dann kann man schon vorab die zwei 'günstigen' Spuren auswählen. Umgekehrt gilt das für den Fall der Geradeausfahrt genauso.

Inwieweit Router Spurvorschläge über mehrere Kreuzungspunkte optimieren (oder vielleicht auch nicht), dazu habe ich keine Erkenntnisse. Insoweit wäre ein Wert für "später links abbiegen" wahrscheinlich eine gute Lösung.

Edbert (EvanE)

amm · 2013-09-24 17:18:06

Da man wohl davon ausgehen kann das die Strassenbauer keine Idioten sind, wuerde ich mal annehmen das es (nahezu) keine Faelle gibt wo Linksabbiegerspuren existieren die einem direkt entgegen einer Einbahnstrasse (oder sonstwie unerlaubte) Einfahrt leiten. Man duerfte also nahzu 100% richtig liegen wenn man die Links(und Rechts)abbiegerspuren dahin interpretiert das sie fuer die naechste erlaubte Abbiegung gilt. (Wenn dann ist es wohl eher das sie fuer die uebernaechste erlaubte Abbiegung gelten als fuer eine nicht erlaubte)

Insofern muss man zwar im Konvertierungsprogram diese Faelle wohl separat behandeln (mit mir unbekannten Aufwand fuer den Programmierer), es sollte aber kein Fall sein das es uneindeutig waere und man "menschliche Intelligenz" dafuer benoetigen wuerde. Man braucht auch keine Grosskreuzungen erkennen. Diese Inteligenz und Uebersicht duerfte der Strassenbauer fuer einem gehabt haben.

chris66 · 2013-09-24 18:01:55

EvanE wrote:

- Wir passen unser Lanes-Tagging an die in OSM existierende Datenstruktur an.

Also wenn man jetzt (nur weil ein Navi noch nicht schlau genug ist) das Tagging ändert, dann kann man den OSM
Spurassistenten wohl vergessen.

EvanE · 2013-09-24 21:32:46

amm wrote:

Da man wohl davon ausgehen kann das die Strassenbauer keine Idioten sind, wuerde ich mal annehmen das es (nahezu) keine Faelle gibt wo Linksabbiegerspuren existieren die einem direkt entgegen einer Einbahnstrasse (oder sonstwie unerlaubte) Einfahrt leiten. Man duerfte also nahzu 100% richtig liegen wenn man die Links(und Rechts)abbiegerspuren dahin interpretiert das sie fuer die naechste erlaubte Abbiegung gilt. (Wenn dann ist es wohl eher das sie fuer die uebernaechste erlaubte Abbiegung gelten als fuer eine nicht erlaubte)
Insofern muss man zwar im Konvertierungsprogram diese Faelle wohl separat behandeln (mit mir unbekannten Aufwand fuer den Programmierer), es sollte aber kein Fall sein das es uneindeutig waere und man "menschliche Intelligenz" dafuer benoetigen wuerde. Man braucht auch keine Grosskreuzungen erkennen. Diese Inteligenz und Uebersicht duerfte der Strassenbauer fuer einem gehabt haben.

Du hast ja aus deiner menschlichen Sicht völlig Recht.
Aber, das in Algorithmen für Programme zu gießen, ist ein ganz andere - wahrscheinlich nicht triviale - Frage.

Es ist immer leicht (sinnvolle) Forderungen zu stellen, die andere letztlich realisieren müss(t)en. Von daher sollte man sich schon fragen, ob es nicht andere Lösungen gibt, die man selber realisieren kann. Ich habe ja mehrere Ansätze dafür beschrieben.

Edbert (EvanE)

Announcement

#201 2013-08-19 13:50:27

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#202 2013-08-19 14:55:37

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#203 2013-09-22 11:03:15

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#204 2013-09-22 18:51:15

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#205 2013-09-22 21:41:51

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#206 2013-09-22 22:21:51

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#207 2013-09-22 23:35:30

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#208 2013-09-23 00:13:41

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#209 2013-09-23 15:32:16

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#210 2013-09-23 16:31:02

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#211 2013-09-23 17:04:27

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#212 2013-09-23 17:15:01

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#213 2013-09-23 17:30:12

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#214 2013-09-23 17:55:12

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#215 2013-09-24 08:09:32

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#216 2013-09-24 14:35:18

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#217 2013-09-24 15:52:57

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#218 2013-09-24 16:20:55

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#219 2013-09-24 16:22:47

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#220 2013-09-24 16:34:32

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#221 2013-09-24 16:42:09

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#222 2013-09-24 16:54:57

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#223 2013-09-24 17:18:06

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#224 2013-09-24 18:01:55

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

#225 2013-09-24 21:32:46

Re: Navigator 10 free von Mapfactor ... nutzt OSM-Daten

Board footer