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 31
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
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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:
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