2010-06 / 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Letzten 7 Tage / Monat
2010-06-22 Tue
■ 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-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: -»
2010-06-12 Sat
■ Falsche Straßennamen
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".
2010-05-12 Wed
■ Unerwartete GPS-Genauigkeit
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.
2009-10-06 Tue
■ Bad Benchmarks
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.
2009-08-04 Tue
■ Umzug zu git
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.
2009-08-02 Sun
■ "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 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.
2009-01-11 Sun
■ osm2bbd
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?
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
Letztes Update: 2026-06-05 20:13