MTB-News.de

bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
hholgi schrieb:
Was sind eigentlich "LiDar" Höhendaten?
Sind das die üblichen im Brouter?
Zum Vergrößern anklicken....

Nein, die sind nicht die üblichen im BRouter - zumindest noch nicht.
LIDAR (Light Detection and Ranging) sind Daten die in der Regel wesentlich höher aufgelöste Höhendaten bieten können als z.B. klassischerweise die SRTM Daten (Shuttle Radar Topography Mission) die um die 2000er von der NASA erhoben wurden und die es seit 2015 im Netz kostenlos in 30m Auflösung gibt. LIDAR Daten für größere Gebiete werden üblicherweise mit Flugzeug- oder Helikopterbeflug erhoben. Leider kocht da noch jedes Bundesland in Deutschland sein eigenes Süppchen was die Veröffentlichungs-Politik angeht, in Baden-Württemberg kannst Du die z.B. eigtl. nur gegen Geld bestellen.

Wie Sonny das Problem umgangen ist ist mir btw auch nicht bekannt, wäre aber mal interessant zu wissen.

Selber hab ich aktiv noch keine LIDAR Daten verarbeitet, schau sie mir aber sehr gerne aufbereitet an und finds cool was für Mehrwerte sie bringen. Und freu mich natürlich dementsprechend auch, wenn man sie sich in BRouter-Web zu Nutze macht.
 
quaelnix schrieb:
Wenn man in BRouter-Web Ebenen multiplikativ miteinander verrechnen könnte, hätte man damit eine nahezu perfekte Höhenschummerung.
Zum Vergrößern anklicken....
Genau, hab ich mir auch schon gedacht - wenn man einen Blendmodus pro Custom Overlay Layer einstellen könnte wäre das äußerst praktisch für den Zweck. Allerdings guck ich mir die Daten gerne auch manchmal einfach so an, da sieht man so schön viele Details die beim "Degradieren" zum Schummerungslayer schneller unter gehen.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
quaelnix schrieb:
...
Mit "HM Abweichungen" meinst du die Abweichung des von BRouter berechneten Gesamtanstiegs von den Gesamtanstiegen, die andere Plattformen berechnen?
Zum Vergrößern anklicken....
Nein, die sind meist sogar noch schlechter :D

Ich meine im praktischen nutzen mit Tachos. Also in unserm Fall 2xGarmin, 1x Wahoo und 1x Sigma.

Zuerst dachte ich es liegt an der neuen Garmin SW. Aber meine Frau hat noch die alte SW drauf, ich die Neue. Dennoch sind die Messdaten identisch.
Und bis ca. Anfang März waren die Abweichungen unter 10% .. jetzt wieder gut 30%

Ich will (wenn mal Zeit) mir mal alte Strecken vom Winter ansehn.
 
hholgi schrieb:
Und bis ca. Anfang März waren die Abweichungen unter 10% .. jetzt wieder gut 30%
Zum Vergrößern anklicken....
Wie gut oder schlecht der von BRouter berechnete Gesamtanstieg mit dem, was das Garmin anzeigt, übereinstimmt, hängt natürlich von der Strecke ab. Auf bikerouter.de hat sich nach meiner Kenntnis im letzten Jahr nichts geändert, was Einfluss auf den Gesamtanstieg hätte haben können.
hholgi schrieb:
Nein, die sind meist sogar noch schlechter :D
Zum Vergrößern anklicken....
Ok, aber woran machst du gut und schlecht fest? Wer sagt dir, dass das Garmin richtig und beispielsweise Strava falschliegt? Und nach welcher Methode sollte man den Gesamtanstieg deiner Meinung nach berechnen, wenn man die exakte Höhe an jedem Punkt der Strecke kennen würde?
 
quaelnix schrieb:
Wie gut oder schlecht der von BRouter berechnete Gesamtanstieg mit dem, was das Garmin anzeigt, übereinstimmt, hängt natürlich von der Strecke ab. Auf bikerouter.de hat sich nach meiner Kenntnis im letzten Jahr nichts geändert, was Einfluss auf den Gesamtanstieg hätte haben können.

