2010-06-22  Slaven Rezic  <slaven@rezic.de>

	* 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  Slaven Rezic  <slaven@rezic.de>

	* 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  Slaven Rezic  <slaven@rezic.de>

	* 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  Slaven Rezic  <slaven@rezic.de>

	* 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  Slaven Rezic  <slaven@rezic.de>

	* 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  Slaven Rezic  <slaven@rezic.de>

	* "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  Slaven Rezic  <slaven@rezic.de>

	* 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?

2008-11-16  Slaven Rezic  <slaven@rezic.de>

	* U-Bahn-Tunnelstrecken: Heute habe ich entdeckt, dass die U5 einen
	Tunnelabschnitt zwischen Kaulsdorf-Nord und Wuhletal. Das habe ich zum
	Anlass genommen, das bereits geplante Projekt "U-Bahn-Tunnelabschnitte
	markieren" durchzuführen. Das erweiterte Projekt würde noch Einschnitt-
	und Dammstrecken umfassen, aber das habe ich für später aufgeschoben.

	Dabei habe ich gemerkt, dass U-Bahnlinien und Autobahnen die gleiche
	Kartensignatur haben. Um das zu verbessern, werden die Autobahnen-Linien
	nun mit einer dünnen Linie in der Mitte gezeichnet, so dass man einen
	"Zwei-Bahnen"-Effekt hat. Leider gibt es einige Stellen im Programmcode,
	die man bei Kartensignaturänderungen anpassen muss: die eigentliche
	Funktion zum Zeichnen (generate_plot_functions) und das Zeichnen der
	Legende (in BBBikePrint.pm). Da die dünne Linie bei großen Maßstäben
	nicht gezeichnet werden darf (die Autobahn-Linien sind dann zu dünn
	dafür), muss diese bei einigen Zoomstufen ausgeblendet werden --- dass
	muss in change_category_visibility() passieren, aber auch beim initialen
	Zeichnen.

2008-11-06  Slaven Rezic  <slaven@rezic.de>

	* gpx2bbd: Für große GPX-Dateien (so um die 1.5 MB) war das Skript bei
	Verwendung des XML::LibXML-Moduls unheimlich langsam: über zwei Minuten
	auf einem Athlon 64 3500+. Mit XML::Twig war es erträglich: etwa 8
	Sekunden. Nachdem ich das Skript mit Devel::NYTProf durchlaufen habe,
	war der Übeltäter schnell gefunden: ich habe statt

	    $xmlnode->find('./@...')

	das schnellere

	    $xmlnode->getAttribute('...')

	verwendet. Danach brauchte das Skript nur noch eine Sekunde, also über
	120x so schnell!

2008-08-24  Slaven Rezic  <slaven@rezic.de>

	* fast_plot_str und osm: Um Tunnels und Brücken mit der "fast"-Version
	zu unterstützen, werden jetzt auch die richtigen Aufrufe von draw_bridge
	und draw_tunnel_entrance gemacht. Leider muss ich mit dieser Doppelung
	von Code leben --- die einzige Alternative ist, schon früher aus XS
	heraus eine Perl-Subroutine ähnlich plotstr_draw_sub aufzurufen. Damit
	würde aber auch etwas vom Geschwindigkeitsvorteil verloren gehen.

	* osm2bbd: Labels für Inseln werden anscheinend mit place=island
	gekennzeichnet (gesehen bei den dalmatinischen Inseln). osm2bbd erzeugt
	jetzt also die Kategorie "I" in der Datei "wasserstrassen" für solche
	osm-Items, und bbbike kann damit etwas anfangen.

	Viele von Wolfram berichtete Kleinigkeiten verbessert bzw. seine Patches
	angewendet (-debug/-verbose, curl ...).

	Weiterhin hat sich die -center-Handhabung nochmal geändert. Bei osm2bbd
	wird jetzt mit -center ein Hint für den Renderer gesetzt (damit wird
	"center" in die Metadatei geschrieben; bbbike kann damit umgehen und
	bevorzugt diesen Wert anstelle der Mitte der Bounding-Box). Die alte
	Bedeutung von -center erhält man jetzt mit -centerdelta; aber ich
	glaube, dass man diese Option nicht mehr braucht. Denn diese Option ist
	jetzt eigentlich nur noch dazu gut, um "kleine" Koordinaten
	(Koordinaten, die sich in der Nähe von 0,0 befinden) zu erhalten.

