From: news51@mystrobl.de   
      
   Am Fri, 31 Oct 2025 10:38:25 +0100 schrieb Olaf Skibbe   
   :   
      
   >   
   >On 2025-10-31 10:28, Olaf Skibbe wrote:   
   >> On 2025-10-31 08:08, Wolfgang Strobl wrote:   
   >>> Am Thu, 30 Oct 2025 21:03:23 +0100 schrieb Wolfgang Strobl   
   >>> :   
   >>>   
   >>>> Saint-Saturnin-lès-Apt   
   >   
   >> (oder gleich mit dem Fahrrad hinzufahren)   
   >   
   >BTW: Die Strecke dahin scheint mir Bikerouter nicht berechnen zu können   
   >(zeigt nach einigen Minuten einfach die Luftlinie). Ich würde meinen,   
   >vor einiger Zeit gingen soche Strecken noch.   
      
   Ich hab's mal mit brouter probiert und von Trier zu der Schleife   
   oben bei Saint-Saturnin-lès-Apt geroutet   
      
   ergab 36 Sekunden.   
      
   Nächster Versuch, mit bikerouter.de   
      
      
      
      
   Das hat auch 36 s gebraucht und eine leicht andere Route   
   produziert, 40 km weniger, weniger Höhenmeter, weniger Kosten.   
      
      
   >   
   >https://bikerouter.de/#map=7/46.479/7.866/standard&lonlats=8.68   
   186%2C49.405625%7C5.380554%2C43.941834   
   >   
      
   Dein Link mit bikerouter hat auf meinem Laptop zwei Kerne   
   ziemlich vollständig ausgelastet und nach knapp drei Minuten   
   einen schwarzen Strich (Luftlinie) produziert, ohne Statistiken   
   zu zeigen. Also Abbruch vmtl.   
      
   Nachdem ich das auf das Profil "Rennrad" statt "Rennrad, sehr   
   wenig Verkehr" umgestellt hatte, erhielt ich blitzartig ein   
   Ergebnis, vmtl. weil ich das schon zum zweiten Mal aufgerufen   
   hatte - irgendwer hat das Ergebnis offenbar im Cache. Ich hab'   
   dann einen leicht verschobenen Zwischenpunkt durch Ziehen   
   eingefügt, was den Cache invalidierte. Nach einiger Zeit wurde   
   eine bis zum Zwischenpunkt (nähe Lyon) berechnete Route   
   dargestellt, kurze Zeit später (nach 1:31) dann die komplette   
   Route.   
      
      
      
   Ich vermute, dass mit "Rennrad, weniger Verkehr", d.h. indem man   
   das Routing auf untergeordnete Straßen zwingt, sehr viel mehr   
   Routingarbeit nötig wird, die mehr Zeit und mehr RAM benötigt.   
   Die CPU-Belastung war anders (mehr Kerne, aber die weniger   
   ausgelastet), das ist aber auch davon abhängig, ob Firefox im   
   Vordergrund läuft, jedoch habe ich das nur nebenher verfolgt. Ich   
   könnte daraus Schlüsse ziehen, was das Programm macht -   
   API-Aufrufe statt selber kalkulieren, das wäre aber reine   
   Spekulation, da ich von der Architektur dieser Anwendung nahezu   
   nichts weiß, also darüber wie sich das Verfahren auf Frontend und   
   Backend verteilt und welche Rolle der Auftrag dabei spielt.  Nur   
   so viel noch: wenn Firefox im Hintergrund läuft, bricht die Route   
   ohne Zwischenpunkt mit schwarzer Luftlinie ab, wenn ich das   
   Fenster/den Tab im Vordergrund in Ruhe laufen lasse (also nicht   
   z.B. den Process Explorer), dann erhalte ich reproduzierbar nach   
   rund 1:30 ein Ergebnis, ohne Zwischenpunkt.   
      
      
   >Kürzere Strecken funktionieren, scheinen aber auch deutlich länger zu   
   >dauern. Ist Euch hier ein Problem bekannt?   
      
   War mir bislang nicht bekannt, jedoch habe ich selten so große   
   Distanzen rechnen lassen und schon gar nicht mit "... (wenig   
   Verkehr)".  Der Laptop hier hat reichlich RAM und Kerne, das   
   reicht aber offenbar nicht für Routing mit der Nebenbedingung   
   "verkehrsarme Straßen", oder es ist ein serverseitiges Limit.   
   Vielleicht weiß jemand mehr, der sich mit der Architektur von   
   brouter und brouter-web auskennt.  Diesbezügliche Einarbeit steht   
   zwar auf auf irgend einer Todo-Liste, aber ziemlich weit unten.   
   :-)   
      
      
   --   
   Wir danken für die Beachtung aller Sicherheitsbestimmungen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)