Ok, aber woran machst du gut und schlecht fest? Wer sagt dir, dass das Garmin richtig und beispielsweise Strava falschliegt? Und nach welcher Methode sollte man den Gesamtanstieg deiner Meinung nach berechnen, wenn man die exakte Höhe an jedem Punkt der Strecke kennen würde?
Zum Vergrößern anklicken....
Guter Einwand: jeder Hersteller verwendet unterschiedliche Berechnungsalgorithmen (Hysteresefaktor, Glättung der Höhenwerte, etc.). Selbst Garmin ändert da immer wieder etwas an den Berechnungsmethoden, sodass selbst bei kleineren Runden je nach Gerät schon relativ große Abweichungen auftreten können. Mal mehr, mal weniger.

Viel Spaß dabei, das alles in eine universelle Formel zu packen 😇

1686818771423.png
 
Natürlich gibt es bei diesem Thema keine wirklich genauen Werte.
Aber die Relationen können durchauzs passen und sollten sich eigentlich nicht ändern.

Das Garmin/Sigma (bis vor kurzem) recht nah an den Breouter Daten liegen ist natürlich Glück (Zufall). Außer bei reinen Flachlandstrecken passte das immer.

Ein Alltrails meldet mir mal eben das doppelte:wut: ...

Wenn diese Relativen Abweichungen sich deutlich ändern wirds halt unangenehm.
In meinem Alter und mit künstlichen Gelenken ist es schon wichtig zu wissen ob ich "echte" 1000Hm vor mir habe die ich kann ... oder ob das 2000HM werden bei denen ich abbrechen müsste.
 
Es gibt doch nicht einmal "die" Brouterhöhenmeter.
Vergleiche mal diese 2 im Prinzip identischen Abschnittsbeispiele: Mit wenig Zwischenpunkten (7,7km/277hm) und mit vielen Zwischenpunkten (8,1km/325hm) Obwohl optisch kein Unterschied in der Strecke erkennbar ist, wird schon deutlich anders gerechnet, sowohl die Entfernung als auch die Höhenmeter. Und fast 50hm bei dieser kurzen Strecke sind schon eine relativ große Abweichung. Von dem her ist es wohl dann auch Zufall, wie genau die geplante Tour dann mit den Garmin-Werten übereinstimmt.

Bei unseren Touren letzte Woche waren die Garmin-Werte immer sehr nahe an Brouter. 3 Beispiele (wobei alle ziemlich gut gepasst hatten):
Garmin zu Brouter
42,16km/919hm zu 42,7km/884hm,
31,74km/1405hm zu 31,8km/1454hm,
30,18km/1544hm zu 31,0km/1563hm
 
scratch_a schrieb:
Es gibt doch nicht einmal "die" Brouterhöhenmeter.
Vergleiche mal diese 2 im Prinzip identischen Abschnittsbeispiele: Mit wenig Zwischenpunkten (7,7km/277hm) und mit vielen Zwischenpunkten (8,1km/325hm) Obwohl optisch kein Unterschied in der Strecke erkennbar ist, wird schon deutlich anders gerechnet, sowohl die Entfernung als auch die Höhenmeter. Und fast 50hm bei dieser kurzen Strecke sind schon eine relativ große Abweichung.
Zum Vergrößern anklicken....

In deiner 2ten Route ist ein Fehler. Da routest Du beim Kleinvoggenhof vor- und zurück. Sieht man auch schön im Höhenprofil und deswegen auch die Differenz in der Distanz.

Dass zusätzliche Wegpunkte die Höhenmeter-Rechnung verändern ist aber interessant zu wissen. Vermute mal, die Wegpunkte werden dann explizit anhand des hinterlegten Höhengitters zusätzlich genau an der Position des Wegpunkts als zusätzlicher Step mit einberechnet, während mit weniger Wegpunkten nur die einzelnen Vektor-Punkte der Wegkarte auf dem Höhengitter durchgerechnet werden. Dadurch kommt es dann zu einer anderen Summe am Ende.
 
