BBBike Log
BBBike implementation log
Rechtspfeil
ich würde gerne die hässliche Notation ((VonStraße) - ZurStraße)durch die etwas weniger hässliche Notation (VonStraße → ZurStraße)zu ersetzen. Allerdings stellt sich die Frage: kann man sicher sein,dass überall der Pfeil sichtbar ist? Klar, alles kann heutzutage utf-8und Unicode. Das sagt aber nichts darüber aus, ob auch alle in Unicodeaufgelisteten Zeichen in allen Fonts verfügbar sein. Mein Emacs kannz.B. den Rechtspfeil oben nicht darstellen, wahrscheinlich, weil meineVersion von LucidaSansTypewriter dieses Zeichen nicht hat.In der Unicode-NamesList habe ich mir einige Kandidaten für denRechtspfeil angeschaut:→ rightwards arrow↣ with tail↦ from bar⇏ double with stroke⇒ double⇨ white⇰ white from wall⇾ open headedKein Problem in Seamonkey unter FreeBSD, alle Zeichen werdendargestellt. Ebenso auf dem Opera. Firefox auf dem Windows-Rechnerstellt auch alle Zeichen dar, aber "white from wall" erzeugt irgendwieeinen riesigen vertikalen Freiraum. IE8 auf dem gleichen Rechner hatdagegen keine Probleme. Bei beiden Browsern werden auch unterschiedlicheFonts verwendet, wobei der im Firefox verwendete Font nicht besondersschöne Pfeile hat.OK, das waren die leichten Browser. Wie sieht's auf dem Nokia N95 aus?Eigentlich könnte ich mit meiner Untersuchung aufhören, denn hier wirdnur der erste Pfeil (rightwards arrow) angezeigt. Der Vollständigkeithalber probiere ich auch Opera Mini auf dem gleichen Gerät aus. Hmmm,kein einziger Pfeil wird als solcher angezeigt. Lynx verwendet für"rightwards arrow" und "double" eine akzeptable Ersatzdarstellung (ichhabe nur ein latin1-Terminal). Der Rest wird als Entity angezeigt. w3mzeigt nur Fragezeichen. Wenn ich das Terminal auf utf8 umschalte, dannverschwinden die Fragezeichen und ich sehe nichts --- wahrscheinlichwerden jetzt Unicode-Zeichen angezeigt, die mein Terminal-Font nichtunterstützt.Conclusio? Vielleicht könnte ich den Pfeil vorsichtig verwenden, z.B.nur, wenn es sich um einen Desktop-Browser handelt. Oder ich wartenochmal ein Jahr ab. Oder ich verwende einfach eine vorsintflutlicheASCII-Kombination: -> oder => oder wenigstens iso-8859-1: -»
Slaven Rezic <slaven@rezic.de>
ich würde gerne die hässliche Notation ((VonStraße) - ZurStraße) durch die etwas weniger hässliche Notation (VonStraße → ZurStraße) zu ersetzen. Allerdings stellt sich die Frage: kann man sicher sein, dass überall der Pfeil sichtbar ist? Klar, alles kann heutzutage utf-8 und Unicode. Das sagt aber nichts darüber aus, ob auch alle in Unicode aufgelisteten Zeichen in allen Fonts verfügbar sein. Mein Emacs kann z.B. den Rechtspfeil oben nicht darstellen, wahrscheinlich, weil meine Version von LucidaSansTypewriter dieses Zeichen nicht hat. In der Unicode-NamesList habe ich mir einige Kandidaten für den Rechtspfeil angeschaut: → rightwards arrow ↣ with tail ↦ from bar ⇏ double with stroke ⇒ double ⇨ white ⇰ white from wall ⇾ open headed Kein Problem in Seamonkey unter FreeBSD, alle Zeichen werden dargestellt. Ebenso auf dem Opera. Firefox auf dem Windows-Rechner stellt auch alle Zeichen dar, aber "white from wall" erzeugt irgendwie einen riesigen vertikalen Freiraum. IE8 auf dem gleichen Rechner hat dagegen keine Probleme. Bei beiden Browsern werden auch unterschiedliche Fonts verwendet, wobei der im Firefox verwendete Font nicht besonders schöne Pfeile hat. OK, das waren die leichten Browser. Wie sieht's auf dem Nokia N95 aus? Eigentlich könnte ich mit meiner Untersuchung aufhören, denn hier wird nur der erste Pfeil (rightwards arrow) angezeigt. Der Vollständigkeit halber probiere ich auch Opera Mini auf dem gleichen Gerät aus. Hmmm, kein einziger Pfeil wird als solcher angezeigt. Lynx verwendet für "rightwards arrow" und "double" eine akzeptable Ersatzdarstellung (ich habe nur ein latin1-Terminal). Der Rest wird als Entity angezeigt. w3m zeigt nur Fragezeichen. Wenn ich das Terminal auf utf8 umschalte, dann verschwinden die Fragezeichen und ich sehe nichts --- wahrscheinlich werden jetzt Unicode-Zeichen angezeigt, die mein Terminal-Font nicht unterstützt. Conclusio? Vielleicht könnte ich den Pfeil vorsichtig verwenden, z.B. nur, wenn es sich um einen Desktop-Browser handelt. Oder ich warte nochmal ein Jahr ab. Oder ich verwende einfach eine vorsintflutliche ASCII-Kombination: -> oder => oder wenigstens iso-8859-1: -»
Falsche Straßennamen
letzten Donnerstag (10. Juni) war die Webversionvon BBBike mehr oder weniger kaputt. Beim Datenupdate kam es zu einerInkonsistenz zwischen den Daten und Cachedateien, so dass zwargeografisch die richtigen Routen berechnet wurden, aber diese teilweisefalschen Straßennamen zugeordnet wurden. Zum Glück...
letzten Donnerstag (10. Juni) war die Webversion von BBBike mehr oder weniger kaputt. Beim Datenupdate kam es zu einer Inkonsistenz zwischen den Daten und Cachedateien, so dass zwar geografisch die richtigen Routen berechnet wurden, aber diese teilweise falschen Straßennamen zugeordnet wurden. Zum Glück haben den Fehler zwei User gemeldet, so dass ich es überhaupt bemerkt habe und durch ein Löschen aller Cachedateien das Problem beheben konnte. Für die Zukunft heißt das: - Nach dem Datenupdate werden *alle* alten Cachedateien gelöscht (bislang wurde nur ein Teil gelöscht). - Der cgi-mechanize.t-Test wurde erweitert, so dass einige Routenergebnisse Straße für Straße geprüft werden. Perfekt ist das noch immer nicht. Das Datenupdate ist nicht ganz atomar, so dass während eines kurzen Zeitfensters beim Update noch immer Probleme auftauchen können. Aber hoffentlich ist das Zeitfenster recht klein, auch dank "rsync --delay-updates".
Unerwartete GPS-Genauigkeit
ein mögliches Attribut bei Straßen inBBBike ist die Breite der Straße. Dieses wird in Zukunft dafürverwendet, um optional Straßen in ihrer tatsächlichen Breite auf derPerl/Tk-Karte zu zeichnen.Heute war ich auf dem Flughafen Tempelhof unterwegs und habe mit demalten GPS-Gerät (ein Garmin emap) die B...
ein mögliches Attribut bei Straßen in BBBike ist die Breite der Straße. Dieses wird in Zukunft dafür verwendet, um optional Straßen in ihrer tatsächlichen Breite auf der Perl/Tk-Karte zu zeichnen. Heute war ich auf dem Flughafen Tempelhof unterwegs und habe mit dem alten GPS-Gerät (ein Garmin emap) die Breite der nördlichen Landebahn vermessen. Das Ergebnis: 43m. Dann habe ich bei Wikipedia (http://de.wikipedia.org/wiki/Flughafen_Berlin-Tempelhof) nachgeschaut: stimmt exakt, dort steht auch 43m! Diese GPS-Genauigkeit habe ich nicht erwartet.
Bad Benchmarks
Eine goldene Regel beim Benchmarken: immer prüfen, obdie geprüften Funktionen tatsächlich das Gleiche zurückgeben! Ich habeeinen alten, bislang nur im RCS lebendenBenchmark (miscsrc/strassen_benchmark.pl) ausgegraben und insgit-Repository verschoben. Dieser Benchmark hat immer behauptet, dassdie Str...
Eine goldene Regel beim Benchmarken: immer prüfen, ob die geprüften Funktionen tatsächlich das Gleiche zurückgeben! Ich habe einen alten, bislang nur im RCS lebenden Benchmark (miscsrc/strassen_benchmark.pl) ausgegraben und ins git-Repository verschoben. Dieser Benchmark hat immer behauptet, dass die Strassen::Storable-Implementation langsamer als die normale Strassen oder eine DB_File-Variante ist. Leider war dieser Benchmark immer schon falsch gewesen: die Schleife über alle Datensätze hatte einen fehlerhafte Bedingung und ist schon nach dem ersten Datensatz ausgestiegen. Nachdem der Benchmark korrigiert wurde, ergibt sich ein völlig anderes Bild: DB_File/RECNO ist nun mit Abstand am langsamsten, dann folgen die Pure-Perl-Varianten (wobei sowohl die Streaming-Variante als auch die normale Variante sich nicht groß unterscheiden), und schließlich als Schnellstes die Storable-Variante. Also lohnt es sich vielleicht doch, die Storable-Variante (z.B. für binäre BBBike-Distributionen) zu verwenden.
Umzug zu git
Das Haupt-Repository von BBBike ist ab sofort alsgit-Repository bei github erreichbar: Clone-URL: git://github.com/eserte/bbbike.git Webseiten: http://github.com/eserte/bbbikeIntern habe ich schon seit einigen Monaten git verwendet und mitgit-cvsimport und git-cvsexportcommit von und zum CVS-Reposit...
Das Haupt-Repository von BBBike ist ab sofort als git-Repository bei github erreichbar: Clone-URL: git://github.com/eserte/bbbike.git Webseiten: http://github.com/eserte/bbbike Intern habe ich schon seit einigen Monaten git verwendet und mit git-cvsimport und git-cvsexportcommit von und zum CVS-Repository bei SourceForce synchronisiert. Wegen Bugs in der git-cvs-Brücke (genauer: in cvsps, welches von git-cvsimport verwendet wird) funktioniert aber diese Synchronisation nicht mehr. Deshalb die Flucht nach vorne. Das alte CVS-Repository werde ich aber in unregelmäßigen Abständen weiterhin up-to-date halten. Wahrscheinlich werde ich dafür die alte RCS-CVS-Brücke etwas umbauen.
"Eigentlich ein Knoten"
gerade habe ich zwei Datensätze in der"fragezeichen"-Datei, die den Text "eigentlich ein Knoten" enthielten,ersatzlos gelöscht. Dabei handelte es sich um Knoten an der B5 vonSpandau Richtung Nauen, die in der BBBike-Karte nur als normale Kreuzungdargestellt waren, ohne detaillier...
gerade habe ich zwei Datensätze in der "fragezeichen"-Datei, die den Text "eigentlich ein Knoten" enthielten, ersatzlos gelöscht. Dabei handelte es sich um Knoten an der B5 von Spandau Richtung Nauen, die in der BBBike-Karte nur als normale Kreuzung dargestellt waren, ohne detaillierte Ausfahrten darzustellen. Die restlichen Autobahnen und Kfz-Straßen sind ja auch nur grob dargestellt, sollen nur einen ungefähren Orientierungspunkt geben, und, was das Wichtigste ist, sind für das Routing sowieso nicht interessant.
osm2bbd
osm2bbd verwendet jetzt XML::LibXML::Reader statt derDOM-Funktionalität von XML::LibXML. Der Grund war, dass das Parsen dervorgefertigten Länder-OSM-Dateien (Brandenburg und Berlin) zu vielSpeicher verbraucht hatte, weit über 2GB. Die Implementation mitXML::LibXML::Reader ist weit schwieriger und fe...
osm2bbd verwendet jetzt XML::LibXML::Reader statt der DOM-Funktionalität von XML::LibXML. Der Grund war, dass das Parsen der vorgefertigten Länder-OSM-Dateien (Brandenburg und Berlin) zu viel Speicher verbraucht hatte, weit über 2GB. Die Implementation mit XML::LibXML::Reader ist weit schwieriger und fehleranfälliger. Das Ergebnis scheint aber jetzt in Ordnung zu sein (der alte XML::LibXML-Parser ist weiterhin verfügbar und ein diff zwischen beiden Ergebnissen zeigt keinen Unterschied), und der neue Parser ist sogar etwas schneller. Wo ich gerade bei den OpenStreetMap-Daten war, habe ich noch einige Fehler in den osm-Daten per Merkaartor behoben. Aber wie spezifiziert man dort eine für Radfahrer offene Einbahnstraße?