2008-08-23  Slaven Rezic  <slaven@rezic.de>

	* chalow: Im Netz habe ich chalow gefunden, ein Programm, mit dem man
	ChangeLog-Dateien (wie diese Datei hier) in ein blog-ähnliches HTML
	umwandeln kann. Leider ist das Programm komplett japanisch dokumentiert
	und die Ausgabe sieht trotz der lateinischen Zeichen japanisch aus
	(wegen <html lang=ja>). Aber mit ein bisschen raten habe ich die
	Konfigurationsdatei soweit bekommen, dass es ansehlich aussieht. Die
	HTML-Ausgabe wird unter der Adresse
	http://bbbike.sourceforge.net/bbbikelog/index.html zu sehen sein.

	* osm2bbd: Wolfram hat sich beschwert, dass Datasets, die mit osm2bbd
	erzeugt werden, in bbbike nicht automatisch an die richtige Stelle
	zentriert werden. Außerdem sind die Daten meist gar nicht in der
	Scrollregion enthalten und man muss "enlarge scrollregion" aufrufen.

	Um das zu verbessern, schreibt osm2bbd jetzt eine Metadatei (meta.dd und
	meta.yml), in der unter anderem die Bounding-Box der Daten steht.
	bbbike liest diese Metadatei ein und macht automatisch ein "enlarge
	scrollregion", und außerdem wird in die Mitte der Bounding-Box
	zentriert.

	Das initiale Zentrieren in bbbike ist schon eine Wissenschaft für sich.
	Es gibt die Optionen -center (auf eine Straße zentrieren) und -centerc
	(auf Koordinaten zentrieren). -center funktioniert nur mit den Berliner
	Daten, weil PLZ.pm verwendet wird. -centerc dürfte überraschende
	Ergebnisse liefern, wenn man einen Wert in der Konfigurationsdatei
	gespeichert hat und dann zwischen unterschiedlichen Datesets wechselt.
	Weiterhin kann man in Geography::*-Modulen ein Zentrum festlegen.

2008-08-22  Slaven Rezic  <slaven@rezic.de>

	* mkgpmap: Zum ersten Mal zum Laufen gebracht. Ein naiver Aufruf auf das
	Verzeichnis mit den Münchener .osm-Dateien hat die java-vm zum Absturz
	gebracht. Wahrscheinlich waren es zu viele Dateien. Auf die schnelle ein
	Skript zum Zusammenfassen der .osm-Dateien geschrieben
	(miscsrc/combineosm). Dann funktioniert mkgpmap. Mit diesem Kommando
	kann man ein .img erzeugen:

	java -jar mkgmap.jar --description="Muenchen OSM" muenchen.osm

	Die erzeugte Datei bekommt einen zufälligen (?) Dateinamen. Was
	besonders schön ist: man kann mehrere Garmin-Images zusammenfassen:

	java -jar mkgmap.jar --gmapsupp ~/src/bbbike/tmp/bbbikequal.img ~/src/bbbike/tmp/muenchen_osm.img

	Das erzeugt ein Image mit dem wohlbekannten Namen gmapsupp.img.
	
2008-08-20  Slaven Rezic  <slaven@rezic.de>

	* define_item_attribs: Wird jetzt später aufgerufen, nachdem $city
	verfügbar ist, damit einige Berlin-spezifische Labels überschrieben
	werden. Hoffentlich hängt etwas anderes nicht von der Reihenfolge hier
	ab...

	* fast_plot_str/point: Folgendes TODO habe ich heute implementiert:
	
	| BBBikeXS.pm: the fast plotting routines cannot deal with encodings
	| (utf8!), it seems. At least check for it.

	Damit werden osm-Daten mit utf8-Encoding korrekt im "fast"-Modus
	dargestellt. Es werden aber nur die Encodings iso-8859-1 und utf-8
	unterstützt (das ist auch in bbd.pod dokumentiert) --- alles andere ist
	heutzutage wahrscheinlich nicht notwendig.