Zuletzt bearbeitet:
momentmal schrieb:
In deiner 2ten Route ist ein Fehler. Da routest Du beim Kleinvoggenhof vor- und zurück. Sieht man auch schön im Höhenprofil und deswegen auch die Differenz in der Distanz.

Dass zusätzliche Wegpunkte die Rechnung verändern ist aber interessant zu wissen. Vermute mal, die Wegpunkte werden dann explizit anhand des hinterlegten Höhengitters zusätzlich genau an der Position des Wegpunkts als zusätzlicher Step mit einberechnet, während mit weniger Wegpunkten nur die einzelnen Vektor-Punkte der Wegkarte auf dem Höhengitter durchgerechnet werden. Dadurch kommt es dann zu einer anderen Summe am Ende.
Zum Vergrößern anklicken....

Ah danke, war wohl gestern Abend schon zu spät für mein Hirn...hab ewig den Fehler gesucht und nicht gefunden. Aber selbst nach Korrektur bleibt noch eine gute Differenz der hm, km sind dann gleich :)
Und wie @hholgi schon richtig sagte, darüber wurde hier schon hin wieder mal diskutiert :D
 
momentmal schrieb:
Dass zusätzliche Wegpunkte die Höhenmeter-Rechnung verändern ist aber interessant zu wissen.
Zum Vergrößern anklicken....
Das ist Endeffekt ein Bug, der zwar in BRouter v1.7.0 behoben wurde, aber dadurch, dass BRouter-Web sich jeden Zwischenabschnitt einzeln von BRouter holt, wird das Problem zumindest in BRouter-Web vorerst weiter bestehen. Die einzige wirklich praktikable Lösung wäre nämlich, dass BRouter-Web den Gesamtanstieg am Schluss noch mal neu berechnet.
 
Zuletzt bearbeitet:
quaelnix schrieb:
Die einzige wirklich praktikable Lösung wäre nämlich, dass BRouter-Web den Gesamtanstieg am Schluss noch mal neu berechnet.
Zum Vergrößern anklicken....

Naja, eigtl. würde es ja reichen, wenn BRouter nicht strikt von "Wegpunkt über vorhandene Pfade zu Wegpunkt" rechnen würde, sondern immer von letztem Vektor-Pfadpunkt und nathlos daran anschließend dann das Folgesegment vom gleichen Vektor-Pfadpunkt aus. Dann gäbe es keine inkonsistenten Summen und Nutzer-Wegpunkte sind ja eigtl. sowieso quasi nur ein visueller Input um anzuzeigen in welcher Nähe BRouter nach möglichen Pfadpunkten suchen soll. Einen Wegpunkt kann man ja (bis auf die neue Luftlinienfunktion) sowieso nicht irgendwo ins grüne ziehen, BRouter wird immer nach Pfaden in der Nähe suchen und die eigtl. Route sowieso streng nach diesen anlegen. Also könnte man die Nutzer-Wegpunkte und deren Höhe auch gleich von jeglicher Rechnung ausschließen, zumindest solange sie nicht mit der Luftlinienfunktion gesetzt wurden.
 
@momentmal, hier mal am Beispiel von BRouter v1.7:
BRouter (via BRouter-Web)​
BRouter (direkt)​
Zwischenpunkte​
Keine Zwischenpunkte​
momentmal schrieb:
Also könnte man die Nutzer-Wegpunkte und deren Höhe auch gleich von jeglicher Rechnung ausschließen
Zum Vergrößern anklicken....
Die Höhe der Nutzerwegpunkte war noch nie ausschlaggebend. Das Problem war, dass der Filter, der die rohen Höhendaten für die Berechnung des Gesamtanstiegs glättet, in BRouter v1.6.3 bei jedem Nutzer-Wegpunkt zurückgesetzt wurde. In BRouter v.1.7 ist das nicht mehr der Fall, siehe obige Tabelle.
momentmal schrieb:
Naja, eigtl. würde es ja reichen, wenn BRouter nicht strikt von "Wegpunkt über vorhandene Pfade zu Wegpunkt" rechnen würde
Zum Vergrößern anklicken....
Nein, wenn man die Route aus Teilsegmenten zusammenstückelt, dann hat man wieder das Problem, dass der Höhenfilter am Beginn jedes Teilsegments zurückgesetzt wird, und sich dadurch in aller Regel das Ergebnis der Rechnung ändert, siehe obige Tabelle.
 
Moin @Marcus,

ich habe folgendes Problem mit der Einstellung "Oberflächenqualität":
Je nach eingestellter Zoom-Stufe "springt" die Anzeige der jeweiligen Farbe sehr stark.
Ich füge mal ein Beispiel an:
https://brouter.m11n.de/#map=12/53.....881291,53.160152&profile=Trekking-TertiariesIn diesem Streckenabschnitt wird die Oberfläche bis Zoomstufe 14 komplett in grau, also unbekannt, dargestellt.
In Stufe 15 wird ein Teil in rot dargestellt, der aber zu lang ist.
Erst ab Stufe 16 wird die Oberflächenqualität korrekt dargestellt.
Ich weiß das so genau, da ich den Abschnitt in "rot" selber in OSM eingepflegt habe.

Dieses Phänomen des "Springens" in den unterschiedlichen Zoomstufen ist mir auch bei anderen Abschnitten aufgefallen. Woran kann das liegen?

Nach meiner Meinung sollte spätestens ab Zoomstufe 12 die Oberflächenfarben korrekt angezeigt werden.


Gruß aus Ostfriesland

Martin
 
Zuletzt bearbeitet:
Wenn wir grad schon bei komischem Verhalten sind: Unter iOS bekomm ich bikerouter.de einfach nicht dazu, meine Position auf der Karte einzublenden, egal wie oft ich die iOS Prompts für Zugriff auf die Position erlaube. Egal ob native Safari App oder Chrome, wobei alle iOS Browser glaube ich intern sowieso immer Apples Webkit Browserengine nutzen müssen.

Der schlechte Touch-Support unter iOS wurde hier glaube ich schonmal thematisiert, der wäre nochmal ein anderes Thema - aber das mit der aktuellen Position wäre tatsächlich unterwegs schon sehr gut wenn das funktioniert, mit der hakeligen Touch-Bedienung habe ich mich so einigermaßen arrangiert.. 🙈
 
Moin @Marcus

Hast du diese Frage evtl. übersehen?
emmeff schrieb:
Moin @Marcus,

ich habe folgendes Problem mit der Einstellung "Oberflächenqualität":
Je nach eingestellter Zoom-Stufe "springt" die Anzeige der jeweiligen Farbe sehr stark.
Ich füge mal ein Beispiel an:
https://brouter.m11n.de/#map=12/53.....881291,53.160152&profile=Trekking-TertiariesIn diesem Streckenabschnitt wird die Oberfläche bis Zoomstufe 14 komplett in grau, also unbekannt, dargestellt.
In Stufe 15 wird ein Teil in rot dargestellt, der aber zu lang ist.
Erst ab Stufe 16 wird die Oberflächenqualität korrekt dargestellt.
Ich weiß das so genau, da ich den Abschnitt in "rot" selber in OSM eingepflegt habe.

Dieses Phänomen des "Springens" in den unterschiedlichen Zoomstufen ist mir auch bei anderen Abschnitten aufgefallen. Woran kann das liegen?

Nach meiner Meinung sollte spätestens ab Zoomstufe 12 die Oberflächenfarben korrekt angezeigt werden.


Gruß aus Ostfriesland

Martin
Zum Vergrößern anklicken....


Gruß aus Ostfriesland

Martin
 
Hat jemand eine Idee, wie man sich Gebiete mit Einschränkungen hervorheben lassen kann?
Konkret geht es um Nationalparks (in diesem Fall deutsche und tschechische). In der OSM-Standard-Ansicht sind die Grenzen grün, und das meistens auf grünem Grund, das nervt sehr. Ich plane eine Reise im Böhmerwald/Bayerischen Wald und will natürlich nicht dort fahren, wo es aus gutem Grund völlig verboten ist.
 
Bitte beachte unsere Verhaltensregeln beim Antworten. Danke 🙂
Zurück
Oben Unten