2008-08-17  Slaven Rezic  <slaven@rezic.de>

	* Bahnhöfe: Im Zuge des Vorschlags für eine neue Kartensignatur für
	Bahnlinien habe ich auch überlegt:

	| Für Bahnhöfe könnte man ein weißes Rechteck mit schwarzem Rand nehmen,
	| welches parallel zur Bahnstrecke gedreht ist.

	Mir gefällt aber das gegenwärtige Eisenbahnsymbol eigentlich. Also keine
	weiteren Aktionen hier nötig.

	* Sehenswürdigkeiten: rot oder grau?

	Sehenswürdigkeiten vielleicht grau statt rot einfärben wie beim
	Mapserver? Das sieht nicht so aufdringlich aus. Auch bei anderen
	Ausgabeformaten (BBBikeDraw) überlegen.
	
	Aber: bei osm kann man sich Bebauungsflächen besorgen. Und diese will
	man dann tatsächlich grau zeichnen. In diesem Fall will man eine
	Unterscheidung haben.

	Wie machen es andere Karten (öffentliche Gebäude/bebaute Flächen)? RV:
	rot/grau; Pharus: orange/grau; Pietruska: graurosa (kaum Kontrast)/grau;
	Google: rosa/grau (nur Krankenhäuser); Stadtplandienst: rosa+roter
	Rand/grau
	
	Ergo: rot ist OK! Vielleicht kann man den Kontrast etwas abschwächen.
	Vielleicht sollte man beim Mapserver auch wieder zurück zu rot gehen.

	* Windows und GfxConvert: Der TODO-Vorschlag:

	| GfxConvert: add more search paths on Windows machines
  | like C:/Programme/gs/gs8.14/lib;C:/Programme/GnuWin32/bin

	wurde ungetestet umgesetzt.

	* scale_coords: In scale_width sollte wirklich nur die Breite eines
	Canvas-Items angepasst werden. Da die Skalierung in scalecanvas nach dem
	Aufruf von scale_width erfolgt, müssen Koodinatenanpassungen später
	gemacht werden. Dazu ist jetzt scale_coords da.

	Schmutzigerweise ist die "Breiteninformation" für comm-scenic-View in
	%line_width enthalten.

	* Schöne Aussicht: eine einigermaßen befriedigende Implementation
	existiert jetzt. Der alte Eintrag in TODO hat folgendes vorgeschlagen:

	| Aussichtspunkte-Signatur. Idee: Ich könnte ein "View"-Symbol wie folgt
	| zeichen: stipple mit einem
	| vollen Kreis für den Aussichtspunkt für eine feste Größe, z.B. 20x20
	| Pixel vorbereiten. Die bbd-Kategorie sieht dann so aus:
	| View:start:extent und wird mit createArc gezeichnet. Mögliches
	| Problem: beim Zoomen dürfen diese Items nicht angefasst werden oder
	| der Stipple muss sich relativ anpassen. Evtl. kann man ab
	| bestimmten Zoomstufen auf den Stipple verzichten und nur ein
	| Kreissegment zeichnen. (Letzteres ist provisorisch implementiert
	| worden)
	| 
	| Zunächst muss ich aber inkscape zum Laufen bekommen, damit ich die
	| volle Signatur für das Stipple damit zeichnen kann.

	inkscape läuft hier mittlerweile, und ein Aussichtspunkt-SVG existiert
	auch. Das Problem ist, dass man den Ankerpunkt von Stipples bei Perl/Tk
	nicht steuern kann. Die Mitte des Stipples *muss* aber mit der Mitte des
	Canvas-Items zusammenfallen, ansonsten funktioniert es nicht.

	Jetzt ist es so gelöst, dass in 30°-Schritten Kreissegmente der Breite
	15° gezeichnet werden.

	* implementation_log.txt: Diese Datei (auch als BBBike Log bekannt) soll
	vermeiden, dass Implementations-Gedanken verloren gehen. Zum Beispiel
	kann man implementierte Punkte aus TODO.pod hierher übertragen und
	kommentieren.

	Local Variables:
	mode: change-log
	coding: utf-8
	change-log-default-name: "implementation_log.txt"
	tab-width: 2
	left-margin: 2
	End:
