=head1 BBBike: TODO

Legend:

  Challenge level:

    E: easy/fast to implement
    M: middle
    H: hard/time consuming to implement

  Priority from 1 (unimportant) to 5 (very important).

  #: showstopper for next release

  Classification:

    bug, external bug
    feature, external feature
    improvement

=head1 Perl/Tk version of BBBike

=over

=item * (M3) (bug)

Einen Workaround finden, damit die Comboboxen auch einen weißen
Hintegrund bekommen (z.B. im Tk::Getopt-Fenster).

Lösungsansatz: Tk::MyBrowseEntry definieren, welches
ConfigSpecs(-foreground=>['SELF'],-background=>['SELF']) macht
Dann müsste die Definition
$top->optionAdd("*MyBrowseEntry.LabEntry.background", "grey95", ...)
funktionieren
Erschwerend kommt hinzu, dass diese MyBrowseEntry *überall* verwendet
werden müsste. Oder BrowseEntry::Populate wird direkt gepatcht? So:
*oldPopulate = \&Tk::BrowseEntry::Populate;
*Tk::BrowseEntry::Populate = sub { my $w = shift; oldPopulate($w, @_); $w->ConfigSpecs(-background=>['SELF'],...)};

=item * (M3) (improvement)

Unter Unix kann ich dort noch einen File-Selector mit Default auf
/dev anbieten, das Geräte immer dort anzufinden sind.

=item * (H4) (feature)

The default street might appear by default in the street chooser (only
for streets!).

=item * (H4) (feature)

Better interface for the center coordinate configuration entry, e.g.
choosing the current map center, or letting the user choose the coord
in the map. -> use Tk::Getopt's custom E<quot>widgetE<quot>
functionality; this would set a new map mode with a new cursor (what
text next to the pointer?),maybe show also a help dialog with a cancel
button. The user may click on the map, or hit escape/cancel, or close
the getopt window, everything restoring the old map mode and in the
first case setting the new coords.

(This feature request was already in the list:)

Option -centerc auch schöner zugänglich machen. Eine Möglichkeit
wäre, im Optionseditor einen Button neben der Option anzubieten, der
in den set-coord-mode geht, cursor aendert, das tk-getopt-fenster
withdraw-t, und darauf wartet, dass der benutzer auf die karte klickt
oder E<quot>cancelE<quot> drückt.

=item * (H4) (feature)

Better interface for the center street configuration entry, i.e. use
some kind of street chooser functionality (maybe browseentry style? or
as a dialog?) Also, it is not clear what has currently precedence:
center coordinate or center street?

Question: let the user only choose Berlin streets or also streets
outer Berlin?

Also here: use Tk::Getopt's custom widget functionality.

=item * (H3) (feature)

Create a small toolbar in the footer bar which displays the
current optimization settings in a few letter or with images. Also, a
shortcut to change the optimization settings should be possible there,
at least by showing the existing preferences window.

=item * (H5)

Aufräumen des Options-Editors.

Sobald Tk::Getopt es unterstützt, vertikalen Listenview statt Tabs
verwenden.

=item * (M5)

Der Optionseditor sollte auch Layer wie qualitaet, handicap etc.
unterstützen, eigentlich alles.

Es wäre auch schön, wenn der aktuelle Layereinschaltzustand auf
Knopfdruck als initialer Zustand übernommen werden könnte, oder der
letzte Zustand auf Wunsch immer wiederhergestellt wird. Man könnte
sogar beim *Start* fragen, ob der letzte Zustand wiederhergestellt
werden soll.

=item * (M3) (feature)

Routenliste: gewünschte Attribute für die Kommentare sollten über den
Options-Editor einstellbar sein bzw. beim Beenden automatisch
gespeichert werden.

=item * (M4)

If FontDialog is available, then use this instead of the *font entries
in the option editor. Make FontDialog also usable for fixed font
selection (this needs the relatively slow -fixedfont option of
FontDialog). Otherwise, if FontDialog is not available, the chosen
fonts should be made immediately visible using set_fonts().

=item * (M3)

Aliase sollten suchbar sein: implementiert in search_anything für
nicht-Similarity-Suchen und nicht-egrep-Suchen. Der Rest muss
untersucht werden (brauche ich egrep überhaupt?)

=item * (H5)

Die Optimierungsparameter des CGIs (textuell) sollten in der
Tk-Version verwendet werden können. Plan: Geschwindigkeitsbasierte
Parameter und die E<quot>textuellenE<quot> Parameter werden getrennt
(entweder eins oder das andere); die Faktoren werden vom CGI
übernommen. Vor dem Aufrufen der Suche muss entweder das eine oder
andere genommen werden. Evtl. Modul schreiben, wo die Parameter für
CGI und Tk-Version ge-sharet werden können (-> make cgidist anpassen?
wird das noch für die SF-Version verwendet? Vielleicht sollte die
SF-Version grundsätzlich alle Module außer Tk/* bekommen?). Manuelle
Tests machen, ob bei beiden das gleiche herauskommt.

=item * (H4)

qualitaet-Einstellungen sollten persistent aus dem Optimierungsdialog
gemacht werden können

=item * (M1)

Konverter vom E<quot>TouratechE<quot>-Format nach bbd schreiben. Beispieldatei:
http://www.arur.de/fileadmin/reisenotizen/reisenotizen_roland/images/berlin-ffo/bl-ffo.xml

=item * (H5)

Besseres Erkennen der Kreuzungssituation in der Straßenliste. Z.B. Bei
Kreuzungen, wo beide Straßen nur einen kleinen Winkel zueinander
haben, sollte immer (auch bei <30°) die Richtung ausgegeben werden.
Bei Situationen wie Falkensteinstr./Oberbaumstr. sollte trotz
Geradeausfahrt die Nebenstraße gekennzeichnet werden (z.B.
E<quot>nicht der Hauptstraße folgenE<quot>). Bei einfachen
Kurvensituationen ohne Kreuzung (Neudecker Weg und Rudower Str.)
braucht keine Richtungsangabe erfolgen. Wenn an so einer Stelle eine
Kreuzung ist, dann kann die Angabe E<quot>Hauptstraße folgenE<quot>
zusätzlich angezeigt werden.

=item * (M4)

Show more fields in route list (just like in web interface)

=item * (H5)

Drucken: if the PDF backend is chosen, then Druckeinstellungen have no
effect -> Remove them in this case! Maybe it would be nice to support
at least some of them (legend, maybe b/w)

=item * (M4)

Aufteilen des Strassen-Menues. Vorschlag:

 Strassen-Layer
  Strasse auswaehlen
  Erweiterte Auswahl (untereinander!)
  Strassenkategorien
  Strassennamen
  Attributierung:
  Radwege + Kategorien (comments_cyclepath geht hier ein)
  Hoehenangaben ?
  Ampeln
  Strassenqualitaet + Kategorien
  Sonstige Beeintraechtigungen + Kategorien ?
  Unbeleuchtete Straßen
  Vorfahrt
  Gruene Wege ?
  Steigungen (comments_mount geht hier ein)
  Kfz-Verkehrsdichte (comments_kfzverkehr)
  Strassenbahnen (comments_tram)
  Routing-Hilfen (comments_path)
  Sonstige Kommentare (comments_misc)

 Andere Wege-Layer
  Radrouten (comments_route)
  Radrouten auswaehlen
  Faehren (comments_ferry geht hier ein)
  Faehren auswaehlen
  Fragezeichen

=item * (H2)

Bug: see t/strassennetz.t

=item * (M3)

Computers are faster nowadays. Make some feature default, e.g.
no_overlap_labels, more layers on startup (flaechen, gewaesser).
Detect computer speed on linux:

    perl -e '($bogomips)=`grep bogomips /proc/cpuinfo` =~ /:\s*([\d\.]+)/; print $bogomips,"\n"'

How to get CPU/hardware speed on other OSes: FreeBSD (sysctl?,
/compat/linux/proc/cpuinfo?), Windows?

E<quot>Optionen für langsame RechnerE<quot>: z.B. E<quot>Überlappungen
vermeidenE<quot> etc.

=item * (H2)

Optimize SRTProgress: only hide canvas if first progress drawing is
necessary (already done, check). Adjust progress drawing to be
specified in time intervals (alternatively). This would reduce the
need of hiding/displaying the canvas in short or empty redraws.

Research for alternative SRTProgress implementation: pre-forked
stand-alone MainWindow, or submit a TIP with a per-widget update (in
Perl/Tk: updateWidget) method.

=item * (H3)

The -lazy option seems to cause a big memory leak. Unless this is
solved for sure there should be no standard-user-visible -lazy option.

=item * (H5) (bug)

-lazy does not work with bbd files using map:polar. I assume that the
grid algorithm is broken wrt to map!=standard.

=item * (M3)

In Routenbeschreibungen Zeilen wie "Straße A", "Straße
A", "Straße A" zu einer Zeile zusammenfassen. Das kann
vorkommen, wenn bei der Route ein Zwischenpunkt verwendet wird.

=item * (M2)

Bessere Routenbeschreibung für Landstraßen (wie? was ist
an der derzeitigen nicht gut genug?). In der Datenbank "X - Y" nach
"(A) - X - V - Y - (B)" ändern, wobei X und Y Start- und Zielort
der Strecke ist, (A) und (B) die globale Richtung
(größere Städte vor und nachher) und V ein Via-Ort
ist. Die geklammerten Orte und V sind optional. Auch alle Straßen, die
bislang nur mit der Straßennummer bezeichnet sind, auch mit
Start/Zielort in der Form E<quot>X9: Start - ZielE<quot> oder
E<quot>Start - Ziel (X9)E<quot> bezeichnen.

=item * (H2)

Möglichst Orte (optional) in die Routenbeschreibung aufnehmen.
Vielleicht mit nearest_... arbeiten. Eine erste Implementation mit
$do_route_strnames_orte, aber was macht diese? Nähe zur Ortschaft
sollte evtl. einstellbar sein. Problem: ich habe keine Ortsgrenzen zur
Verfügung. Anfangen, die Datei orte_flaeche anzulegen (zwischen
sicheren Punkten --- diejenigen, wo ich einen Waypoint am Ortsausgang
gesetzt habe, und interpolierten Punkten unterscheiden)

-> Ich sollte für orte_flaeche OSM-Daten verwenden.

=item * (H2)

Im Umland ist es vielleicht sinnvoller, eine Routenbeschreibung anhand
von Punkten (Ortschaften) anstatt Strecken (Straßen) zu machen.
Optional eins oder beides zusammen.

=item * (M1)

Leichtere Unterstützung für andere Städte/Regionen:

 Wolfram:
 > Koennte man den nicht fuer die anderen Staedte erweitern? Erstmal
 > eine Auswahl an Staedten, die man haben will und dann ein Update/Download?
 
 Das könnte man machen. Die Stadtauswahl müsste auch schon aus dem Netz
 geholt werden, dann datadir für den Update umbiegen und dem User
 Anweisungen geben, wir er das nächste Mal mit den neuen Daten starten
 soll, oder sogar ein Umschalten per GUI ermöglichen.

=item * (M1)

Wie ist der derzeitige Stand mit aktuellen Telefonbuch-CDROMs? Welches
Programm kann diese auslesen (tbb?).

=item * (M1)

Telefonbuch-Datenbank (Name): Die Suche ist suboptimal. Bei der
Suche von häufigen Nachnamen (Müller, Schulze)
wird das Ergebnis begrenzt (200 Namen) und kann mit "Weiter"
fortgesetzt werden.

=item * (M1)

Maushilfe: B4/B5 dokumentieren (nur im Canvas, nicht auf den Buttons
notwendig), Erklärung für B2 anpassen

=item * (H1)

Unlimited Undo?

=item * (M1)

Optionen -auchumland und -nurberlin einführen: damit könnten einige
Variablen wie wasserumland, landstr, orte etc. gesetzt werden.

Aber wahrscheinlich sollte ich besser auf lazyplot setzen?

=item * (H2)

search_route: multiple Start/Zielpunkte (Checkbutton) --- Ausführung
unklar.

=item * (M3)

Mehr einfache Optionen (E<quot>ShortcutsE<quot>) für die Suche:
kürzeste Strecke, schnellste Strecke (in Abhängigkeit von
Wind, Steigung/Gefälle, Straßenoberfläche etc.),

=item * (M1)

Einheitliche Schalter für das interne Caching von Daten (z.B. ob
beim Anklicken von "Ort" die Datei immer neu eingelesen werden soll).

=item * (H1)

Portrait/Landscape-Umschaltung: alle Canvas-Daten aktualisieren. Route
wird z.Zt. nicht gedreht (evtl. auf @coords verzichten und nur
@realcoords verwenden).

=item * (M4)

Vernünftige Options-Eingabe in der GUI. Zwischen
Startup-Optionen (Zeichnen der Straßen/Punkte) und aktuellen
Optionen unterscheiden (teilweise wird das schon gemacht, siehe
E<quot>Layers at StarttimeE<quot>). Damit zusammen hängt eine
Neubearbeitung von Tk::Getopt (Tk::NoNotebook, Klick auf Checkboxen
etc. resultieren *NICHT* in einer sofortigen Aenderungen --- erst nach
E<quot>OkE<quot>, besseren Msgcat-Support (eigene Module dafür?)).

=item * (M1)

choose_ort, S- und U-Bahnen: neben dem Bahnhof die zugehörige(n)
Linien anzeigen

=item * (M1) (bug)

choose_ort, Orte: the E<quot>E<verbar>E<quot> is visible in the list.
Not nice. Easy to replace with a space or so?

=item * (H1) (feature)

choose_ort, Orte: maybe have some other sorting possibilities, e.g. by
category, or by state. In this case the A..Z bar has to be removed,
probably.

=item * (M3)

search net custom: statt automatisch alle Layer zu verwenden sollte
man lieber:

* entweder einen Filedialog erhalten und damit eine bbd-Datei
auswählen

* oder einen Dialog mit allen vorhandenen Layern anzeigen und daraus
beliebig viele (für multistrassen) auswählen

* oder beides

=item * (M3)

Additional layers sollten auch in der Kommandozeile und im config-File
spezifizierbar sein.

=item * (H1)

Server-Mode und Client-Programm: austesten, insbesondere mit KDE, und
dann alle Starts auf bbbikeclient umschreiben. Gucken, wie man sowas
mit Win32 machen könnte. Server-Beispielcode aus
E<quot>Mastering Perl/TkE<quot> verwenden.

=item * (H1)

Kurzhilfe: kann man feststellen, ob man eine 2/3-Tastenmaus hat? Und
wenn es nur eine 2-Tasten-Maus ist, dann existiert vielleicht eine
Emulation fuer die mittlere Taste?

=item * (H2)

Meta-Choose-Dialog, der alle Choose-Dialoge vereinigt. Vielleicht
(eine noch zu schreibende) Tk::SmartListbox verwenden?

=> Existiert als experiment E<quot>Search while typeE<quot> in
SRTShortcuts, mit normaler Listbox.

=item * (M3)

wettermeldung2 mit fork/spawn/threads aufrufen

=item * (H3)

Neue Version von wettermeldung2 schreiben, die SYNOP-Information
verwendet.

=item * (M4)

Wenn während eines WWW-Fetches die Verbindung gekappt wird,
hängt BBBike vollkommen. Gesehen bei Win32. Vielleicht mit
Timeouts arbeiten (kann das LWP?) und häppchenweise holen. Oder
noch besser: fileevent verwenden! ... LWPng kann Event-Handling.
Leider ist das Event-Handling noch inkompatibel mit Tk. Auch für
wettermeldung2 mit LWPng arbeiten. =E<gt> Vielleicht das hochgelobte
POE verwenden.

XXX Stimmt das noch immer, auch mit Http.pm? Unter Unix scheint es gut
zu laufen.

=item * (M1) (feature)

Für das Drucken von Text: evtl. auch Netscape und print-Methode
verwenden (?). Für Unix könnte man eine start netscape, netscape
remote openFile/print-Kombination verwenden. Bei Windows? Evtl. ein
Modul für Netscape schreiben, daß die ganzen remote-Kommandos
verwendet. Hier eine alte Liste:

 %s: usage: OpenURL(url [ , new-window|window-name ] )
 %s: usage: OpenFile(file)
 %s: usage: print([filename])
 %s: usage: SaveAS(file, output-data-type)
 %s: usage: SaveAS(file, [output-data-type])
 %s: usage: mailto(address ...)
 %s: usage: find(string)
 %s: usage: addBookmark(url, title)
 %s: usage: htmlHelp(map-file, id, search-text)

Die neuen Mozillas unterstützen weniger Kommandos. Siehe
L<http://www.mozilla.org/unix/remote.html>. print() ist nicht mehr
dabei, und funktioniert tatsächlich auch nicht mehr mit Seamonkey.
mail() ist relativ uninteressant, weil man anscheinend nur To: angeben
kann, aber weder Subject noch Body.

Mit Xprt für X11 experimentieren (doc lesen).

=item * (H1)

Speicheroptimierung für kleine Systeme.

Ein minimales System kann auf Folgendes verzichten:

    * BikePower::*
    * Devel::Peek::*
    * EasySound::*
    * Karte::Berlinmap1997::*
    * Karte::Berlinmap1999::* und weitere
    * wettermeldung2::*
    * BSD::Resource::*
    * Hyper::*
    * Plugin::*

Evtl. auch:

    * Tk::DragDrop::*
    * Tk::CanvasBalloon::*
    * Tk::ContextHelp::*
    * Tk::Dialog::* (nach STDERR umlenken, wenn nur OK-Button erscheint)
    * Tk::ErrorDialog::* (Default: nach STDERR umlenken)
    * Tk::FireButton::*
    * Tk::SRTProgress::*
    * Tk::UnderlineAll::*

=item * (H2) (feature)

Bike+Ride integrieren. Das würde in eine unterbrochene Route
resultieren, deren Fahrzeiten addiert würden. Zusätzlich
käme noch eine abgeschätzte Zeit für die Benutzung
des Verkehrsmittels (Fahrzeit + Zusteigzeit + Umsteigezeiten). Eine
Verbindung zu Fahrinfo wäre genial.

Vorgehensweise:

=over

=item * automatisch Verknüpfungspunkte Bahnhof-Straßennetz erstellen.
Z.B. exact_streetchooser verwenden, um die nächste Straße zu
ermitteln, und dann mit add_net den Lotpunkt neu erzeugen.

=item * evtl. für pathologische Fälle Verknüpfungspunkte manuell
erstellen

=> Existiert bereits als Datei E<quot>exitsE<quot>.

=item * make_net_cat für die Geschwindigkeit. Faustregel: RB 80-100
km/h (?), U-/S-Bahn anhand von einigen Fahrplänen
Durchschnittsgeschwindigkeiten ermitteln

=item * jeder Verknüpfungspunkt wird mit einer Penalty belegt, die der
Wartezeit ungefähr entspricht.

=item * auch Umsteigemöglichkeiten im Netz mit Penaltys belegen (wie?)

=item * Suche modifizieren: Verabschieden vom Grundsatz gleiche
Koordinate = Verknüpfung? Mitführen der aktuellen Linie (bzw.
Liniengruppe), um Umsteigen zu erkennen.

=back

=item * (H1) (improvement)

GfxConvert evtl. mit Tk::WinPhoto/Tk::Photo-Funktionen implementieren,
wenn die externen Programme nicht verfügbar sind. Am besten
wäre natürlich noch immer ein NetPBM-Modul.

Photo-Zooming: -zoom x -subsample y == -zoom x/y oder umgekehrt

=item * (M1)

Bei -usbahnnetz sollte folgendes gehen: Routenbeschreibung mit Bahnhöfen
statt Strecken (davon kann auch die Routenbeschreibung auf dem flachen
Land profitieren!) ... Und noch schöner: eine Kombination von U/S-Bahn
und Straßennetz (für Fußwege bzw. Bike+Ride).

=item *

Optional eine kürzere Beschreibung. Bei der Tk-Version gibt es das
schon, aber noch nicht beim CGI. Wann wird die Ausgabe endlich
vereinheitlicht?

=item *

bei Windows (oder allgemein: bei ClickToFocus) ist es
unangenehm, dass neue Fenster den Focus klauen. Allerdings ist es ohne
Maus eher angenehm, dass neue Fenster den Focus bekommen. Wie soll man
also verfahren? -> Ich habe Cycle-Windows mit CTRL-TAB implementiert.
Vielleicht reicht das schon?

=item *

user editing: negative/positive präferenzen mit b2/b3 lange druecken
setzen

Vielleicht reicht ein besseres Menü für E<quot>Benutzerdefinierte
SperrungenE<quot>: handicaps fehlen, Einbahnstraßen fehlen.

=item *

bugfix: optmenu in optimierungseinstellungen korrigieren (Fehler beim
Tk Widget) -> schon korrigiert???

=item *

MDI-Interface entwickeln mit:
 * map-widget
 * start/zieleingabe
 * einfaches opt-einstellungs-fenster
 * routenbeschreibung
Siehe Tk::WindowManager =E<gt> entwickle ich nicht mehr weiter,
dafür gibt es aber ein neues Tk::MDI-Widget. Aber: MDI is evil!

=back

=over

=item CDROM-Probleme:

 - tk:underlineall.pm warnings in 111,114,157,178
 - win, print: fehlermeldung nicht auf stdout zeigen. start_cmd wird ohne progexe gestartet, wenn der ps-viewer gestartet weden soll. dito beim browser
 - tk::getopt: pane verwenden. ab 800.015 eh standard
 - optionen besser gruppieren. z.b. audio irgendwo unterbringen
 zwei Reihen mit Notebook?
 - "outline" -> umrandungen
 sonstige anglizismen herausnehmen
 - Bei Win98 geht anscheinend perlglob nicht-> Probleme mit Ncopy
 - unix/kde-installation: statt symlink von /usr/local/bin besser shell-skript mit richtigem perl-path erstellen. wenn /usr/local/bin nicht im PATH, dann evtl. /usr/bin nehmen. wie macht es autoconf bei KDE? kann ich was von autoconf verwenden?
 Env-loesung ist auch OK
 - menuepunkt fuer taste x
 - layereditor hat bei win95 einen absturz verursacht, und zwar beim local drag (NT mit 800.015 selbst compiliert auch? nur bei followmouse?)
 - winddaten eingeben als menuepunkt
 - eigenes popup mit popover nicht fuer win32 verwenden - da ist eh clicktofocus aktiv. Bei KDE auch? Gibt's ne property, die die wm -einstellung anzeigt?
 - set ziel vom str-dialog setzt anscheinend das via-array nicht
 - shift-click vom start aus geht nicht
 - besseres cdrom.pl schreiben. Sowas wie cons, nur fuer das kopieren. Oder mkisofs beibringen, das er die richtigen sachen ohne kopieren erzeugt

=item BBBike - Externalization, towards to v4.0

 Allgemein: Aenderungen nur durchfuehren, wenn sie entweder trivial und unaufwendig sind oder zwingend fuer die anstehenden Portierungen sind.

 - data: neue Verzeichnishierarchie
 Vorschlag: city "_" iso-country-abbrev. Beispiel: berlin_de, muenchen_de, san_francisco_us
 - oder: derzeitige datadir-praxis beibehalten: z.b. data_berlin_de
 - in den Geography-Modulen: Iconleiste (welche Buttons sind ueberhaupt definiert? Welche zugehoerigen Menues?)
 - Iconleiste wird stadtspezifisch erzeugt (e.g. Gibt es U-/S-Bahnen?)
 - Iconbilder werden stadt/landtpezifisch benannt. Beispiel: ubahn.gif => ubahn_de.gif
 - Umland ja/nein. 3-stufig (mit jwd?), "Haltestelle" oder "Haltestelle/Ort"?
 - Aufgeben des manuellen Landstraßenzeichnens (und jwd etc.)
 - generell: vielleicht ein gesondertes sub symbolframe für jeden Ort?
 - oder: XML-Beschreibungsdatei für die Properties?
 - automatisches Erstellen der Properties in Geography.pm anhand der existierenden data-Dateien
 - Ampeln sind vielleicht nicht überall erfasst
 - winddaten können vielleicht nicht überall über das web geholt werden
 - Straßen: nicht alle Daten sind überall erfasst (Kategorien, Radwege, Qualität, ...)
 - Straßenauswahl: PLZ-Liste, CDROM?
 - etc. So gut wie alle daten können vorhanden sein oder nicht
 - transpose-Funktion ist ortabhängig, BBBikeTranspose als Verteiler
 - map-button sollte berlin-spezialität bleiben
 - check-skript: sind alle benötigten Variablen definiert (in den Geography-Modulen)
 - einige devel-skripte sind auch ortabhängig
 - vielleicht Erstellung eines devel-Verzeichnisses mit nötigen skripten aus miscsrc und vielleicht misc. Insbesondere kritische Sachen wie den eplus-Roboter herausnehmen
 - verkleinerung für overview-mode sollte einstellbar sein
 - anhand von $0 erkennen, welcher Ort verwendet eerden soll. Gut für CDROM-Installationen
 - edit vs. normal mode: bei anderen städten keinen unterschied machen (transpose entsprechend setzen) oder gps-koordinaten im edit-mode verwenden
 - CGI: imagedir ortsunabhängig machen
 - caches ortsunabhängig machen

=item Bookmarks

Bookmarks in choose_ort und möglichkeit, per dnd neue bookmarks zu definieren, um als straßenauswahl dienen zu können

=item weiter:

 - bei Http.pm vielleicht IO::Select::can_read/write verwenden
 - bbbike.cgi: Installation auf rapidsite testen => automatisierten Test a la wap_test schreiben, gleiche Features erkennen und verallgemeinern
 - BBBike: feinere Aufteilung der Gegenwind- etc. Strecken (fließend von rot bis grün)
 - BBBike: "Window intelligent positionieren" implementieren

 - BrowserInfo.pm: von Roxen's SUPPORT lernen:
 SUPPORTS: font tables cookies javascript backgrounds backgrounds autogunzip netscape_javascript tablecolor ssl frames mailto forms images pull push java imagealign gifinline pjpeginline fontcolor some_html3 jpeginline

 - bbbike/c: neues pmake funktioniert unter Suse nicht =>
 gmake benutzen? grrr...

 - Verwendung von Tk::App::Reloader. Scheint allgemein zu funktionieren.

=item Fahrbahnbeschaffenheit

  Aus der Radzeit 3/2001, Seite 8-9:
  Radwege: Verbundsteine kontra Asphalt
  [...]
  Der Energieverbrauch beim Rad fahren (durchschnittliche
  Geschwindigkeit 15 km/h) auf Asphalt in Straßenqualität
  beträgt ca. 1000 Joule und auf Kopfsteinpflaster ca. 2200
  Joule jeweils pro 100 Meter. Bei asphaltierten Radwegen mit
  schlechter Längsebenheit liegt dieser Wert zwischen 1200 bis
  1400 Joule, bei neu gebauten Radwegen mit gefasten Verbundsteinen
  bei ca. 1400 Joule und bei wassergebundenen Decken zwischen 1600 und
  2000 Joule pro 100 Meter. Da der Einsatzbereich des Fahhrades als
  Verkehrsmittel umgekehrt proportional zum Quadrat des
  Energieverbrauchs ist, ist dieser bei Radverkehrsanlagen in guter
  Straßenqualität rund doppelt so groß wie bei
  Radwegen mit Betonverbundsteinen und etwa viermal so groß wie
  bei wassergebundenen Radwegen. Quelle: UPI-bericht Nr. 41, 3. erw.
  Auflage August 1999 E<quot>Entwicklung und potentiale des
  Fahrrad-VerkehrsE<quot> Seiten 18 bis 20

  URL: L<http://www.upi-institut.de/upi41.htm>

=item Verkehrsverwaltung

  Verkehrs-/Umweltverwaltung wegen Emissionen:
  Reulenbäcker
  IX D2
  Tel: 9025 2391
  Raum 8.020
  Brückenstr. Mitte

=item weiter

 - Farbeditor: background setzen sollte vielleicht Canvas-bg ignorieren bzw. eigener Auswahlpunkt für Canvas-bg. Vielleicht *alle* Farben änderbar machen --- aber dann muss man die Änderungen auch abspeichern können (schwer, unwichtig)

 - Straßennamen: zeichnen on demand? besserer Algorithmus? TIP mit -angle ausprobieren? (schwer)

 - intelligenterer Markieralgorithmus: nicht Zentrieren, sondern nur verschieben, falls: durch andere Fenster verdeckt (nur eigene Toplevels beachten) oder weniger als 10% (5%) oder .... Pixel vom Rand oder einem anderen Toplevel entfernt. In diesem Fall den Ausschnitt auch nur minimal verschieben, bis sichtbar (schwer)

 - Idee von effizienten Loop/Callback-Mechanismus: ein callback kann entweder alleine aufgerufen werden (mit nötiger Initialisation + Cleanup) oder in eine beliebige Loop eingebettet werden (Inline, Initialisation + Cleanup außerhalb der Loop). Beliebig viele Callbacks können kombiniert werden (Stacking). Verwendung von B::Deparse? (sehr schwer, API und Ausführung erst einmal ausdenken)

 - Bug: beim Umschalten von einem anderen Mode in den Suchmode muss zuerst einmal ein Reset ausgeführt werden, bevor Start gesetzt werden kann (mittel)

 - Start/Ziel löschbar machen (mittel)

 - Optimierung bei vias löschen/verschieben/einfügen: nur geändertes Stück berechnen (delete=strecke vor-nach; move=beide strecken vor/nach; insert: neue zwei strecken) (mittel-schwer, nur, wenn ich das via-feature häufiger nutze)

 - bbbike.cgi: kommentar-spalte: bei münchen schiebestrecken ausweisen, evtl. auch radwege. in berlin vielleicht alles mögliche ausgeben --- ausprobieren

=item Straßennetz, Suche

Die build-Funktion könnte viel einfacher gestaltet werden, da if
(const) { } von perl optimiert wird. Die Vorgehensweise wäre
also:

    eval q{
        sub CONST () { $const }
        ...
        A*-Code
    }

Leider gibt es mandatory redefine warnings, die vielleicht mit einer
STDERR-Umleitung unsichtbar gemacht werden können. Allerdings
--- eine Analyse mit B::Terse zeigt, dass nach der Optimierung
zusätzliche enter/leave opcodes im Tree geblieben sind. (Das
wäre eine Idee für optimize::...: überflüssige
enter/leave überspringen, wenn in einem Block keine padsv (my)
oder LVINTRO (local) vorkommen sowie der Block in einem void-Kontext
steht.)

=item Vernünftige Koordinaten verwenden

Wahrscheinlich ist GKK (für Deutschland) die beste Wahl. => Nein,
polare Koordinaten mit Datum=WGS84, um mit der gesamten restlichen
Welt kompatibel zu sein.

Mit dem Mapsource-Programm und/oder gpsman folgendes testen:

  * 1km entspricht wieviel Längengrad in Usedom, Prenzlau,
    Berlin, Dessau, Dresden?

  * Das gleiche mit Karte::Polar ausrechnen

  * Zur Sicherheit auch Breitengradabstände berechnen.

  * Range von GKK feststellen (in Mapsource einstellen, falls
    möglich, ansonsten mit dem eTrex). Wo gelten die Zonen, was
    für Einschränkungen hätte ich?

  * Umrechnung GKK - Karte::Standard - Karte::Berlinmap1966 - Karte::GISmap.

  * -orig-Dateien =E<gt> GKK, konvertierte Dateien =E<gt> einfach auf
    0/0 subtrahiert (ähnlich wie in München)?
    Hmmm. Wahrscheinlich ist es sogar besser, wenn die -orig-Dateien
    auf polare Koordinaten basieren --- wegen der verschiedenen Zonen.
    Beim Konvertieren wird eine Zone als E<quot>HauptzoneE<quot>
    angenommen und die gesamte Karte dagegen konvertiert (die
    Ränder sind dann verzerrt). Da mitten durch Berlin eine
    GKK-Zone verläuft, sollte ich vielleicht eine Pseudo-Zone
    4.5 verwenden (Aufruf von Karte::UTM::ConvToTm mit dem Berliner
    Längengrad als lat0 z.B.). Wie sieht es mit der
    Konvertierungsfunktion DegreesToGKK aus?

  * Liste aller von den derzeitigen Koordinaten abhängigen
    Dateien erstellen

  * Wenn die GKK-Konvertierung in Perl zu langsam läuft:
    XS-Modul schreiben. Tests sind einfach (Perl-Ausgabe gegen
    XS-Ausgabe checken)

  * Welches Datum verwenden: Potsdam oder WGS84?

  * Alle abgespeicherten Dateien sollten besser Degrees sein! Also
    .bbr und evtl. esri und so. Auch wenn möglich: die
    sichtbaren Koordinaten im cgi sollten auch Degrees sein.

  * Evtl. alle data/*-Dateien nach .bbd umbenennen und am Anfang einen
    Header einfügen (Datum, Koordinatenformat etc.)
    Entsprechende orig-Dateien heißen .orig.bbd oder .bbd.orig.
    In der Zwischenzeit mit beiden Systemen gleichzeitig arbeiten
    (Konvertierung im Makefile)

  * DegreesToNZGrid sieht interessant aus --- das brauche ich: x und y
    und keine Zonen. Implementieren, angucken!

  * Was ist mit dem Koordinatensystem ETRS 89?

=item *

Falls ich auf WGS84 umsteige, sollte ich vielleicht auch
Math::Trig::great_circle_distance als XS-Funktion umschreiben (obwohl,
das sieht so einfach aus, da wird die C-Implementierung nicht viel
schneller sein können).

=item Niederschlagsprognosen:

  http://puma.dkrz.de/theomet/prognosen/
  http://puma.dkrz.de/theomet/prognosen/bilder/colorpop6.jpg
  http://puma.dkrz.de/theomet/prognosen/bilder/colorpop6_12.jpg

  Kommerzielles Programm: http://www.einfalt.de/x_rad_vorher.html

=item Volltextsuchfunktion in bbbike erweitern: agrep mit fester
  Fehleranzahl, automatische Operation mit schrittweiser
  Erhöhung der Fehleranzahl

=item Volltextsuchfunktion: itemconfigure und normal/bold oder
black/grey verwenden, um Kategorisierung darzustellen (größere Orte,
wichtigere Straßen)

=item Eine Kreuzung:

  Verzögerung durch Vorfahrtsberechtigungen: Ampel, Bahnübergang,
  Vorfahrt, Vorfahrt gewähren, rechts-vor-links; Abbiegevorgänge

  Verzögerung durch Richtungsänderungen: geradeaus, rechts/links

=item ??? make some data controlled persistent

  * mapping full path => data structure
  * check modtime
  list: strassen, landstrassen, Berlin.coords.data,
        Potsdam.coords.data ???

=item dillo 0.7.x ist schon richtig gut

--- kann imagemaps und tabellen, für ipaq besorgen und dann endlich
die alternative zu bbbike impl.! => auf skiffcluster compilieren

=item gpsman2bbd Parameteruebergabe ueberarbeiten

=item Tk::LayerEditor

in einer nicht-DND-Version (für Windows,
optional auch für X11, notwendig fuer Tk804) -> fix for TK804 ist leicht, einfach

     my($x, $y) = ($_[3], $_[4]);#XXXchanged for Tk804

in LayerEditorCore::Drop verwenden

=item * (H3)

Entweder nur einen LayerEditor erlauben oder Aenderungen in einem
LayerEditor in alle anderen propagieren. Ausserdem: jeder Aufruf von
plot* sollte alle LayerEditoren aktualisieren

LayerEditor koennte weitere Spalten mit Funktionen enthalten, z.B.
hidden/visible setzen vs. ganz loeschen, Reload, Ausschnitt anpassen,
Strassenliste zeigen.

LayerEditor bug: es wird special_raise nur auf alle vom LayerEditor
verwalteten Layer gemacht. Dadurch wird die stacking order von
nicht-verwalteten Layern kaputt gemacht.

=item * (M3)

Rewrite BBBikePersonal to a real object-oriented module: preserve
widgets when do any actions, immediately show changes (plot, hlist)
when editing.

=item Preferences:
  - Stellung des Kopfsteinpflaster-/Ampelzeit-Buttons (nicht so wichtig)
  - evtl. die Möglichkeit des Rücksetzens (nicht so wichtig)

=item Inline modules => XS modules (less hassle with dependencies,
faster compilation)

=item Rename Kurvenpunkte => ... to AllPoints => ... in all scripts
and modules.

=item Turn all comments in Strassen/*.pm into Pod.

=item Waypoint+ besorgen. geht der export ueberhaupt? gibt es extensions?
geht ein import? -> export geht (txt only), import geht nicht (binary!), will ich
auch nicht implementieren
=> Programm ist downgeloaded und in distfiles/windows, install and check

=back

  * E3 make test unter Windows/cygwin ausführen

  * M3 make ext unter cygwin machen => habe ich Inline installiert?

  * evtl. overview-fenster so positionieren, dass die canvas-scrollbars nicht
    verdeckt sind

  * alle skripte/module, die zum abspeichern als ESRI notwendig sind,
    einbinden

  * es ist nur ein einziges Upload auf den Garmin unter Win moeglich. Wird ein
    FH evtl. nicht geschlossen? perl-gps-Problem oder bbbike-Problem?
    -> Lösung ist in Sicht, ich muss nur auf Win testen!

  * Tk::Getopt-Optimierung: withdraw before showing (long)help window

  CHECK AGAIN:

  * M1 ->postscript is slow (sieperl). Warn before calling any export
    and print function? COMBINED WITH:
  * M1 PNG-Export: first check for all dependencies, then try to export
    (change in GfxConvert needed). Das ist jetzt haesslich: ps-export braucht
    jahre und dann merkt man, dass es doch nicht geht

  * E3 Print OK? (ps vs. pdf backend and automatic recognition)

  * H1 very low prio: Research Tk::Balloon: kann ich Tk::CanvasBalloon durch
  Tk::Balloon *effizient* ersetzen?

  * M1 TelbuchDBApprox: wenn eine genaue hausnummer nicht gefunden wurde,
  dann in der naehe suchen!

  inaccessible_strassen, look at:
     fix_coords in bbbike.cgi
     all_crossings and similar functions
     introduce also in perl/tk version
  [???]

[Ab hier wieder geordnet:]

=over

=item * (M1)

Remove SRT Algo (bbbike menu, StrassenNetz.pm ...)

=item * (M2)

enter_opt_preferences, Straßenqualität: additional select box like in
bbbike.cgi (Kopfsteinpflaster vermeiden, rennradtauglich, Custom).

=item * (M2)

Drucken: optional auch die Routenansicht/PDF drucken, mit/ohne
Routenbeschreibung.

=item * (M2)

PDF-Routenbeschreibung: zusichern, dass die Spaltenbreite nicht zu
groß wird. Beispielsweise bei langen Dateinamen wie E<quot>Str. des
17. Juni - Tiergarten, Philharmonie ...E<quot> kann es passieren, dass
die Entfernungsspalte rechts herausrutscht.

=item * (M4)

comments_kfzverkehr sollte nicht in E<quot>Aktuelle RouteE<quot> (und
wahrscheinlich nicht in show_info) vorkommen, da viele Einträge ohne
vernünftigen Namen existieren. Mögliches Problem:
$comments_net/_get_comments_obj braucht vielleicht an einigen Stellen
comments_kfzverkehr, an anderen nicht.

=item * (M2)

power and speed settings: allow to E<quot>chainE<quot> power settings
to speed settings; or let the user set the power settings
(distinguishing both needs option support). In the first case, if
changing parameters in the BikePower interface and clicking
E<quot>ApplyE<quot>, then the power should be recalculated in the
applyhook.

=item * (M2)

BikePower: if some variable bikepower settings like steigung or
gegenwind are set, then these are used in the initial calculation of
the chained power values, which seems wrong.

=item * (M1) (feature)

Support for the imview image viewer (imview.sf.net). Unfortunately
every download seems to be corrupted?!

=item * (H1)

Why is selecting one of the last characters in the streets chooser
significantly slower (approx. 4s vs 1s) than a similar test with
Tk-SREZIC/examples/k2listbox.pl? (Seems to be not reproducible with my
new machine)

=item * (M1)

Eine Möglichkeit schaffen, auch im overview-Fenster Strecken zu
zeichnen. In der Zwischenzeit geht es manuell mit ptksh>

    plotstr("L100", Canvas => $overview_canvas, -filename => "$FindBin::RealBin/misc/abdeckung.bbd")

Das gibt es schon (im Devel-Mode für Strecken), hat aber noch eine
Defizite; in BBBikeAdvanced.pm bei draw_layer_in_overview()
nachschauen.

=item * (H4)

Bahnlinien wie in Deutschland (Europa?) üblich zeichnen. Das könnte
man mit drei Linien schaffen:

    $c->createLine($c->get_corners,-width=>6,-fill=>"black");
    $c->createLine($c->get_corners,-width=>4,-fill=>"white");
    $c->createLine($c->get_corners,-width=>4,-fill=>"black",-dash=>"-");

Reales Beispiel: dreimal die Ebene R-Bahn laden und dann folgendes
ausführen:

    $c->itemconfigure("L3",-width=>6,-fill=>"black");
    $c->itemconfigure("L4",-width=>4,-fill=>"white");
    $c->itemconfigure("L5",-width=>4,-fill=>"black",-dash=>"-");
    $tag_group{"newbahn"}=[qw(L3 L4 L5)];

special_raise/lower_taggroup kann verwendet werden. Um Bahnlinien im
Bau oder im Tunnel zu zeichnen, kann man folgendes nehmen:

    $c->itemconfigure("L5",-dash=>[1,16])

=item * (H3) (improvement)

A better configuration system. Low-level configuration variables
(which directly map to states in the program, i.e. are variables
there), composite configuration variables (e.g. a profile
E<quot>RennradE<quot>, which sets a number of lower-level
configuration variables), and the possibility to nest composite
configuration variables. Define some good predefines: Rennrad,
Mountainbike, Trekkingrad, gemütliches Fahren (Spazierenfahren),
normales Fahren, schnelles Fahren, mit Anhänger, mit Kindersitz,
E<quot>kindergeeignetE<quot> (whatever this means) etc.

Furthermore, configuration variables should go into a category system
with categories like map display (could control the visible layers and
lazyness of drawing), supplemental display (e.g. overview map),
routing preferences (with subcategories street category, quality,
handicap, cyclepath, bikepower preferences, maybe weather etc.), route
presentation preferences (should the route list pop up or not, how to
display the route (which could also go to the map display)), gps
device config, GUI level in terms of sophistication (which knobs are
actually there? how many files to remember in E<quot>last usedE<quot>
menus?), dataset-related configurations (e.g. the San Francisco map
does not have the S-Bahn-Layer, or generally OSM-generated layers do
not have the landstrassen layer and do not distinguish between city
and outer city data), ...

=item * (H2) (improvement)

Fahrradfreundliche Zugänge, die nur für einzelne Bahnsteige gelten,
mit entsprechenden Pfeilen kennzeichnen. Dazu muss nach heutigen Stand
der Technik eine weitere Datei [usr]bahnhof_bg2 angelegt werden,
welche per plotstr gezeichnet wird und nur kurze Pfeile enthält
(line_shorten_end). Besser wäre es, wenn die Datei [usr]bahnhof_bg
beides enthalten könnte.

=item * (H4) (improvement)

plotstr/plotpoint: Should have $want_... variables which are
associated with the checkboxes to turn layer on, and subs (e.g. called
want_plot_....) which call plotstr/plotpoint in a
E<quot>transactionalE<quot> way and reset the $want_... variable if
something was not successful.

(Was already in this TODO list with a different description:)

Umbau der plot*-Funktionen, damit $str_draw{...} etc. nicht sowohl für
den Status (ist der Layer an?) und auch den Wunsch (möchte man den
Layer einschalten?) verwendet wird. Außerdem gibt es ein Problem bei
normal canvas vs. $overview_canvas, aber nur einen Satz an
$str_draw{...}-Variablen.

=back

=head2 Kartendarstellung

=over

=item * (H3) (improvement)

balloon_info_from_all_tags should also deal with E<quot>pointE<quot>
values (Haltestellen, Einbahnstraßen...). Then enterpoint could be
replaced by an universal enterstr. Also, enterroute should be probably
replaced by an extended enterstr.

Related: do I then still need the distinction between Ort/Bahnhof and
Straße/Strecke? But this is useful to quickly get to the chooser
(although I think this is not known to the public, and I also do not
use this functionality at all)

=item * (M1) (feature)

Mehrere Eingabemodi anbieten, z.B. E<quot>BBBike ClassicE<quot>,
Google, GoYellow, Merkaartor.

 BBBike Classic: <1> setzen von routenpunkten
                 <Motion-2> scanning
                 <3> popup-menu
		 <cursor>: scrolling mit einer geschwindigkeit
		 <pg up/down, pos1/end>: seitenweise scrollen
		 <+>/<->: zooming

 Google:         <1> original: zusatzinformationen anzeigen (?), bei
		     bbbike weiterhin routenpunkte setzen
                 <Motion-1> dragging
		 <2> unbelegt (Browser)
		 <3> unbelegt
		 <Cursor>: scrolling mit zwei geschwindigkeiten
		 <pg up/down, pos1/end>: seitenweise scrollen
		 <+>/<->: zooming
		 <wheel up>: zoom in and keep pos under mouse
		 <wheel down>: zoom out and keep pos under mouse
		 <double-1>: zoom in and center
		 <double-3>: zoom out

 GoYellow:	 <1> zoom in and center
		 <3> zoom out and center
	 	 <Shift-1> dito
		 <motion-1> dragging
		 <enter> zusatzinformationen
		 <pg up>: zoom out, center kept
		 <pg down>: zoom in, center kept
		 <cursor>: scrolling mit einer geschwindigkeit

 Merkaartor:     <wheel up>: zoom in and keep pos under mouse
		 <wheel down>: zoom out and keep pos under mouse
                 <1>: select object
                 <Motion-2>: dragging
                 <3>: select region for zooming
 (or fix Merkaartor?)

Nachdem ich Motion-1 per default für Dragging eingestellt habe und es
sich OK anfühlt, ist die Implementation der unterschiedlichen
Eingabemodi nicht mehr so wichtig.

=item * (H2)

There's no (easy) way to draw only outlined polygons from custom bbd
files. (Maybe it can be done with category_stipple.cat:
Tk/trans_cur.xbm and some outline directive?) (Frage: wo wird so etwas
benötigt?)

=item * (H2)

If E<quot>Namen zeichnenE<quot> is turned on in custom street draw and
filled areas are drawn, then it's visible that the labels are not
above the are layer. Will probably be fixed if all labels are drawn in
an own layer (quite on the top), which will also get a nice label
positioning algorithm.

=item * (M2)

Straßennummerierungsschilder (+ Font) werden nicht korrekt gezoomt.

=item * (M4)

Überlappende (gleiche) Straßennummern sollten gar nicht erst gezeichnet
werden.

=item * (M2)

Create nice anti-aliased and alpha-using PNG images and use it if
possible for icons/symbols etc.

=item * (H3)

insert/delete etc. functionality: add an easy way to use custom layers

=item * (H1)

Unterstützung für E<quot>Persönliche WegeE<quot> (oder
user-defined layers). Zwei Typen: routingfähig (automatisch per
E<quot>add...E<quot> in das Straßennetz eingebunden) oder
nicht-routingfähig. Editiermöglichkeiten für diesen Layer
(mit Verwendung von datachange.log). Möglichkeit der
Veröffentlichung. -> Niedrige Prio, da theoretisch schon machbar,
auch wenn nicht ganz komfortabel: edit-Funktion funktioniert für
eigene Layer, add custom und custom existiert für das Suchnetz

=item * (H3)

Neue Symbole (basierend auf E<quot>>E<quot>) für Steigungen verwenden:

 > (gepunktet): 1-3%
 > (solid): 3-7%
 >>: über 7%
 > (grau): Steigung ohne Prozentangabe

=item * (M3)

no_overlap feature: is it more efficient to implement this feature
with the current mechanism (using Tk::Canvas' bounding box and
overlapping methods) or do it without Tk?

=item * (H1)

Hausnummern. Für wichtige lange Straßen erfassen. In der
Kreuzungsliste beim CGI dann neben den Straßennamen anzeigen. Wie in
der Perl/Tk-Karte darstellen? Vielleicht nur bei kleinen Massstaeben?

=> Ich sollte für die Hausnummern OSM-Daten verwenden.

=item * (H2)

Dynamisches Zeichnen (weniger/mehr) von Kartenelementen anhand der
Vergrößerung (wird teilweise schon gemacht, z.B. bei
get_symbol oder Orte/Kategorien=Auto, was fehlt noch?).

Beim Zeichnen von Orten muss das Problem des Abstand zwischen Punkt
und Label geloest werden --- bislang wird der Abstand beim
Vergroessern zu gross und beim Verkleinern zu klein. Ideal waere
natuerlich ein eigener Canvastyp (Composite-Item)

Mittlerweile ist das Problem Punkt-Label bei Orten gelöst für den
Modus E<quot>überlappendE<quot>.

=item * (M2)

Oben/normal/unten: Reihenfolge: RB oder S, dann RB-Bhf oder S-Bhf, und
nicht RB, RB-Bhf, S, S-Bhf wie bislang.

=item * (M2)

Evtl für BBBike-Canvas und Übersichtskarte: Maus ziehen zum
Einstellen eines Ausschnitts. Das Rechteck, das beim Ziehen erzeugt
wird, muss natuerlich den Aspect des Hauptfensters beibehalten.

<Motion> ist bei der Übersichtskarte schon belegt. Trotzdem
umdefinieren? Oder nur die Ecken des Rechtecks zum Ziehen verwenden?

=item * (H3)

Straßennamen: Labels wie in richtigen Stadtplänen
anordnen, also z.B. "Yorckstr.": am Anfang der Straße "Yorck-",
am Ende der Straße "str.". Dadurch werden die Namen hoffentlich
lesbarer sein.

Der Code dazu existiert schon, ist aber langsam und buggy und wird nur
bei bbbike.cgi verwendet.

=item * (H3)

Da das Zeichnen von Straßennamen so lange dauert: mit Hints
arbeiten (z.B. für einige oft verwendete Zoomstufen Koordinaten
und Transformationsmatrizen vorberechnen).

=> not needed, drawing street labels in lazy mode should be fast
enough, see the street name experiment in SRTShortcuts.

=item * (H2)

Beim Vergrößern könnte man ab einer bestimmten
Stufe auch die Größe der Straßen/Ortslabel auch
mitvergrößern.

=> Für Straßen: bereits exemplarisch implementiert, siehe
real_street_width-Experiment in SRTShortcuts.

=item * (H3)

Rotierte Fonts: vielleicht ein Freetype-Modul schreiben, dafür
eine Tk::Canvas-Erweiterung und diese in BBBike verwenden?

Besser: man kann bereits jetzt rotierte TTF-Fonts verwenden:

    perl -MTk -e 'tkinit->Label(-text => "hello, world!")->pack;MainLoop' -- -font 'serif:matrix=1 .1 0.2 1 122'

=> Wird bereits im street name experiment verwendet.

=item * (M1)

Vergrößerung der Schrift beim Zoomen

=item * (M1)

Beim pp-Symbol wird beim Zoomen vergrößert; beim Neuzeichnen wird aber
die kleinste Vergrößerungsstufe wieder genommen.

=item * (H1)

Optimierung: Beim Ausschalten von Outline oder Straßennamen
muß nicht alles neu gezeichnet werden.

=item * (H1) (feature)

3D-Darstellung von Berlin (z.B. vier versetzte Flächen, die
oberste in der Hintergrundfarbe und die anderen in der Schattenfarbe).

Z<>=> Wo verwenden: overview-Fenster, overview-Button oder im CanvasMap
anstelle der normalen Grenzen?

=item * (H3)

outline_text bei draw_text_intelligent verwenden (maybe already
implemented? check!)

=item * (M4)

draw_text_intelligent should use the bbox of the central object
if xaddanchor/yaddanchor is not defined

=item * (H4)

Beim intelligenten Zeichen von Ortsnamen bietet sich ein
Scanline-Vorgang von rechts nach links an. Somit vermeidet man Sachen
wie
        Slubice *
	      * Frankfurt

Schwierig, wenn gleichzeitig das Ergebnis aus sortbycat beachtet
werden soll (Multipass? Langsam! Wie macht es Mapserver? Kann ich das
auch mit Geo::SpaceManager machen, siehe BBBikeDraw::PDF?)

Vielleicht auch Andreas' Labeling-Algorithmus verwenden

=item * (H3)

Bei der Ausgabe der Straßennamen an der Route sollte ein aehnlich
intelligentes Verfahren angewendet werden. Vielleicht kann bei Routen,
die von W nach O verlaufen, die Strassennamen erstmal links vom Punkt
eingezeichnet werden und umgekehrt.

=item *

Splines verwenden?

Z.B. in den Daten so markieren: x,y S x,y ... Falls ein Spline
auftritt, wird der gesamte Linienzug mitsamt Outline als -smooth => 1
markiert und für nicht spline-Abschnitte werden die Koordinaten
gemaess der Tk::Canvas-Doku dupliziert. Kreuzungen müssen exakt sein
(also darf ein Kreuzungspunkt nicht zwei S-Nachbarn haben! =>
Konsistenzcheck möglich). Mögliches Problem: können alle Tools mit
Extra-Daten zwischen den Koordinaten umgehen? Und: wie sieht die API
dazu aus (z.B. $street->getattr($data_pos, $coord_pos) und
$street->getallattr($data_pos)). Splines auch bei der Routensuche
(strecke()) beachten?

=item * (H1)

Ausblenden von Strassentypen/Radwegtypen

sollte besser -state => "hidden" verwenden, wenn moeglich (d.h. recent
Tk). Waere aber eine Semantikaenderung, da zurzeit nicht eingeblendete
strassen auch nicht in der routensuche verwendet werden. Was
eigentlich Quatsch ist.

=item * (H2)

Cycle paths are displaced when zooming. Correct this.

=item * (M3)

Sehenswürdigkeiten: eine neue Kategorie für
E<quot>flächigeE<quot> Sehenswürdigkeiten (z.B. Holländisches Viertel)
einführen, um besseres Stacking zu machen (unterhalb von Straßen).

=item * (H2)

Sehenswürdigkeiten: mehrere Bilder für unterschiedliche Zoomstufen
sollten bereitsgestellt werden können bzw. Zooming on-the-fly. Ich
habe bereits bodemuseum.png und bodemuseum_klein.png.

=item * (M2)

Gewässer: vielleicht sollte kleinere Flüsse/Bäche/Seen immer ohne
Outline dargestellt werden, damit sie nicht so sehr auffallen,
jedenfalls bei großen Maßstäben? (Bei kleinen Seen scheint es nicht so
schlimm zu sein wie bei langen Bächen) Ich sollte nochmal die
Gewässerkategorisierung überarbeiten in punkto Empfehlungen für die
Darstellung (wann wird ausgeblendet, wie werden E<quot>breitereE<quot>
Flüsse gekennzeichnet).

=item * (M2)

Einfärben der Route nach Steigungen.

=back

=head2 Plugins

=over

=item * (M4) (bug)

BBBikeRuler: das neue Leftmouse-Dragging funktioniert nicht mit diesem
Plugin.

=item * (H5)

BBBikePluginLister: Plugin-Argumente sollten angezeigt und editiert
werden können. Vielleicht auch mehr Informationen (Icon, längere
Beschreibung etc.) hereinnehmen.

=item * (M1) (feature)

BBBikeScribble: tell user where the scribble was saved (at least in
status bar). Connect lines in bbd if possible. New feature: mail
scribble to maintainer (newstreet). Dabei aber beachten, dass
tkbabybike noch immer damit umgehen sollte...

=item * (M1)

Vielleicht Windchill-Temperatur zusätzlich anzeigen. See
windchill program in bin/sh or devel. Frage: wie und wo soll die
Temperatur angezeigt werden? Im CGI? In der Perl/Tk-Version als Plugin
oder Standard?

=item * (H1) (feature)

New plugin which links to weather data. First, it would be nice to
automatically find a nearby weather station. One could use the WMO
worldwide station list (e.g.
http://www.wetterzentrale.de/klima/stnlst.html or
http://www.htw-dresden.de/~kleist/wx_stations_ct.html, the latter
a html-ized version, the former a nearly text-only version).

Second, link to archived or current weather data. Archived weather
data are useful in conjunction with saved GPS tracks or geocoded
photos, in which case we have a date to link to. Otherwise use some
current date. Possible sources: wetteronline (web link possible),
local archives.

=back

=head2 Editing

=over

=item * (H3)

Im Edit-Mode auch Direktiven zu Strecken zeigen, soweit sie
interessant sind. Evtl. könnte man einige Direktiven (Aliase) auch im
Normal-Mode zeigen.

=item * (H3)

Edit mode, coloring of pp points: use different coloring for
E<quot>KurvenpunkteE<quot> and crossings, to easier detect errors in
the street net.

The beginnings are made (see pp_color, tags ppkvp and ppcrs etc.), but
one thing is missing: I need a net like $net->{Net}, but without
gesperrt/oneway modifications... It would also be good to have that
net for *all* layers. A simple solution would bei not too hard to
implement, but time- and memory-consuming.

=item * (M4)

Edit mode: if route searching is active and E<quot>insert pointE<quot>
(or insert multiple points) is active, then it seems that the created
middle point is broken (off by pixels, and in float). So warn the user
in this situation to switch route searching off.

(NB: Is this really the case? It does not seem to be the search mode,
but another problem...)

=item * (H4)

Edit-Menu: Weiteren Punkt E<quot>bulk editE<quot> einführen. Damit
kann ein Straße mit allen wichtigen Attributen gesetzt werden.
Zusätzlich für E<quot>Add new toE<quot>-Dialog: Beschränkung der
Kategorien auf die aktuell verwendbaren (also bei
strassen auf HH .. NN, bei landstrassen zusätzlich B, bei qualitaet-*
Q... etc.)

=item * (H3)

Edit-Menu: new feature: prolonge street. From the editing view: click
2nd and 1st point of street and then a series of coordinates to be
added.

-> This can be hacked using the following edit sequence:

   * move line from the old end point to the new end point
   * use "insert multiple" to add all points in between, including the
     old end point

=item * (H3)

Edit-Menu: new feature: split street. From the editing view: click
three neighboring points on the street. The middle one is the split
point.

=item * (H2)

Edit-Menu: new feature: combine streets. From the editing view: click
three points from two streets, where the middle one belongs to both
streets. Check if both streets have the same name and category,
otherwise combining is not possible. But maybe combine nevertheless
and give the user the possibility to choose the combined
name/category.

=item * (H3)

Edit-Menu: new feature: Move multiple points. From the editing view:
select a number of points (e.g. all points of a street or area; or by
selection rectangle; or by clicking on a number of points). Select a
delta by defining a line. Move all points by this delta.

=item * (M2)

Edit-Mode: DEL does not delete the coord list (but Backspace does).

=item * (H3)

Replay datachange.log: alle Änderungen (am/bis einem bestimmten Datum)
werden automatisch aufgenommen. Am besten mit einem Testmodus, der
zuerst alle Dateien aus data/* nach /tmp kopiert und nur dort ändert.
Dann könnte man bbbike mit -datadir aufrufen und testen, oder ein diff
-r machen.

diff wortweise würde wahrscheinlich besser als zeilenweise
funktionieren. Siehe textproc/docdiff oder textproc/dwdiff oder
textproc/wdiff.

=item *

BBBikeEdit: Teile nach BBBikeGPS etc. auslagern => schon gemacht, noch mehr?

=item *

Ampelschaltung.pm und BBBikeEdit.pm erweitern

So, dass die alte Form (misc/ampelschaltung-orig.txt) auch per GUI
editierbar ist. Alternativ herauskriegen, wie ich mir die
Punkt-Kreuzung-Liste zusammenklicken kann (wahrscheinlich einfacher).

=item * (M1)

Überprüfen, ob der Menüpunkt E<quot>GPS-Track bearbeitenE<quot> im
Edit-Modus funktioniert.

=item * (H1)

F8/F9 funktioniert bei fragezeichen im Edit-Mode (manchmal) nicht. Der
Grund ist, dass fragezeichen hier kombiniert aus fragezeichen und
XXX.bbd erzeugt wird. Wenn das Canvas-Item aus XXX.bbd oben liegt,
kann keine entsprechende Datei von click_info in BBBikeEdit.pm
gefunden werden.

Theoretisch kann der Mechanismus intelligenter gemacht werden, indem
der E<quot># sourceE<quot>-Mechanismus benutzt wird und vielleicht
durch Zeilennummern ergänzt wird. Dann kann eindeutig auf die
entsprechende Originaldatei verwiesen wird.

=back

=head2 MacOSX specific

=over

=item * (M5)

Bei E<quot>Schriftart ändernE<quot> erscheint folgende Fehlermeldung:

 Tk::Error: named font "Helvetica -12 bold" doesn't exist at /Library/Perl/5.8.6/darwin-thread-multi-2level/Tk/Submethods.pm line 19.
 Tk callback for font
 Tk::Submethods::__ANON__ at /Library/Perl/5.8.6/darwin-thread-multi-2level/Tk/Submethods.pm line 19
 main::set_fonts at ./bbbike line 18370
 main::change_font at ./bbbike line 18254
 main::__ANON__ at ./bbbike line 3485
 Tk callback for .#menu.#frame#frame#symframe#frame1#menubutton7#menu
 Tk::__ANON__ at /Library/Perl/5.8.6/darwin-thread-multi-2level/Tk.pm line 249
 Tk::Menu::Invoke at /Library/Perl/5.8.6/darwin-thread-multi-2level/Tk/Menu.pm line 532
 <ButtonRelease>
 (command bound to event)

In früheren Versuchen hat es aber funktioniert. Vielleicht liegt es an
der Vorgeschichte (hatte gerade tests.pod durchgespielt)?

=item * (M5)

xfig-Erzeugung scheint nicht zu funktionieren, es wird kein ...fig
erzeugt (aber dafür ...fig-images?)

=item * (M2)

Exportieren > PDF: Funktioniert nicht, aber Ps wird sowieso
automatisch zu Pdf konvertiert, also könnte man die Funktion aus dem
Menü herausnehmen oder einen entsprechenden Dialog anzeigen.

=item * (M2)

Wenn die Routenliste gespeichert wird, bekommt sie keine
E<quot>.txtE<quot>-Extension, sondern bleibt extensionlos. Außerdem
sollte die Routenliste vielleicht mit utf-8 gespeichert werden, da
besser vom Betriebssystem unterstützt? Vielleicht auch unter Unix
und/oder Windows? Vielleicht als Option anbieten?

=item * (H2)

Maybe create a Mac distribution using .dmg disk images? See for
example:

 http://www.stepwise.com/Articles/Technical/2001-03-29.01.html
 http://el-tramo.be/guides/fancy-dmg/
 http://el-tramo.be/files/fancy-dmg/Makefile

-> Wolfram did something. Make it available!

=item * (H1)

Drawing custom category images seems to not work in lazy mode (try:
turn on lazy mode, draw E<quot>misc/zebrastreifenE<quot> as a point
layer).

=item * (H2)

New editor functions: moving whole polygons or regions. Some
implementation suggestions: mark all points to move. Mark another
point which the last marked point would move to and use this delta for
all other points. Or just draw a region boundary, and all points
inside the region would move.

More ideas: copy polygons, rotate polygons.

=back

=head2 Windows specific

=over

=item * (M1)

ShAddRecentDoc geht unter Win98 nicht?

=item * (H1)

Drag'n'drop und open's sollten vielleicht etwas mit .lnk-Dateien unter
Win* anfangen können...

=item * (H4)

USB support for uploading GPS tracks is missing for Windows. (It's
only available for Linux with the special Garmin module; it would be
nice if there was a common solution for other Unices, too)

Possibilities under Windows:

- Interface gpsbabel (but then gpsbabel has to be bundled...)
  -> Already implemented, and seems to work. Bundling is missing, though...
  -> gpsbabel does not have an installer. maybe file an bug report and ask the
     author to use innosetup? -> DONE. There's an unmaintained .iss
     script in the gpsbabel distro. Maybe just use it and do it myself?

- Use Device::USB and try to make it work with LibUsb-Win32
(L<http://sourceforge.net/projects/libusb-win32/>). But I have yet to
get Device::USB working with the garmin...

=item * (M2)

Do I need to use a larger font if user's font settings are different
from Tahoma 8? -> Es existiert eine Liste der noch lesbaren und gut
aussehenden Font/Schriftgrößen-Kombinationen auf einer Win98-Maschine.
Unter Win98 scheint ein Minimumdefault von 10px besser zu sein als
8px, wie derzeit in set_fonts eingestellt.

=item * (M2)

String::Similarity und ggfs. String::Approx in die winbindist
aufnehmen für die approximative Volltextsuche. Leider sind das beides
nicht pure-perl-Module. Diesen Testcase auch in doc/tests.pod
aufnehmen!

=item * (H1)

Die -except-Option von IncBusy sollte auch für die
Nicht-Tk::InputO-Variante implementiert werden.

=item * (M1)

make-target für das Kopieren einer kompletten win-distro auf usb-stick
schreiben.

=item * (M4)

HINWEIS zum Update von Modulen in der sieperl-Distribution (dieses
sollte zu einem Skript oder so werden?):

Am besten, ich update neue Module in ein shadow-Verzeichnis
sieperl-5.6.1-bbbike-$(BBBIKEVER) und lasse winbindistcopy dieses
Verzeichnis zusätzlich kopieren. Bei einer neuen Version würde ich
typischerweise die alte rüberkopieren und vielleicht Updates machen.

Ich muss noch rausfinden, wie ich pure-perl-Module in dieses
Verzeichnis installieren lasse. -> So:

    umask 022; setenv PATCHBINPERLROOT /home/e/eserte/src/binperl/sieperl-5.6.1-bbbike-3.16-DEVEL; perl Makefile.PL INSTALLSITEARCH=$PATCHBINPERLROOT/site/5.6.1/lib INSTALLSITELIB=$PATCHBINPERLROOT/site/5.6.1/lib INSTALLSITEBIN=$PATCHBINPERLROOT/5.6.1/bin INSTALLSITESCRIPT=$PATCHBINPERLROOT/5.6.1/bin INSTALLSITEMAN1DIR=/tmp/IGNORE_man/man1 INSTALLSITEMAN3DIR=/tmp/IGNORE_man/man3

=item * (M1)

Langfristig auf Strawberry Perl umsteigen, sobald ich alle Module aus
Bundle/BBBike_windist.pm erzeugen kann. Und sobald Strawberry Perl mit
Windows Vista funktioniert.

=item * (M5)

Add Tk::Clipboard to @Tk::HList::ISA on Windows (or so). Then it would
be possible to use Control-C for copying the selection. -> Eigentlich ein Task für Tk. Check it!

=item * (E1)

Should $top->focusfollowsmouse be default everywhere?

=item * (H1)

Windows: An activating click should only activate the window but not
doing an action. This should be like in Excel (but unlike Windows
Commander). This sounds like a generell Tk problem (is it maybe solved
with Tk804?).

=item * (M1)

It seems that it is standard on Windows to
have some more spacing between buttons and make related buttons the
equal width (especially in end dialog buttons). I think grid() has
some new? -uniform option to force all widgets in a frame to have
the same width.

=item * (M1)

An example how to programmatically make a screenshot on Windows ---
maybe this can be of use somewhere (using instead of xwd?):
L<http://www.perlmonks.org/index.pl?node_id=355073>

=item * (H4)

Overview-Map: always segfaults under Win98

=item * (M5)

Tk::Icon (see L<http://www.schmuker.de/perl/modules/>) to optionally
display the bbbike icon (avoid transparency problem!) (Windows only).

Auf Windows bundlen und prüfen. Oder ist es nicht mehr notwendig?

=back

=head2 GPS

=over

=item * (M3) (improvement)

Da es unter Windows im Gegensatz zu Unix eigentlich keinen Grund
gibt, eine editierbare Combobox für das GPS-Device anzubieten,
sollte ich das in eine nicht editierbare umwandeln.

=item * (M3) (feature)

GPS-Dialog: show a pre-generated route name. And check if the route
number is useful for something (GPX may handle this, but maybe it's
not worth the hassle i.e. could overwrite existing routes). Currently
the meaningless name E<quot>TRACBACKE<quot> is generated if the route
name is left empty. -> Route::Simplify now generates a route name if
not supplied. Though the created name could be better, and it is also
not shown yet in the route dialog. Question: what about the old name?
Store it for later reuse? Maybe only if the user entered his own name?

=item * (M3) (feature)

Introduce GPS device types for the GPS card in the option editor. This
would set the waypoint number, name length and charset automatically.
A E<quot>customE<quot> setting will still be available to set these
values manually. How to get for the device types? Maybe something like
etrex b/w series, etrex color series, gpsmap etc.

Related: the charset for the etrex color series does not include some
characters like <, > ...

=item *

BBBikeGPS:

Die Graphendarstellung verallgemeinern und verbessern:

  * Es sollte möglich sein, die Graphen beliebig ein- und
    auszuschalten (kein Redraw notwendig)

  * Die Graphen könnten besser gelabelt sein, z.B. mit den
    entsprechenden Straßennamen oder nahe gelegenen Orten/Plätzen.

=back

=head2 Updating

=over

=item * (H5)

Implementiert, aber nicht getestet: Update-Prozess: data/.modified um
eine weitere Spalte für einen MD5-Hash oder so erweitern. Die Prozedur
sieht dann so aus: .modified wird bei jedem Update/Rsync geändert.
Zuerst wird downgeloaded, dann mit Digest::MD5 überprüft (falls nicht
installiert, gibt es eine Fehlermeldung) und die alte Datei ersetzt.
Man könnte noch einen Sanity-Check auf das Format von .modified
machen. Leider handelt es sich bei data/* um ein Sammelsurium von
Dateien, nicht nur .bbd (auch .gif oder .coords.data oder ...)

=item * (H5)

Update-Prozess: falls unter /usr/* installiert, hat der normale User
normalerweise keine Rechte auf das Installieren. Erkennen und
hinweisen, z.B. BBBike als root starten (sudo/super) -> getan, aber
noch nicht getestet. Nice to have: su/sudo/super für die Dauer der
Installation verwenden. Oder in ein privates Verzeichnis installieren
und dieses bevorzugt verwenden.

=item * (H1)

(Rsync und CVS hat Zeit...)

Update über das Internet: rsync-Unterstützung und die
Alternative CVS testen. rsync ist vielleicht nicht so gut, weil ein
rsyncd irgendwo benötigt wird und rsyncd nicht das Sicherste der Welt
ist. CVS wäre besser, noch besser, wenn es eine abgespeckte
Client-Variante in Perl gäbe (VCS-LibCVS scheint auch brauchbar zu
sein), die man ins Windows-distfile dazupacken könnte. CVS ist unter
Unix meist vorhanden.

Vielleicht besser: gibt es eine Apache-Option, um automatisch bei
accept-encoding: gzip mit komprimierten statischen Dateien zu
antworten? Update.pm braucht allerdings auch Unterstützung dafür...

=back

=head2 Internals

=over

=item * (H3) (improvement)

Unification of plot streets and plot points. Eigentlich nicht so
schwierig: alles, was einen Punkt hat, wird wie bei plot_point
gezeichnet, und alles andere wie bei plot_street. Der Teufel steckt
wohl im Detail: am Ende wird ein itemconfigure über alle neu
gezeichneten Elemente gemacht, evtl. muss es hier Unterschiede geben.
Vielleicht gibt es Konflikte bei den Kategorien. Vielleicht reicht es,
wenn man den zu evaluierenden Code ein bisschen zusammenfasst.

=item * (M3) (improvement)

Get rid of Class::Struct. It's only advantage is: it's in the core,
and it does use a 1:1 mapping between method name and hash key (unlike
accessors.pm).

Seek for an alternative, maybe self-written.

=item * (H2)

category_* directives in bbd files have side effects: the global
%category_... is set and not per-file variants. Should be fixed,
probably in reset_free_layer in bbbike.

=item * (H5) (improvement)

Rationalisierung der layer/category-Variablen
(%layer_category_line_width etc.) fortsetzen. Es sollte nur eine Liste
geben, die alle möglichen Variablen enthält. Das Ansprechen sollte
immer gleich sein (layer/category vor layer vor category vor global).
Die Direktiven für bbd-Dateien sollen laut Pod angepasst werden.

=back

=head1 Daten allgemein

Achtung: bei Änderungen am Datenformat muss ich für Nutzer älterer
BBBike-Softwareversionen weiterhin das alte Format für den Update über
das Internet anbieten.

Das gilt schon, wenn anderen Kategorien verwendet werden.

Eine Strategie wäre, für das neue Datenformat die Dateinamen zu ändern
(und langsam von deutsch auf englisch umzuschalten) und eine Zeit lang
beide parallel anzubieten, wobei das alte Datenformat automatisch aus
dem neuen erzeugt wird.

=head2 Kategorien, Attribute

=over

=item * (H4) (improvement)

Move abbreviations and icon specifications into comments_route. This
would obsolete parse_street_type_nr in Geography::* nearly useless
(the functionality can still be there as a fallback solution for
highly dynamic mappings). This would require two new directives (e.g.
E<quot>abbrevE<quot> and E<quot>iconE<quot> or E<quot>imageE<quot>).
Also, the directives needs to be preserved when converting from the
-orig into the real file; and the plot* functions need to deal with
these directives (Performance penalty because a new method
get_directives is called multiple times? What about fast plotters (XS)
or the lazy plotter?)

The new feature could also be used in things like radroute.html or in
the mapserver output.

=item * (H4) (improvement)

Normalize comments in bbd files. For example qualitaet*-orig: we could
introduce abbreviations like +AS (= guter Asphalt) or -KS (schlechtes
Kopfsteinpflaster) or oBT (= mäßiger Beton), which could be
automatically translated into German, but also other languages.
Suggestion: this feature could be mixed with normal comments. Only if
a comment starts with a E<quot>*E<quot>, then an abbreviation is
assumed. The describing street name may still precede the comment.
Examples:

     # old fashioned:
     Dudenstr.: Asphalt	Q0 X,Y...
     Methfesselstr.: mäßiges Kopfsteinpflaster	Q2 X,y...
     Asphalt	Q0 X,Y...

     # new style:
     Dudenstr.: *AS	Q0
     Methfesselstr.: *oKS	Q2 X,y...
     *AS	Q0 X,Y...

Suggested abbreviations:

  adjective (categorization)
    -- sehr schlecht
    -  schlecht
    o  mäßig (maybe E<quot>.E<quot> instead E<quot>oE<quot>?)
    +  gut
    ++ sehr gut
  adjective (better attributization)
    (abbreviations missing)
    uneben, wellig (is here a difference?)
    glatt
    holprig
    fest (Waldweg, Sandweg)
    fein (Schotter)
    grob (Verbundsteinpflaster, Schotter)
    Schlaglöcher
    OK (hmmm....)
    gut befahrbar (is this the same as +=gut?)
    mit einigen/leichten Schäden, schadhaft, schadhaft durch Wurzeln
  substantive:
    AS  Asphalt, asphaltiert
    KS  Kopfsteinpflaster
    KK  Kleinpflaster (Kleinsteinpflaster? Begriff?)
    VS  Verbundsteinpflaster, Verbundsteine
    GW  Gehwegpflaster (typisches Berliner Gehwegpflaster)
    BT  Beton
    PW  Plattenweg (= Betonweg mit unregelmäßig verlegten Platten; what
                      about E<quot>BetonplattenE<quot>?)
    wD  wassergebundene Decke
    PW  Parkweg (was wäre der Unterschied zu wD?)
    SW  Sandweg (also: unbefestigter Weg?)
    FW  Feldweg
    WW  Waldweg
    Sch Schotter

Missing:

  teils ..., teils ...
  Fahrbahn ..., Radweg ..., Gehweg ...
  bei Trockenheit/Regen/... ...
  Moabiter Kissen; gepflasterte Bodenschwellen
  Fahrbahnmitte, Rand
  Sandbanketten (bei schlechtem Kopfsteinpflaster)
  n km/h möglich

Also interesting: convert the existing comments back into the
abbreviations. How many will be left unconverted?

The categorization could go into the category field. So we had in the
-orig files:

    Dudenstr.	Q0::+AS X,Y...
    Methfesselstr.	Q2::oKS X,Y...

which would be translated into the non-orig file (German version):

    Dudenstr.: guter Asphalt	Q0 X,Y...
    Methfesselstr.: mäßiges Kopfsteinpflaster	Q2 X,Y...

This looks better. Categorization to categorization. I could even
think about dropping the describing street names completely.

=item * (H3) (feature)

Introduce new types Roundabout and MiniRoundabout in comments_misc:

  - don't render lined Roundabouts at all (see XXX_prog in comments_misc-orig)
    -> Hmmm, there's
       $str_ignore{"comm-misc"}->{Roundabout} = 1
       but this would falsely ignore the point roundabouts. Maybe I also need something like
       %str_line_ignore and %str_point_ignore??? Or different categories depending on point or line?
  - in routing text, add something like "zweite Straße im
    Kreisverkehr"; but: ignore paths and unshiny streets (e.g. Große Sternallee am Großen Stern)
  - make sure that all existing roundabouts have all crossing streets
    recorded
  - document in edit doc that roundabouts need to have all crossing
    streets recorded

Related the next feature:

=item * (H4) (feature)

It would be nice to have a function situation_at_point which takes a
route and a point and return information like:

  - is it a crossing or a roundabout or nothing of both
  - if a roundabout, which street use to leave
    -> XXX need information about roundabouts, or can I determine this implicitely (closed street?)
  - if a crossing, determine direction of turn (left, right, straight) and angle
    -> algo: if start point equals end point, then assume wenden/umkehren/umdrehen
             if angle is the smallest one of all at crossing, and smaller than HALF_ANGLE, then assume straight
             if angle is not the smallest one, and smaller than HALF_ANGLE, then assume half-left/right
             if angle is smaller than SHARP_ANGLE, then assume left/right
             otherwise assume sharp-left/right
    -> implemented, more checks
  - if in a crossing changing between higher-level street to lower-level, 
    then add extra information (show straights nevertheless)
  - maybe some "priority" of information: points without crossing are
    lowest, points where street name just changes next, crossing with
    straight direction next, turns highest (or so)

  Vorfahrtdetection, algo:
  - if there are only two in the neighbor array: nothing to do!
  - in the neighbor array: if there are exactly two B, or two HH and no B, or two H and no B and no HH, then these constitute the right-of-way relation
  - like above, but exactly one ...: very strange situation, should not happen!
  - like above, but more than two: in Berlin: either an Ampel or Vorfahrt is missing here. Outside Berlin: we don't know it
  - otherwise:
  - if there is two N, then these constitutes the right-of-way relation (over an NN one)
  - if there are more than two N, then links-vor-rechts rules
  - only one N: strange situation, could maybe happen?
  - what about pure NN crossings? tell anything about it?

  Now map the vorfahrt situation to the driving direction:
  - if before-street==vorfahrt street1/2 and after-street==vorfahrt street2/1 -> we have right of way
  - if before-street==vorfahrt and after-street!=vorfahrt -> we are leaving the right-of-way relation (maybe only report if it's a bent one)
  - if before-street!=vorfahrt, but there's some vorfahrt street in the crossing: we need to give way

=item * (H4) (improvement)

Do layer stacking for bridges and tunnels right. Some idea: we need
additional tags <abk>-L<level> to signalize special layer levels. The
normal layer order would be something like (LVL-1=below, LVL0=normal
(typically missing), LVL+1=above):

     "u/r/b-LVL-1" "s/l-LVL-1" "u/r/b" "s/l" "u/r/b-LVL+1" "s/l-LVL+1"

Have to find out where to put outlines, radwege, bahnhoefe and such
into the layer stack.

=item * (H3) (feature)

Combine traffic lights with same cycle times for routing calculations
and display.

=item * (H4) (improvement)

S- und U-Bahnlinien mit den neuen Attributen Em (embankment=Damm, z.B.
U6 nach Tegel) und Cu (cut=Einschnitt, z.B. U nach Krumme Lanke)
versehen. Diese sollten dann dafür verwendet werden, um das Layering
anzupassen. Leider muss man bei U-Bahntunnelstrecken eine Ausnahme
machen: da diese meistens genau unter Straßen verlaufen, würde man bei
einem perfekten Layering nichts von den U-Bahnlinien sehen. Da diese
bereits gestrichelt gezeichnet werden, kann man sie also ausnahmsweise
über den Straßen zeichnen (was bislang schon der Fall ist).

=back

=head2 Radwege und -touren im Netz

=over

=item

Radroutenlogos:

    http://commons.wikimedia.org/wiki/Image:Piktogramm_Mecklenburgischer_Seen-Radweg.JPG
    http://commons.wikimedia.org/wiki/Image:Pictogramm_Ostseek%C3%BCsten-Radweg.jpg

=item * (H3)

Bahntrassenradeln: L<http://www.achim-bartoschek.de/bahn_bb.htm>

 BBN1: ignore
 BBO1: eingepflegt (Qualität vielleicht mit aufnehmen) (hmm, doch nicht eingepflegt,
       oder wurde die Nummerierung geändert?)

Eine große Liste von stillgelegten Bahnstrecken in Deutschland, die
als Radwege umgewidmet wurden. Leider recht wenig Angaben zur
Qualität, außerdem müsste man sich die Streckenführung heraussuchen...

=item * (H3)

GPS-Tracks in BRB: L<http://www.das-rad-ruft.de/Radtouren/index.php?Bundesland=11&id=431&action=Suche>

Bereits eingepflegt: Ahrensfede-Gamegrund-Niederfinow.trk,
Berlin-Bredereiche.trk, Teile von anderen.

=item * (H3)

Radrouten im Raum Potsdam:

(aus L<http://www.werder-havel.de/t2.htm>)

  Route F1
  Potsdam - Caputh - Ferch - Geltow - Pirschheide- Wildpark - Potsdam

  Route F2/2
  Werder - Golm - Nattwerder - Grube - Bornim - Eiche - Wildpark - Werder

  Route F3
  Werder - Phöben - Ketzin - Paretz - Uetz - Marquardt - Grube - Nattwerder - Werder

  Route F3/1
  Die Insel Töplitz

  Route F3/2 und F3/3
  Glindow - Plötzin - Bochow - Groß-Kreutz - Deetz - Schmergow - Krielow - Derwitz - Glindow
  Werder - Kemnitz - Krielow - Schmergow - Phöben - Werder

  Route F3/4
  Glindow - Petzow - Plötzhorn - Glindow

  Route F3/5
  Glindow - Kammerode - Klaistow - Kanin - Busendorf - Glindow

  Route F3/6
  Werder - Werder Inselstadt - Glindow - Plessow - Werder

(Müsste vor Ort recherchiert werden)

=item * (H3)

Der Spreeradweg: L<http://www.spreeradweg.de/>

=item * (H3)

Berlin-Kopenhagen: L<http://www.bike-berlin-copenhagen.com/>

=item * (H3)

Berlin-Usedom: L<http://www.berlin-usedom-radweginfo.de/>

Anfahrtsbeschreibung: L<http://www.teamdochnoch.de/mtb-barnim/MTBB_11.html>

=item * (H3)

Broschuere der Landesregierung Brandenburg:
L<http://www.wirtschaft.brandenburg.de/sixcms/media.php/1312/broschurrad.pdf>

=item * (H3)

Radtouren im Raum Potsdam:
L<http://www.f-monzer-co.de/easteuro/hhklinik.htm>

=item * (H3)

Radfahren - Mobil in Potsdam:
L<http://www.mobil-potsdam.de/radfahren.htm>

=item * (H3)

Radwegkonzept MOL:
L<http://www.maerkisch-oderland.de/landratsamt/bauplanungsamt/Radwege2002.pdf>

=item * (H3)

Allgemein:
L<http://www.berliner-rundfunk.de/cgi-bin/WebObjects/brf.woa/wa/CMSshow/1058650>

=item * (H3)

GPS-Tracks zusammenfassen.

=back

=head2 Fehler, Ergänzungen, ...

=over

=item * (M5)

Reviews: alle bbd-Dateien brauchen Reviews. Konkret:

 * comments_*: CP2, CP etc.-Kategorien sollten in einer Routensuche
   vernünftige Kommentare ergeben. Mit ~/devel/massbbbike.pl kann man
   für eine (gefilterte) bbd-Datei HTML-Resultseiten der jeweiligen
   bbbike.cgi-Suchen anzeigen. Z.B. sollte der Mittelpunkt bei cat=CP;
   im Kommentar textlich gekennzeichnet sein, z.B. E<quot>beim
   Überqueren der A-StraßeE<quot>. Das ist aber *nicht* notwendig,
   wenn man dabei in die Straße einbiegt.

   Siehe auch REVIEW UNTIL HERE in comments_path-orig

=item * (M1)

Neues Sehenswürdigkeit-Bild vom Fernsehturm machen, das jetzige sieht
etwas mickrig aus im Vergleich zu anderen Bildern.

=item * (M1)

Fahrradkarte Charlottenburg-Wilmersdorf besorgen:

Die Fahrradkarte ist zum Preis von einem Euro bei den Bürgerämtern
(Otto-Suhr-Allee 100, Hohenzollerndamm 174-177, Heerstr. 12-14)
sowie beim Fachbereich Vermessung (Rathaus Wilmersdorf, Zi. 4090)
während der Sprechzeiten erhältlich.

=item * (H5)

Potsdam ist größer geworden (Golm, Marquardt ...). Potsdam.coords.data
erweitern, vielleicht auch zwischen den Potsdamer Ortsteilen
unterscheiden? (Ich könnte Andreas Titz' Ansatz nehmen: Potsdam-Golm,
Potsdam-Marquardt etc.)

=item * (E3)

Neue Straßen in Mitte (jetzt und zukünftig):

Lehrter Bahnhof:
Emma-Herwegh-Straße (DONE),
Europaplatz (DONE),
-> Agnes-Zahn-Harnack-Straße 7776,13105 7935,13197,
Ilse-Scheffer-Straße (DONE),
Washingtonplatz (DONE),
Ella-Trebe-Straße (DONE),
Berta-Benz-Straße (DONE),
Katharina-Paulus-Straße (DONE),
Clara-Jaschke-Straße (DONE)

Nordbahnhof, Stettiner CarrE<eacute>:
Julie-Wolfthorn-Straße (DONE),
Caroline-Michaelis-Straße (DONE),
-> Elisabeth-Schwarzhaupt-Platz 9063,14050 9148,13942

Elisabeth-Lüders-Haus, Straße davor:
Adele-Schreiber-Krieger-Straße (DONE)

Moabiter Werder-Nord:
Elisabeth-Abegg-Straße (DONE)

Friedrichswerder-West:
Caroline-von-Humboldt-Weg (DONE)

Luisenstadt:
Paula-Thiede-Ufer (DONE),
Bona-Peiser-Straße (DONE (weg))

=item * (E1)

ÖPNV-News tracken:
L<http://www.oepnv-berlin.de/news/news_aktuell.htm>. Oder:
L<http://www.bahninfo.de>.

=item * (H4)

E<quot>Flughafen SchönefeldE<quot> ist im Web-Interface nicht
erreichbar. Das Problem ist, dass der Flughafen außerhalb des Berliner
Stadtgebietes liegt. Man könnte vielleicht einen Hack für Schönefeld
analog zu potsdam_hack programmieren? Dann bräuchte man aber
eigentlich ein Schönefeld.coords.data --- lieber nicht...

=item * (E1)

Look at it:

aus zwei Artikeln in der aktuellen Bahnzeitung punkt3 habe
ich herausgelesen, dass es ab dem 14. Juni eine neue S-Bahnlinie
S85 gibt, die von Grünau über den Ostring nach Waidmannslust
fahren soll. Sehe ich das richtig, dass diese Linie die erste
Linie nach der Wiedervereinigung ist, die eine bis dahin nicht
gefahrene Trasse nutzt? Die Artikel sind Online unter

<http://www.punkt3.de/p3/Punkt3.nsf/f89cda9362f1398c80256a380044fd3c/e35bb9a0c9febd3cc1256ea0003a35c3?OpenDocument>
<http://www.punkt3.de/p3/Punkt3.nsf/f89cda9362f1398c80256a380044fd3c/110ed361d2a59f1dc1256ea0003790b4?OpenDocument>

nachzulesen.

=item * Vosskanal => Voßkanal?

 neue stuetzpunkte fuer gps_correction_map (entsprechungen in standard-koordinaten suchen)
 N52 46 59.9 E14 02 11.3	Bad Freienwalde B158/B167
 N52 35 49.4 E14 14 17.8	bei Neuhardenberg B167/L36 nach Trebnitz
 N52 48 50.5 E12 45 48.1	Fehrbellin (Knick der L16)
 N53 15 52.1 E13 36 23.6	Boitzenburg (hmmm, reichlich unspezifisch)
 N53 23 36.8 E13 35 04.5	L259/L25 bei Fuerstenwerder (vielleicht anstelle von Boitzenburg)
 N52 53 37.2 E11 45 09.4	Seehausen/Altmark, Kreuzung, richtig!
 N51 21 59.7 E12 44 38.9	Wurzen: B6/S11
 N52 16 52.3 E11 25 22.9	Haldensleben:B245/L24 nach Hundisburg
 N52 31 42.2 E11 26 02.5	B71/B188

 stolpe => stolpe/oder
 hohensaatener wasserstr. eintragen
 H-str. B2 => Stolpe/oder => neukuenkendorf eintragen
 deichstr. ab stolpe richtung sueden
 siehe auch: http://www.grass-net.de/modules.php?name=Content&pa=showpage&pid=16
 Radtouren um bestensee herum: http://www.mediapur.de/foto_rad.html

 Fahrplanaenderungen Dezember 2003 bei RE/RB beachten!

 brunnels mit nicht-leeren NAME suchbar machen

 U-Bahn: Negativliste erstellen, alle Strecke, die nicht enthalten
 sind, sind automatisch als Tunnel markieren. U1 nach Krumme Lanke =
 tunnel. => DONE, wobei ich keine Negativliste verwendet habe, sondern
 alle Tunnelstrecken aufgeführt habe.

 brunnels sollten bei sort_by_cat verwendet werden können,
 insbesondere für BBBikeDraw::GD und ::PDF

 gpsbabel kann zwischen einer großen Anzahl von GPS-Formaten
 konvertieren. Evtl. optional in bbbike integrieren. Siehe auch:
 L<http://gpsbabel.sourceforge.net/>. Evtl. ein Strassen::Gpsbabel
 schreiben, welches alle gpsbabel-unterstützten Formate
 lesen/schreiben könnte.

=item * Waypoints und Tracks im Internet:

=over

=item *

Jede Menge, leider in einem binaeren Format:
L<http://www.grabo.de/gps/index.html>

=item *

Als Test für G7T Version 2, enthält Teil von Berlin-Usedom bis
Biesethal:

L<http://www.berlin-usedom-radweginfo.de/downloadzaehler.php?URL=http://www.berlin-usedom-radweginfo.de/tracks/0u1_BB.zip>

=item *

Alternativroute von Frankfurt/Oder Richtung Norden:
L<http://adfc.jgr.de/alternativradroute/alternativradroute.ovl> und
L<http://adfc.jgr.de/alternativradroute/>

=item *

Radfernwege in Brandenburg:
L<http://www.brandenburg.adfc.de/Tourismus/index.htm>

=item *

Radwege um den Stechlinsee herum:
L<http://www.stechlin.de/aktivitaet.htm>
Radfernwanderweg Berlin - Kopenhagen,
Stechlinsee-Radweg,
Polzow-Radweg

=back

=item * Funktionieren die Aufzüge bei der S-Bahn? Das erfährt man
E<quot>... am Besten bei der Kundenbetreuung 297-4 33 33E<quot>.

=item * Spielpläze aufnehmen? Z.B.
  L<http://www.stadtentwicklung.berlin.de/umwelt/stadtgruen/kinderspielplaetze/de/spielplaetze/>

=item * Radtouren um FF herum

L<http://www.adfc-frankfurt-oder.de/radtour/>

=back

=head2 Erfassung

=over

=item * (H3)

comments_mount: zurzeit schätze ich mithilfe des Alt-Graphen in
BBBikeGPS.pm und der Hilfe von BBBikeRuler (Mount of GPSman tracks)
Steigungen ab. Das ist noch recht ungenau und teilweise problematisch:

 * Wenn Hin- und Rückfahrt übereinander liegen, dann kann BBBikeRuler
   nicht verwendet werden, weil es mal einen Punkt von einem und den
   anderen Punkt von dern anderen Fahrt nimmt.
   Verbesserungsmöglichkeit: nur nahe liegende Punkte verwenden.
   Außerdem wäre es besser, wenn beide (alle) Steigungen angezeigt
   würden.

 * Es ist nicht ganz klar, welcher Höhenpunkt genommen wird: der
   erste, der letzte eines GPS-Trackabschnitts?

 * Es wäre schön, wenn man schon im Alt-Graphen die Steigung ablesen
   könnte.

 * Es wäre schön, wenn man mehrere Tracks in einem Alt-Graphen
   zeichnen könnte. Dann müsste man noch horizontal (potenziell
   verschiedene Startpunkte und Streckenverläufe) und vertikal
   (potenziell andere Altimeter-Kalibrierung) verschieben können.

 * Was nehme ich eigentlich? Den Durchschnitt oder das Maximum oder
   eine Kombination aus beidem? 

=item * (H1)

Schön wäre ein Gerät, dass mir während des Radfahrens beim Erfassen
von Ampelschaltungen helfen könnte. Ideen für dieses Gerät:

 * Es hat einen GPS-Empfänger und kann mir meine Position in einer
   kleinen Karte anzeigen.

 * Es benutzt vielleicht den NMEA-Kanal von GPS-Empfängern, so dass
   man auch die Satellitenpositionen und -signalstärken auslesen kann
   und damit eine ungefähre Genauigkeit ableiten kann.

 * Über den GPS-Empfänger kann es erraten, auf welcher Straße ich
   gerade fahre. Damit kann es auch erraten, welche die nächste und
   übernächste Ampel ist. Ggfs. kann es eine vorgefertigte Route als
   weiteren Hint nehmen.

 * Im einfachsten Layout hat das Gerät vier große Schaltflächen:
   Beginn der Gelb+Rot-Phase und Grünphase jeweils für die nächste und
   übernächste Ampel.

 * Ein komplizierteres Layout könnte zwischen Auto- und Radfahrampeln
   sowie zwischen Geradeaus- und Abbiegeampeln (wo anwendbar; Daten
   dazu fehlen komplett!) unterscheiden können.

 * Um das kompliziertere Layout zu vermeiden, könnte man zumindest für
   die Auto- und Radfahrampeln eine Heuristik anwenden: wenn man "zu
   weit" von den Ampel entfernt ist (wo auch immer die Grenze ist),
   wird man nur die Autoampel erkennen können. Wenn man nah dran ist
   *und* man sich relativ eindeutig auf dem Radweg befindet, wird die
   Fahrradampel verwendet. Das Erkennen, dass man sich auf dem Radweg
   befindet, ist eine Wissenschaft für sich: falls die GPS-Daten genau
   genug sind (unter fünf Meter!) oder man sich mit einer "eindeutigen
   Geschwindigkeit" bewegt (schnell auf der Fahrbahn, langsam auf dem
   Radweg)

 * Man müsste eine Undo-Funktion haben.

 * Man müsste anzeigen können, dass eine Ampel schon rot oder grün
   anzeigt (das wäre für eine Online-Analyse interessant).

 * Das Gerät enthält Ampelschaltungsdaten und fügt ständig neue dazu.

 * Die Ampelschaltungsdaten werden regelmäßig mit dem
   Haupt-BBBike-Repository synchronisiert.

 * Aus den Fakten werden passende Regeln generiert. Regeln können auch
   manuell definiert werden. Regeln haben Gewichte (oder eine
   Wahrscheinlichkeit, oder Prioritäten). Regeln könnten sein:

   * Statisch geschaltete Ampeln haben relativ normierte Zyklen, meist
     60, 70, 80, oder 90 Sekunden. Wenn eine Straßenbahntrasse an der
     Kreuzung existiert, ist die Wahrscheinlichkeit für 90 Sekunden
     hoch.

   * Bei modernen Fußgängeranforderungsampeln bekommen Fußgänger fast
     sofort grün (ca. nach zwei Sekunden), aber es gibt eine
     n-sekündige "Mindestzeit" zwischen zwei Grünphasen (z.B.
     Bergmannstr. ca. 20 Sekunden)

   * Folgende Ampeln haben den gleichen Zyklus. Die
     Wahrscheinlichkeit, dass sich der Zyklus nicht ändert, ist groß,
     sobald keine wichtigere Straße kreuzt.

   * Zyklen und Phasen sind zu gleichen Tageszeiten und an gleichen
     Wochentagen gleich. Folgende Gruppierungen wird es wahrscheinlich
     geben: morgendlicher Berufsverkehr, Tagesverkehr,
     nachmittäglicher Berufsverkehr, Abendverkehr, Nachtverkehr,
     jeweils für Mo-Fr, Sa und So/Feiertag (Liste der
     deutschen/Berliner Feiertage!).

 * Wenn während der Fahrt Regeln angewendet werden können und auch
   Fakten für die augenblickliche Fahrt existieren, dann soll das
   Gerät Empfehlungen für die zu fahrende Geschwindigkeit geben. Dabei
   wird die jetzige Position zur Position des Ampel (abzüglich der
   halben Breite der kreuzenden Straße, heuristisch ermittelt) und die
   prognostizierte Zeit für den nächsten Wechsel auf eine Grünphase
   verwendet, ggfs. auch für darauf folgende Ampeln. Weiterhin wird
   die bisherige "Reisegeschwindigkeit" als Grundgeschwindigkeit
   angenommen (Stopps und kurze Sprints werden hierbei
   herausgerechnet), sowie die maximal mögliche Geschwindigkeit für
   die folgende Strecke (wegen Kopfsteinpflaster, Steigungen etc.)
   noch mit eingerechnet. Die Empfehlung wird fortlaufend revidiert.
   Die Empfehlung kann auch als ein Bereich angegeben werden. Schön
   wäre auch eine hörbares Signal, welches "langsamer" oder
   "schneller" angeben würde.

 * Bei dynamischen Ampelschaltungen ist die Berechnung schwieriger.
   Wahrscheinlich bedeutet die Dynamik nur, dass Grünphasen verlängert
   werden können, aber die eigentliche Zykluszeit gleich bleibt. Oder
   dass bei Bedarf Phasen über zwei Zyklen erweitert werden. Hier kann
   man vielleicht nur mit Wahrscheinlichkeiten arbeiten? Oder kann man
   geschickt die A- und Z-Lichtzeichen der Straßenbahnen mitverwenden?
   Oder einfach angeben können, dass irgendwo eine Straßenbahn fährt?

 * Für die Hardware hätte ich zurzeit die folgenden Alternativen: iPAQ
   mit altem eTrex, dem N95 oder etwas ganz Neues.

   * Nachteile beim iPAQ: die Konstruktion wäre wegen des seriellen
     Kabels wacklig, das alte eTrex hat eine schlechte Genauigkeit,
     ein Halter für den iPAQ wäre notwendig, der Touchscreen des iPAQs
     ist schlecht, die Akkus des iPAQs sind am Ende und würden kaum
     eine Fahrt überstehen, das iPAQ dürfte nicht wasserdicht sein.
     Vorteil: ich könnte ich Perl/Tk programmieren.

   * Nachteile beim N95: solange ich kein Firmwareupdate mache, ist
     der eingebaute GPS-Empfänger fast unbrauchbar, ein Halter für das
     N95 wäre notwendig (siehe
     http://www.telefon-treff.de/showthread.php?postid=2848643), die
     Programmierung müsste in Java oder C++ erfolgen, es gibt keinen
     Touchscreen, sondern alles müsste über die kleinen Softkeys und
     vielleicht über den Cursor erfolgen, das N95 dürfte nicht
     wasserdicht sein. Vorteil: wenn der Halter halten würde, wäre es
     keine wacklige Konstruktion. Schön wäre es, wenn man das Gerät
     per Sprache steuern könnte (es müsste ja nur "rot", "grün",
     "nächste" und "übernächste" verstehen können, erst einmal).

   * Nachteile beim Neuen: ich müsste erst einmal evaluieren, was es
     gibt. Es müsste GPS eingebaut haben, möglichst frei
     programmierbar sein (Perl!), es müsste einen Touchscreen haben,
     es müsste einen Fahrradhalter dafür geben.

=back

=head2 Datenhandling (make, conversion ...)

=over

=item * (M3)

"Modersohnbrücke" wird nicht gefunden, weil brunnels nicht in strassen
enthalten ist. Sollte bei einer Brücke, die in Berlin.coords.data
gefunden wurde, aber die nicht in strassen enthalten ist, in brunnels
nachgeschaut werden? Würde nicht allzuviele Brücken betreffen, wie es
aussieht.

=item * (M5) (bug)

Bei Verwendung von PreserveComments=>1 sollte $s->next die Kommentare
überspringen. Siehe workaround in Strassen::CoreHeavy::simplify.

=item * (H4)

Es sollte möglich sein, in einer bbd-Datei sowohl nur-Routing- als
auch nur-Mapping-Information unterzubringen. Ein Beispiel wäre
3nocross/3: beim Routen benutzt man die E<quot>3E<quot>er-Kategorie,
beim Plotten die E<quot>3nocrossE<quot>-Kategorie. Evtl. könnte ich
eine Konvention erfinden, dass Kategorien, die mit E<quot>RTE-E<quot>
anfangen, für das Routing reserviert sind und nicht geplottet werden
sollen. Sollte es dafür eine spezielle next-Methode in Strassen::Core
geben, welches solche Kategorien überspringt (next_map)? Oder kann ich
das erst einmal ignorieren, weil der gesperrt-Layer sowieso nur in
bbbike Perl/Tk gezeichnet wird und spezielle gesperrt-Kategorien beim
MapServer noch ignoriert werden?

=> Sollte mit igndisp und ignrte (siehe data/gesperrt, siehe L<bbd>)
implementiert sein.

(related entry in the TODO list:)

Idee: in bbd-Dateien die Möglichkeit erzeugen, Display-only- und
Routing-only-Informationen ablegen zu können. Z.B.

    #: routing-only vvv
    Straße	q4; X1,Y1 X2,Y2
    #: routing-only ^^^
    #: display-only vvv
    Straße	1 X1,Y1 X2,Y2
    #: display-only ^^^

In diesem Beispiel würde die Straße als Einbahnstraße dargestellt
werden, aber im Routing als Schrittgeschwindigkeitstraße behandelt
werden.

=> Speziell dieses Beispiel wurde aber mit Kategorien gelöst: C<1s:q4>

=item * (H5)

Einbahnstraßen-Reorganisation: Die derzeitigen Typen von
Einbahnstraßen 1 und 1s sollen noch feiner aufgeschlüsselt werden.
Beispiele: 

 * Neue Schönhauser Str.: die Straßenbahn darf in beide Richtungen
   fahren, d.h. die Fahrbahn ist breit genug und normalerweise sollte
   es keine Konflikte mit dem Gegenverkehr geben. Höchste Kategorie
   (= 25 km/h?) (+ Achtung, Einbahnstraße!) -> DONE

 * Am Treptower Park: teilweise Gehweg, teilweise Nebenfahrbahn zum
   Parken. Eher niedriges Konfliktpotenzial, vielleicht mittlere
   Kategorie (= 18 km/h?) (kein Achtung?)

 * Bayernring, Schulenburgring: sehr wenig Verkehr, aber enge Straße.
   Deshalb niedrige Kategorie. (= 13 km/h?) (+ Achtung,
   Einbahnstraße!) -> DONE

 * Jahnstr.: etwas mehr Verkehr, aber auch etwas breitere Straße.
   Zusammengenommen auch niedrige Kategorie. (+ Achtung, Einbahnstraße!)
   -> DONE

 * Landwehrkanalstraßen: gegen die Richtung mit nur 5 km/h erlauben
   (Gehwege) (+ Achtung, Einbahnstraße -> Gehweg!)

 * Großer Stern: gegen die Richtung mit vielleicht 13 km/h erlauben?
   Eher wenig Fußgängerverkehr, kurze Strecken, relativ breite
   Gehwege. (+ Achtung, Einbahnstraße -> Gehweg!)

 * Mangerstr.: Radfahren auf dem schmalen Gehweg erlaubt? (+ Achtung,
   Einbahnstraße -> Gehweg!)

 * Flughafen Tegel: striktes Einbahnstraßenverbot (keine durchgängigen
   Gehwege, starker Verkehr)

Vielleicht mal einige Realworldbeispiele mit Stoppuhr messen?

Weiterhin sollte in der CGI-Version angezeigt werden, dass man gegen
die Einbahnstraße fährt bzw. schiebt (aber vielleicht nicht immer,
siehe Beispiele oben). -> DONE

=item * (H3)

Fragezeichen-Reorganisation: Es gibt mehrere Typen von Fragezeichen:

=over

=item public: werden von fragezeichen-orig nach fragezeichen
konvertiert und sind öffentlich sichtbar, insbesondere Perl/Tk-Version
im Nicht-Edit-Modus und WWW-Version

=item private: sind nur in fragezeichen-orig und nicht öffentlich
sichtbar, d.h. nur in der Perl/Tk-Version im Edit-Modus (allerdings
sollte es auch eine Möglichkeit geben, die privaten Fragezeichen im
Nicht-Edit-Modus anzuschauen)

=item last_checked/next_check mit relativen Datum: diese könnten
automatisch als öffentliche Fragezeichen erzeugt werden (falls nicht
ausdrücklich als privat gekennzeichnet)

=item Datensätze mit add_fragezeichen-Direktiven versehen: diese sind
in fragezeichen-orig nicht sichtbar, dafür aber in fragezeichen

=item XXX-Datensätze: diese sind ebenfalls in fragezeichen-orig sowie
in fragezeichen nicht sichtbar

=item Es gibt Fragezeichen, die das Abfahren einer Strecke verlangen
sowie Fragezeichen, die durch andere Recherchemöglichkeiten aufgelöst
werden (z.B. Ortsteilfragen, nicht ausgeschilderte offizielle
Straßennamen ...) -> indoor vs. outdoor

=item Es gibt Fragezeichen, die durch eine technische Änderung
aufgelöst werden können (z.B. durch das Einführen von neuen
Straßenattributen)

=back

Es gibt folgende fragezeichen-Dateien am Ende:

 - fragezeichen-public (weiterhin nur E<quot>fragezeichenE<quot>
   genannt, einzige Datei, die in die Distribution wandert)
 - fragezeichen-private-outdoor (für alles, was E<quot>vor OrtE<quot>
   recherchiert werden kann; falls es eine
   nextcheck/lastcheck-Direktive gibt, wird diese beachtet)
 - fragezeichen-private-indoor (für alles, was im Internet oder
   sonstwo recherchiert werden kann)
 - fragezeichen-checklater (ebenso Sachen, die
   E<quot>vor OrtE<quot> recherchiert werden können, aber die später
   überprüft werden sollen --- wegen einer
   nextcheck/lastcheck-Direktive. Hier können sich öffentliche und
   private Fragezeichen befinden)
 - fragezeichen-tech (Sachen, die durch technische Änderungen
   aufgelöst werden können)

XXX.bbd wird nicht mehr benötigt. Alle fragezeichen-*-Dateien außer
-public kommen nach bbbike/tmp.

Ungefähre Einordnung der jetzigen Daten:

 - geplante Straßen und Radstreifen: sofern nicht durch nextcheck
   oder ein Fertigstellungsdatum im Text abgedeckt, können diese ruhig
   nach fragezeichen-public (aber genauer prüfen!)
 - section private Fragezeichen -> fragezeichen-private-indoor oder -outdoor
 - Aufnahme in DB fraglich: dieser Abschnitt sollte entfernt werden
 - Isolierte Einträge: fragezeichen-private-outdoor
 - öffentliche Fragezeichen: fragezeichen-public
 - XXX (alternativ: XXX-outdoor) -> fragezeichen-private-outdoor
 - add_fragezeichen -> fragezeichen-public
 - eine neue Direktive für fragezeichen-private-indoor:
   XXX-indoor
 - eine neue Direktive für fragezeichen-tech:
   XXX-tech

=item * (H4)

Routes vs. Layers: some data formats may be interpreted as routes and
as map layers. If interpreted as routes, then normally information is
lost (colors, route is always connected...). If interpreted as map
layer, then information about length and time and maybe a route list
is not available. How to solve this problem? Have a clever route/layer
loader which decides what to use?

=item * (H5)

Introduce interrupted routes. E.g. by introducing E<quot>interruption
elementsE<quot> in realcoords_ref; or another variable. Rendering:
interrupt the route at these points. bbr2bbd: should look nicely.
bbd2bbr also.

=item * (M4)

comments_route should probably be combined (e.g.
RR6+Pankeweg+Berlin-Usedom), just like sbahn/rbahn. Interesting
question: what icon should be shown in a combined section? both? the
first? alternated?

Vielleicht ist das Kombinieren nicht so dringend, wenn die
mehrzeiligen Tooltipps poliert und für alle verfügbar sind. Aber für
das leichtere Editieren könnte es trotzdem sinnvoll sein (Vermeidung
der Doppelung).

=item * (M3)

Check the coordinates of Berlin.coords.data against the corresponding
streets in strassen-orig.

=item * (M3)

resolve_stars: add support for E<quot>* X *E<quot>

=item * (H4)

.desc-Dateien komplett durch globale Direktiven ersetzen. Es fehlt noch:

    @scrollregion = (516703,180658,918450,458155)
    $p_attrib = ["Botschaft", "Botschaften, undef];

=item * (H2)

0-Sperrungen mit Richtungen durch drei Koordinaten kennzeichnen.

=item * (H3)

Check auf E<quot>erlaubteE<quot> Kategorien pro Datei, also z.B.
H/HH/N/NN in strassen, zusätzlich B in landstrassen, nur Pl in plaetze
etc. Diese Information könnte auch dazu verwendet werden, um im
Straßen-Editor die Kategorien einzuschränken. BBBikeCategories.pm?

=item * (H4)

Find algorithms for reducing points in a polyline/gon. Use it for
wasserstrassen-lowres.

=item * (M4)

Automatic conversion from GPS tracks to bbd data: maybe using
Douglas-Peucker polyline simplification algorithm?

=item * (H4)

Ich brauche eine spezielle handicap-Kategorie für Abbiegevorgänge
(z.B. q\d3 oder q\d::3 oder q\d::dir (für directed)), sowohl für
Anzeige als auch für das Routing.

Datenbeispiel: Am Volkspark/Bundesallee

=item * (M3)

Introduce new bbd file E<quot>xxxE<quot> which contains all non-public
XXX comments. ? on devel-host would also draw xxx.

=item * (M4)

Siehe miscsrc/merge_overlapping_streets.pl

=item * (M1)

Convert the data/Makefile to data/Makefile.PL or similar (to solve
problems like for loops etc. only availabkle in BSD make).

=item * (M3)

All references to E<quot>commentsE<quot> should use the partial
comments files instead. Maybe define a method with a list of the
partial files in Strassen/Dataset. Create new menu cascade Comments
all and comment types (partially done in bbbike, check for other
apps).

=item * (M4)

insert_points changes:

* warn if deleting a point causes a street to have only one point

* special handling for vorfahrt:

  given A B C
  insert between A and B: A changes to last inserted point
  insert between B and C: C changes to first inserted point

=item * (H3)

insert_points optimizations:

* Use a MLDBM or similar database for a point -> [file, pos] mapping.
  This can be used for fast searching. Check database file <-> orig
  file for recentness.

* Further optimization: the insert/add/change/move operations should
  update the MLDBM database themselves to avoid a complete rebuild.

=item * (M4)

Use the :by and :temporary directives in the data files (ampeln
already done). Change some files which are using this information
(e.g. misc/Makefile). Write some tests for all kinds of directives
(global, block, line, nested blocks and lines, errors)

=item * (M3)

Change convert_* to optionally not ignore directives and comments.
Rewrite the misc/Makefile rule to use standard Strassen methods.

=item * (H4)

In bbd files, there are presently line and block directives. Maybe
introduce another form of block directives, which do NOT nest. This
could be used for a E<quot>sourceE<quot> directive, which is more
convenient to specify once at the beginning and not also at the end.

=item * (H3)

A new E<quot>sourceE<quot> directive could probably change the virtual
file location for relative paths.

=item * (H4)

Add more directives to control presentation of bbd files. E.g:
plotting of labels enabled...

=item * (H1)

Add directives for a kind of E<quot>metaE<quot> bbd which contains
only references to other bbd file (E<quot>includeE<quot>?
E<quot>referenceE<quot>?). But some questions are difficult to answer,
e.g. how to apply global directives? What is the current directory of
the file?

But if the only concern is to open multiple layers and to avoid clumsy
GUI dialogs, then it's probably sufficient to just use the
BBBike-Server/Client.

=item * (H4)

Radwegekategorien erweitern: RW(kategorie)(qualitaetskategorie). Also
heißt dann z.B. RW00: Radweg mit sehr guter Qualität und
RW13: benutzungspflichtiger Radweg mit sehr schlechter
Qualität. Bei den restlichen Kategorien kann man sich die
Erweiterung sparen, da dort die Qualitätskategorie der
Straße gilt. Default-Qualitätskategorie für Radwege
sei 1 (gute Qualität).

Problem => ich bin schon bei RW10 angelangt, also brauche ich eine
andere Kodierung.

Ich könnte aber RW(kategorie)::Q(qualitaetskategorie) verwenden (mit
einem oder zwei Doppelpunkten). Präzedenzfall: in gesperrt gibt es
1s:q1.

=back

=head2 cgpsmapper

=over

=item * (H3)

Fragezeichen besser bauen: alle aus fragezeichen ausser für mich
ignorierte (wo ich z.B. die Daten einfach nicht aufnehmen will).
next_check/last_checked beachten. Auch alle XXX-Strecken aufnehmen.
temporaries aufnehmen (es sei denn, mit next_check/last_checked
versehen).

=item * (M1)

zwischen Seen und Meer unterscheiden (benötigt Support in
wasserstrassen/wasserumland)

=item * (M3)

landstrassen/N und NN ab 8km oder so nicht mehr sichtbar haben;
Sichtbarkeiten zwischen strassen und landstrassen differenzieren

=item * (H2)

Straßennummern - wie?

=item * (H3)

Images oder Prozess veröffentlichen

=> Ja, images existieren bereits auf Sourceforge im
bbbikedata-b_de-Package
L<http://sourceforge.net/project/showfiles.php?group_id=19142&package_id=207826>

=item * (M1)

Eisenbahnen werden zurzeit nur bis 200m angezeigt. Für RB hochgehen
auf 3 km oder mehr, bei S-Bahn auf ca. 800m, bei U-Bahn auf ca. 500m
(falls es überhaupt geht). -> Ich glaube, dass ist beim Garmin so
eingebaut. Nicht zu ändern. Vielleicht mal per Googlen überprüfen.

=item * (H3)

Friedhof-POI (als Punkt zusätzlich zu der Fläche, z.B. in der Nähe des
Eingangs oder in der Mitte), bank-POI (falls ich noch
sparkassen/citibank-Daten habe), sonst. Sehenswürdigkeiten ->
building-POI, stadium, tall tower (Fernsehturm, Funkturm,
Schäferbergturm -> müsste gekennzeichnet sein), Zoo-POIs, igraliste
(PVRT?)

=item * (H3)

Einführen von Garmin-Typen in bbd, z.B.: SW::GARMIN=0x1f39. Diese
könnten von bbd2polish direkt verwendet werden. IDs oder Klartextnamen
verwenden?

=back

=head2 Verschiedenes

=over

=item * (M5)

Cleanup the E<quot>-infoE<quot> companion of a .bbd file. Suggestions:

* Have a .yml or .dd file (first better because it's more readable,
  second is better because it does not need any perl requirements, but
  is also unsafe) with the id -> info-string/object mapping. Name it
  maybe .infoyml or .infodd?

* Have a module which reads and creates these info files.

* It is preferable to cache these files in a berkeley db file or
  anydbm file (like is the situation now).

* Parts of the info-reading code in show_info in bbbike should also go
  into this module.

The other tracks in misc/gps_data should have a info companion.

=item * (M5)

Many old files in misc/gps_data seem to have wrong TZ setting. This
could probably be automatically fixed?

=item * (H4)

Interesting: L<http://www.geonames.org/export/>. Geographical names,
elevations at a accuracy of 90 meters.

=item * (E1)

L<http://bikeroutetoaster.com/Course.aspx>. A route planner, but
nearly unusable for Germany. One will be routed over freeways, and
good cycle routes are not available within this application.
Interesting: the evelation display using data from geonames. Maybe I
should, too?

=item * (M4)

Nicht benötigte Einträge aus bbbike-temp-blockings.pl nach
old-bbbike-temp-blockings.pl verschieben. old-bbbike-temp-blockings.pl
kommt ins MANIFEST.addtocvs, aber nicht ins MANIFEST. -> evtl. reicht
die jetzige Methode mit dem optimierten bbbike-temp-blockings?

=item * (E1)

weblinks E<quot>offiziellE<quot> machen.

=> Ja, gibt es bereits auf der Info-Seite.

=item * (E1)

Look at it:

Es wurde eine Unterführung gebaut, die erst die Fernbahntrasse und ein
paar Meter weiter dann auch die neue S-Bahntrasse unterquert. Bilder
hier: http://www.bsisb.de/default_f.htm?/anhalter/anhalter07fc.htm
oder direkt die schrittweise Wandlung vom Kolonnenweg zur Unterführung:
http://www.bsisb.de/anhalter/g_s_lio_tw/l25.htm

=item * (H4)

Wie zeige ich an, dass ein BNP unpassierbar fuer anhaenger ist?
Fr-Jahn-Sportpark zur Topsstr ist so ein fall.

=item * (H4)

Alle in "strassen" vorkommende Straßen sollten auch in
"Berlin.coords.data" stehen. Ansonsten gibt es derart Probleme,
daß zwar beim CGI in der Liste "Alle Straßen anzeigen"
z.B. "Hallesches Tor" angezeigt wird, diese Straße als Eingabe
aber nicht akzeptiert wird. Sprich: die Datei data/add_str sollte auf
Aktualität überprüft werden und dann möglichst
alle fehlende Straßen nach Berlin.coords.data übertragen
werden.

Hatte ich schonmal:
[in add_str sollten möglichst KEINE "richtigen" Straßen stehen --- nur
Sachen wie Brücken, Tunnel, "Alexanderplatz [zur Grunerstr.]", Parkwege etc.
ansonsten werden sie in bbbike.cgi nicht erkannt, obwohl sie
existieren!]

Vielleicht ein ausreichender Workaround vorerst: Liste aller Straßen
enthält nicht die Straßen, die keine Koordinate in Berlin.coords.data
haben.

=item * (M2)

Landstraßen: Gibt es Untersuchungen zur Verkehrsdichte?
Recherchieren! => Jan hat etwas gefunden (Aldi-Karten...) -> Die habe
ich jetzt auch...

=item * (H1)

Garmin GPS Courses - kann mittels
L<http://www.bradculberson.com/cc/map.html> erzeugt werden.

=back

=head1 Routing (BBBikeRouting.pm, Strassen::StrassenNetz)

=over

=item * (H4)

Alberne Route: Route auf der Bergmannstraße mit "Hauptstraßen ohne
Radwege vermeiden" und Ampeloptimierung suchen. BBBike schlägt einen
Umweg über die Arndtstr. vor. Prüfen, ob die Ampelschaltung
tatsächlich "doppelt" zählen muss oder man die beiden Ampeln als
einzige zählen soll.

=item * (H3)

Ungünstige Beschreibung: Endpunkt ist Pariser Str./Bundesallee, man
kommt von Osten und wird auf der Regensburger Str. geroutet. Natürlich
befindet man sich jetzt nicht auf der Pariser Str., sondern muss
umständlich zur Kreuzung Nachodstr., die Bundesallee überqueren, und
dann wieder den Weg zur Pariser zurückfahren. Besser wäre es
wahrscheinlich gewesen, gleich eine Route über die Nachodstr. zu
wählen.

=item * (H5)

Alberne Beschreibung, sollte lieber E<quot>3x ...E<quot> erwähnen:

nach 0.10 km	rechts (50°) in den	Parkweg	1.7 km
enge Brücke, Fußweg; teils sehr gutes Kopfsteinpflaster; Drängelgitter
(ca. 5 Sekunden Zeitverlust); Drängelgitter mit asphaltierer
Vorbeifahrmöglichkeit (Parkweg) (ca. 2 Sekunden Zeitverlust);
Drängelgitter mit asphaltierer Vorbeifahrmöglichkeit (Parkweg) (ca. 2
Sekunden Zeitverlust); Drängelgitter mit asphaltierer
Vorbeifahrmöglichkeit (Parkweg) (ca. 2 Sekunden Zeitverlust)

=item * (H5)

In der Routenliste problematische Kreuzungen anzeigen, zum Beispiel
eine abknickende Straße mit dem gleichen Straßennamen (das Abbiegen
wird nirgendwo angezeigt) oder bei Kreuzungen mit abknickender
Vorfahrt. Siehe oben: situation_at_point()

=item * (H4)

Neue Kategorie 0 und BNP mit Richtungsabhängigkeit einführen. Z.B.

	0:10	A B C

wobei B die Stelle mit dem Hindernis ist. Es sind also nur genau ein
oder drei Punkte erlaubt. Im Pre-Processing könnte man Joker (*)
erlauben.

Implementiert werden muss:

* Routing (wahrscheinlich ähnlich wie E<quot>3E<quot> und
E<quot>BNPE<quot>, make_sperre und build_penalty_code müssen geändert
werden)

* Zeichnen im Perl/Tk-Tool (weiterer Spezialfall in plot_sperre,
vielleicht mit einem Pfeil versehen? Oder versetzt zeichnen, wenn die
Position eindeutig ist (i.e.: * A B)? Neues Icon bzw.
Polygon/Polyline-Zug für Bordsteine, da diese so oft vorkommen [wenn
ja, dann auch im Postprocessing (Winkelberechnung) berücksichtigen]?)

=item * (H2)

Optimierung: bei Landstraßen reine Kurvenpunkte bei der
Netzberechnung ignorieren. Das ist mit B<make_wide_net> bereits
implementiert, wird aber nicht verwendet. Benchmarks? Probleme?

=item * (H1)

Suchen nach Alternativen. Es ist schwierig zu entscheiden, wann eine
Alternative wirklich eine Alternative darstellt (z.B. ist es kein
großer Unterschied, ob man nur rechts oder links um einen Block
herum fährt).

=item * (H1)

Neuimplementation der Streckensuche. Dabei soll zwischen
Streckenaufwänden und Knotenpunktaufwänden unterschieden
werden. Aufwände werden entweder in Längen, in Zeit oder
in einem Punktesystem (Kombination aus Zeit, Komfort, Sicherheit etc.)
angegeben. Streckenaufwände berechnen sich aus: Länge der
Strecke, Gegenwind, Steigungen, Dynamowiderstand,
Straßenqualite<auml>t der Strecke, sonstige Hindernisse auf der
Strecke, Verkehrsdichte (Staus, Berufsverkehr), Radwege,
Maximalgeschwindigkeiten. Knotenpunktaufwänden berechnen sich
aus: durchschnittliche oder wahre Ampelwartezeit mit Zeit für
die Beschleunigung, durchschnittlicher Zeitverlust an
Rechts-vor-links-Kreuzungen und an vorfahrtsgewährenden
Kreuzungen (abknickende Vorfahrtsstraßen beachten), Zeitverlust
für Abbiegevorgänge (rechts, links), erschwertes Abbiegen
(Bordsteinkanten überwinden). Qualitätsbewertungen:
Straßenqualität, niedrige Leistungsaufwände (Wind,
Steigungen), Nebenstraßen, Parks. Sicherheitsbewertungen:
Nebenstraßen vor Hauptstraßen bevorzugen, Radwege
ja/nein. In (C) und Perl implementieren.

Analyse eines Streckenabschnitts:

=over

=item * Feststellen der Länge

=item * Feststellen der Windrichtung und -geschwindigkeit

=item  * Feststellen der Steigung

=item  * Verluste durch Straßenqualität

=item  * Korrigieren auf Maximalgeschwindigkeit (max. Trittfrequenz)

=item  * anhand der aktuellen Leistungswert Zeit berechnen

=back

Analyse einer Kreuzung:

=over

=item  * Feststellen, ob es um einen Abbiegevorgang handelt und ggfs. Zeit
   für den Abbiegevorgang abziegen

=item  * Feststellen, ob eine Ampel vorhanden ist, und eine
   durchschnittliche Zeit abziehen.

=item  * Feststellen, ob die Vorfahrt beachtet werden muß

=back

Z<>=E<gt> nicht unbedingt notwendig, die jetzige Lösung reicht erst
einmal aus...

Siehe oben: situation_at_point()

=item * (H3)

Compressed data: use <long><long> (or <short><short>) for starting x,y
value and then only the deltas as bytes <byte><byte>. Add additional
points if delta exceeds 128/128 meters.

=back

=head1 CGI version of BBBike (bbbike.cgi)

=over

=item * (H5) (improvement)

Temporär gesperrte Straßen wie z.B. der Innovationspark Köpenick oder
das Gartenufer in Tiergarten sollten suchbar sein, aber ähnlich wie
temp_blockings behandelt werden, d.h. der User soll eine
Ausweichstrecke auswählen können.

Das gleiche könnte man generell auch für Fähren machen.

=item * (M4) (bug)

Einige Einstellungen in bbbike.cgi.config scheinen bei der
Apache::Registry-Operation permanent über Requests bestehen zu
bleiben. Gesehen bei: @PLZ::plzfile, vielleicht auch datadirs.
Lokalisieren?

=item * (E3) (bug)

mamboforge.net war am 2008-08-16 nicht erreichbar. Ist die Seite
permanent down?

=item * (H4) (feature)

Sehenswürdigkeiten auswählbar machen. Prinzipiell geht das schon, wenn
man "sehenswuerdigkeit_bp" in @b_and_p_plz_multi_files einbindet.
Aber:

 * Bei der Suche nach E<quot>GesundbrunnenE<quot> bekommt man nun auch
   E<quot>Gesundbrunnen-CenterE<quot> angeboten. Möchte ich das?
   (Abgesehen davon, dass ein cgi.t-Test deswegen bricht)

 * Zurzeit wird eine Sehenswürdigkeit (und auch schon immer
   U/S-Bahnhöfe) in die jeweilige Kreuzung übersetzt, was etwas
   hässliche aussieht (insbesondere beim Beispiel
   Gesundbrunnen-Center). Sollte hier vielleicht die
   Sehenswürdigkeit/der Bahnhof genommen werden? Abwägen?

 * Was passiert mit den Sehenswürdigkeiten, die sich bereits in
   plaetze befinden? Herausnehmen?

 * Zurzeit wird alles in Klammern als Bezirk angenommen. In
   sehenswuerdigkeit gibt es aber viele Klammern in anderer Bedeutung,
   z.B. E<quot>Belvedere (Pfingstberg)E<quot>. Wie soll ich damit
   verfahren?

 * Theoretisch könnte ich eine Checkboxreihe im Eingabeinterface
   anbieten: Straßen/Plätze; Bahnhöfe; Sehenswürdigkeiten/öffentliche
   Gebäude. Ja/Nein?

=item * (M4) (improvement)

Radrouten auch als Routenliste bereitstellen. Eine erste
Implementation existiert schon. Noch vorhandene Probleme:

Wie behandelt man unterbrochene Routen?

Kann man Abschnitte, in denen die Hin- und Rückstrecke nicht
gleich ist (Beispiel: E<quot>CS;E<quot>, z.B. Großer Stern), bei
E<quot>RückwegE<quot> richtig behandeln (zurzeit ist
E<quot>RückwegE<quot> in bbbike.cgi ausgeschaltet)?

Kann man Alternativen besser behandeln, besonders in der Kartenansicht
(normale Route und alternative Route anzeigen? Man könnte z.B. eine
Kartenansicht für die E<quot>HauptrouteE<quot> haben und eine, bei der
alle Alternativen eingezeichnet sind.

Flaeming-Skate ist ein besonderer Fall, da es sich nicht um
Alternativen, sondern E<quot>Sub-RoutenE<quot> handelt. Hier ist eine
Routenliste für die Hauptroute nicht möglich (es gibt keine
Hauptroute). Bei der Kartenansicht könnte man alles anzeigen und jede
Sub-Route gesondert. Man muss auch beachten, dass Sub-Routen kombinert
sind (E<quot>Flaeming-Skate (RK1, RK2)E<quot>). bbd2mapservhtml muss
diese aufteilen und dann noch Strassen::Combine::make_long_streets
aufrufen (mehrere Strecken für die gleiche Sub-Route sind dann
womöglich ein Fehler, prüfen!).

=item * (M3) (bug)

Wenn man in der Straßenlistenauswahl die E<quot>Potsdamer Str.
(Potsdam)E<quot> auswählt, so erscheint ein Fehler

    [Sun Feb  3 23:29:41 2008] bbbike.cgi: Fehler: Ziel <Potsdamer Str. (Potsdam)/position > kann nicht zugeordnet werden.

im error_log, aber das System scheint sich doch zu fangen und geht zum
nächsten Formular über. Meine Vermutung: die Straße existiert in
landstrassen als E<quot>Potsdamer Str. (B273) (Potsdam)E<quot>, aber
in Potsdam.coords.data ohne die Bundesstraßenbezeichnung. Vielleicht
muss ich die richtige strip_*-Funktion an der richtigen Stelle
anwenden.

Vielleicht auch systematisch mal schauen: 

    grep "kann nicht zugeord" /var/www/logs/radzeit.de-error_log

Kam 100x in den letzten 12 Monaten vor.

=item * (M5) (bug)

Wenn auf der Übersichtskarte eine Straße außerhalb Berlins aber in der
Nähe der Grenze angeklickt wird, dann wird häufig eine Straßenkreuzung
in Berlin gewählt, auch wenn es eine bessere Kreuzung außerhalb
Berlins gäbe. Lösung: zuerst prüfen, ob sich der Klickpunkt innerhalb
Berlins befindet, ansonsten sofort den Scope erhöhen.

=item * (M4) (improvement)

Review bbbike.cgi.config and change defaults in bbbike.cgi. Rule of
thumb: everything which is included in the normal distro and needed by
a feature, should be turned on.

=item * (M5) (bug)

If the strname_html parameter to fragezeichenform.html contains
HTML-escaped characters, then the parameter is parsed incorrectly due
to premature call of unescape(). I need a correct querystring parse
like the one in CGI.pm. Create one! Or maybe search one in the net.

=item * (H3) (feature)

Im Umland sollte statt Kreuzungen bevorzugt der Ortsname verwendet
werden. Der Code dazu ist teilweise schon vorbereitet (siehe
get_kreuzung, if (0)).

=item * (M5)

$g_str muss wissen, welcher Scope verwendet wurde. Und jeder Zugriff
auf get_streets muss ggfs. get_streets_rebuild_dependents aufrufen,
falls sich der Scope geändert hat.

Das wirkt sich nur in mod_perl aus.

Kann ich einen Test schreiben, der dieses Verhalten reproduziert
(i.e.: Apache neu starten, nur einen Prozess verwenden, scope=city ...
scope=region, kreuzung auswählen -> boom!)

-> fixed, aber der Test fehlt noch...

=item * (H5)

Ich habe unvollständig gezeichnete Kacheln (fehlende Straßen) auf
bbbike.de gesehen. Wie sind sie entstanden? Vielleicht eine
komplette Karte zusammenfügen, um zu sehen, ob weiterhin Fehler
entstehen?

=item * (H5)

Mit www.bbbike.de umziehen.

=item * (M4)

Alternative Startseite a la
L<http://wolfram.schneider.org/tmp/bbbike/> (gibt's nicht mehr!)
erzeugen. Aber zunächst müssten die Layer-Probleme gelöst werden (Via-
und Ziel-Layer sind nach dem Aufklappen verschoben).

Die Layer-Probleme gibt es übrigens schon jetzt, wenn durch ein Resize
des Browser-Fensters eine Umordnung der Layer erfolgt. Also brauche
ich so oder so eine Lösung.

=item * (H4)

Crop (or use?) the E<quot>ortE<quot> part of a street, i.e.
E<quot>robert-rössle-str. 10, 13125 berlinE<quot>. Split against the
E<quot>,E<quot> and filter (or use?) the part with berlin or without
str or ...

In real data (Berlin.coords.data) there are no streets containing a
E<quot>,E<quot> (just a few Siedlungen with E<quot>I,IIE<quot> and
Gaststätten).

=item * (M3)

Opera 7.11: nice_berlinmap seems to work, but nice_abcmap has problems
(only the first character is highlighted?). Check on newer Operas.

Another problem with abcmap and berlinmap: if the E<quot>niceE<quot>
code is disabled, then <Return> will fire the wrong button (that is,
the image maps...). Unfortunately the hidden submit hack does not work
on Opera...

Also: the clicking on the <label>...</label> part does not fire the
onClick function (seen on Opera 7.xx) (maybe I should just remove
<label> for Opera?).

=item * (M3)

Zusätzlich zu "Schopenhauer Str. (Potsdam)" die Schreibweise "Potsdam,
Schopenhauer Str." akzeptieren. Frage: nur fuer Orte oder auch fuer
Bezirke, also "Kreuzberg, Bahnhofstr."? Kommt auch vor, dass die Leute
E<quot>Berlin, ...E<quot> schreiben.

=item * (E2)

/robots.txt einrichten, um das Indexieren von temporären Dateien bei
bbbike und mapserver zu verhindern. -> Hmmm, es existiert schon ein
robots.txt. Mit Dirk konferieren? Nein, ich kann selbst robots.txt
schreiben.

=item * (H1)

Bei pref_fragezeichen=yes: Straßenbezeichnungen aus fragezeichen
vertragen sich mit Strasse::strip_bezirk nicht so gut. Es wird oft zu
viel abgeschnitten. Könnte strip_bezirk intelligenter programmiert
werden und tatsächlich nur die in Geography:: vorkommenden Bezirke
abschneiden? Wo wird strip_bezirk überall eingesetzt?

=item * (M1)

Evtl. Link auf Detailmap, um eine bessere Straße auszuwählen? Bei
"genaue Kreuzung": evtl. Link auf Detailmap um alternativ eine
Kreuzung auszuwaehlen?

=item * (H5)

Ackerstr. (Mitte,Wedding,Spandau)-Problematik: es sollte erkannt
werden, dass die Ackerstr. (Mitte, Wedding) die selbe Strasse ist. In
multi_bez_str steht es drinnen, muesste wahrscheinlich von PLZ.pm
verwendet werden (combined streets?). (Aber nur, falls multi_bez_str
vorhanden ist)

=item * (H2)

Subroutine zum Mapping von Kreuzungen (E<quot>Astr./Bstr.E<quot>) auf
mögliche Koordinaten erstellen. Ein Ansatz wäre der Code ab E<quot>if
(defined $crossing_street)E<quot> in bbbike.cgi. Die größte Frage ist
eigentlich, wo der Code hingehört: nach Strassen/Util.pm, Strasse.pm,
PLZ.pm oder StrassenNetz.pm?

Wenn die Subroutine einmal existiert, kann sie z.B. für E<quot>On
start center on streetE<quot> verwendet werden.

=item * (M2)

Request:

 > Wäre es auch möglich, daß man die Acrobat -datei erst speichern
 > könnte, bevor man sie sich anzeigen läßt? Oder, daß man diese
 > vielleicht per autom. Email zugeschickt bekommt?

Ersteres könnte man machen, indem man einen Link bereitstellt, der das
gleiche wie der submit-Button macht, nur mit Content-Disposition:
attachment oder ähnlichem. Vielleicht nicht allzu schwer.

=item * (M5)

Opera and Safari: Hitting the return key on the first screen calls the
abc page (because it's the first <input image> element in the form).
(SOLVED for Konqueror, Opera seems to be difficult, ask wosch about
Safari, same for MSIE!)

=item * (H1)

On resize, the reddot/bluedot points for multiple choices become
displaced. Siehe oben, Layer+Resize-Problematik.

=item * (M2)

Dokumentieren (in ?info=1): Beschreibung der Sucheinstellungen

=item * (H2)

Optional mehr Informationen in der Routenbeschreibung aufnehmen, z.B.
Steigungen, Sehenswürdigkeiten in der Nähe,
U/S-Bahnstationen ... Kommentare sind schon drinnen.

=item * (E3)

cgi-Version: Linux+Netscape: Probleme mit Cookies (Einstellungen)
=E<gt> noch immer? -> ein Problem habe ich gelöst, war es das?

=item * (M1)

Nice: falls BBBike nur mit Start XOR Ziel angegeben wurde, wird der
Titel geändert auf E<quot>BBBike: <startname> (als Start)E<quot> bzw.
das Gleiche mit E<quot>zielE<quot>. Hintergrund: wenn dieses auftritt,
handelt es sich höchstwahrscheinlich um eine Bookmark-URL.

=item * (M3)

Idea by Andreas Mühlhausen: beim Anzeigen der Ausweichroute auch die
Basisdaten (Länge, Fahrzeit, Ampeln) der ursprünglichen Route
anzeigen, sowie ein Diff zwischen den beiden Routen anzeigen.

Implementationsmöglichkeit: Die alte Route wird per CGI-Parameter
E<quot>oldcsE<quot> und als Wert die Session-ID der alten Route
referenziert (done). Daraus kann man zumindest die Länge herausholen (die
anderen Parameter sind vielleicht nicht so wichtig). Außerdem könnte
man ein primitives Diff erstellen: einfach den ersten Unterschied am
Anfang und am Ende nehmen und mit E<quot>Beginn der
AusweichrouteE<quot> und E<quot>Ende der AusweichrouteE<quot> in der
Tabelle kennzeichnen. Ein besserer Diff-Algorithmus ist nicht
notwendig, typischerweise sollte es nur einen Diff-Chunk geben.
Weiterhin könnte man feststellen, ob sich alte und Ausweichroute
überhaupt unterscheiden und einen Erklärungstext anzeigen.

Das geht natürlich nur, wenn Apache::Session* installiert ist.

Note: Einiges ist bereits implementiert: Anzeige der vorherigen Länge,
grafisches Diff bei der googlemaps- und BBBikeDraw::GD-Darstellung.

=item * (E3)

newstreetform.html: qualitaet zum Pflichtfeld machen.

=back

=head1 BBBike and Googlemaps/similar

=over

=item * (H4) (improvement)

Use the suggest AJAX funktion for bbbikegooglemaps.cgi. Possible
alternatives: just for searching for streets (and user has to use the
existing function to set start/goal) or to set start+goal or both.

=item * (H2) (feature)

Use the googlemaps clone on mapserver basis.

=item * (M4) (improvement)

Make it possible to add points to a computed route in
bbbikegooglemaps.cgi. Also make it possible to delete points (last, to
last via, whole) from a computed route.

=item * (H5) (feature)

Routingpräferenzen sollten eingebbar sein. Das kann ruhig das gleiche
Formular wie bei bbbike.cgi sein, und die gleichen Cookies sollten
verwendet werden. Am besten als eingeblendetes Fenster.

=item * (H3) (improvement)

Neben der Anzeige der temp-blockings sollte auch ein Re-routing
möglich sein (Link im info-Fenster). Die alte Route kann dann als
old_coords-Route weiterhin sichtbar sein.

=item * (M3) (improvement)

Info-Fenster für temp-blockings: weitere Informationen anzeigen,
insbesondere die ungefähre verlorene Zeit

=item * (H3) (improvement)

Die gesamte Länge von temp-blockings sollte markiert werden, nicht nur
der erste Punkt. Benötigt eine Änderung in bbbike.cgi (alle Punkte
müssen in LongLatHop erhältlich sein; da diese unterbrochen sein
könnte, müsste die Datenstruktur entsprechend angepasst werden, evtl.
durch ein <separator>-Element und bei der YAML-Ausgabe mit mehreren
Arrays).

=item * (H3) (external bug)

Manchmal geht die Höhe der map im Seamonkey verloren. Dann erzeugt
Googlemaps Routenbilder mit Höhe=NaN, die natürlich kaputt sind. Die
Frage ist, ob ich hier etwas machen kann (außer den Bug zu reporten).

=item * (M1) (improvement)

Die verwendeten Bilder (Start/Zielflagge/pointer) könnten etwas
Antialiasing vertragen.

=item * (H2) (feature)

Die Attribute an der Strecke sollten irgendwie visualisiert werden
können (Kopfsteinpflaster, Radwege...). Dazu müsste bbbike.cgi erst
einmal die entsprechenden Datenstrukturen bereitstellen.

=item * (H2) (feature)

Zusatzdownloads (GPX, Palm) bereitsstellen, vielleicht auch die
Verlinkung zur Printversion, PDF-Generierung und Mapserver.

=item * (H2) (feature)

Bei kleinen Maßstäben könnte man das angezeigte BBBike-Straßennetz per
Polyline-Zeichnung zeigen (Qualität, Radwege, Fragezeichen etc.). Bei
großen Maßstäben wird die Performance des Clients zu schlecht.

=back

=head1 WAP version of BBBike (wapbbbike)

=over

=item * (M3) (feature)

Missing: Advanced form: another step for choosing search preferences

=item * (M3) (improvement)

Using temp_blockings should be automatic (wap searches are normally
E<quot>nowE<quot> searches) (could be problematic for test suite?)

=item * (M3)

Nokia Series 40: lange Straßennamen werden im Select abgeschnitten

=item * (M3)

<b>bla</b> als <b> bla </b> umbauen

=item * (M3)

keine Tabelle für Nokia40/60 für das Ergebnis verwenden

=item * (H3) (feature)

XHTML-Lösung?

=item * (M3)

width=/height= in BBBike Karte angeben, damit Platz reserviert wird

=back

=head1 tkbabybike

=over

=item * (H3)

Convert to be useable with the Tcl::Tk module (beginnings are done...)

=item * (M4)

Tk::PathEntry (used in start/goal entries): -autocompletion does not
work (anymore)?

=item * (M5)

Completion failure for E<quot>StrausbE<quot>. It should be
Strausberger Platz (the first in list), but it is not completed when
leaving the entry.

=back

=head1 Modules

=head2 Route

=head3 Route::Descr

=over

=item * (M4)

Die Routenbeschreibung (wird z.B. bei der PDF-Ausgabe verwendet) ist
nicht lokalisiert. M(...) und Co. verwenden. Es wäre auch schön, wenn
es auch möglich wäre, convert() eine Option für die Sprache anzugeben.
Nur wenn diese fehlt, dann wird automatisch ausgewählt.

-> Route::Descr hat mittlerweile M(...) support! Bloggen!

=back

=head3 Route::GPX

=over

=item new (input: coords, net, maybe also dataset)

=item param_from_cgi:

=over

=item gpxcontent: trk, rte, trk+rte (default), wpt (?)

=item gpxrteno: number of route points, 50 is default, may be 20 or 30
for older GPS devices

=item gpxtrkno: number of track points, by default very high (1024 or
2048?) or even unlimited

=item gpxversion: default 1.1, maybe support for 1.0 (for gpsbabel)

=item gpxwptlen: length of waypoint ids, by default 10

=item gpxwptsuffix: fixed waypoint id suffix

=item gpxwptprefix: fixed waypoint id prefix

=item gpxname: name of gpx file

=item gpxnameauto: boolean; otherwise: generate name automatically
from start and goal point of route

=back

=item as_string/as_gpx

=back

=head3 Route::Simplify

-> and <- should only be used if it is really a crossing. See
Kreuzungen::situation_at_point() for the beginnings of a function
which will tell this (and more).

=head2 GPS

=over

=item * (M5)

Routenbeschreibung für GPS: Falls das gerät Sonderzeichen wie <, > und
^ unterstützt, sollten die Waypoints diese Zeichen zum Anzeigen eines
Abbiegevorgangs verwendet werden.

=back

=head2 BBBikeDraw

=over

=item * (M1)

Wird ImageSuffix irgendwo verwendet? Besser ImageType stattdessen
verwenden, dann kann ich auch bei bbbikedraw MapServer/gif oder
MapServer/pdf sagen.

=back

=head3 BBBikeDraw::GD

=over

=item * (M2)

In BBBikeDraw/GD.pm nach Kommentar bei AREA suchen: Probleme mit den
verschiedenen Netscape-Versionen. Beim Galeon scheint man nicht auf
das Area-Polygon klicken zu koennen, sondern nur in der Naehe davon.
Evtl. das gleiche Problem bei allen Gecko-Browsern. -> AREA/map nutze
ich gar nicht mehr. Vielleicht vorsichtig wiederbeleben? 

=item * (H3)

Auch hier könnte man Labels intelligent positionieren, siehe unten bei
BBBikeDraw::PDF. VectorUtil::intersect_rectangles wird hier aber schon
genutzt... (Werden auf radzeit.de die XS-Versionen genutzt? Beim
syncen kompilieren!)

=item * (M1)

Titel: E<quot>->E<quot> schöner E<quot>malenE<quot> statt Text
verwenden. Theoretisch ginge es auch mit einem Unicode-Pfeil, aber
erst einmal einen TTF-Font mit passendem Glyph finden...

=item * (H2)

Routenbrush: kann man transparente Pixel einfügen, also rot -
transparent - blau - transparent? (Versucht, scheint aber mit gd2.0.33
nicht so schön zu klappen)

=item * (E2)

E<quot>(A -) BE<quot> zu E<quot>-> BE<quot> optimieren -> konkretes
Beispiel finden?

=item * (H2) (external bug)

An den Rändern werden Straßen nicht durchgezeichnet (schön zu sehen:
bbbikedraw.t, Yorckstr. an der Kreuzung Großbeerenstr.).
Wahrscheinlich ein GD-Bug. Nicht bei der SVG-Variante.

=item * (H2) (bug)

Zusammenstoßende Straßenumrandungen weisen manchmal eine große Lücke
auf (schön zu sehen: bbbikedraw.t, Hochkirchstr.). Auch bei der
SVG-Variante.

=item * (H1) (external bug)

Die nördliche Begrenzung der Yorckstr. scheint zu dick gezeichnet zu
sein (2 Pixel statt 1 Pixel?). Möglicherweise ein GD-Problem. Nicht
bei der SVG-Variante.

=item * (H1) (bug)

GD/gif und GD/jpeg können mit Transparenzen in Bildern nichts
anfangen. S-Bahnhofssymbole und Start/Zielsymbole haben einen
quadratischen Rahmen, halbtransparenten Rahmen. Ein Workaround könnte
sein, immer PNG zu rendern und zum Schluss eine Konvertierung PNG ->
GIF/JPEG durchzuführen.

=item * (H2) (external feature)

GD::SVG kann nicht externe Images einbinden, deshalb fehlt das
Zeichnen von S- und (echten) U-Bahnhöfen bei der SVG-Variante, ebenso
die Flaggen.

=item * (H3) (bug)

Straßenlabels werden nicht immer schön gezeichnet, wenn die Straße
nicht geradlinig verläuft. Siehe E<quot>Platz der LuftbrückeE<quot> in
t/bbbikedraw.t -display.

=item * (H2) (feature)

Bei der SVG-Variante fehlt das Labeling komplett.

=back

=head3 BBBikeDraw::ImageMagick

=over

=item * (M3) (feature)

$TTF_STREET (und auch andere) sollte wie in GD.pm gesetzt werden. Oder
besser: in BBBikeDraw.pm eine Funktion dazu definieren und überall bei
Bedarf verwenden.

=item * (H2) (bug)

Zusammenstoßende Straßenumrandungen weisen manchmal eine große Lücke
auf (schön zu sehen: bbbikedraw.t, Hochkirchstr.). 

=item * (M2) (bug)

Draw street outlines above areas. Siehe
Viktoria-Park/Kreuzbergstr./Katzbachstr.

=item * (M3) (feature)

Draw (multi)route.

=item * (M3) (feature)

Draw U/S stations.

=item * (H3) (feature)

Draw street labels.

=back

=head3 BBBikeDraw::PDF

=over

=item * (M5)

Show more fields in route list (just like in web interface). The
comments column for comments_path and maybe comments_misc is
especially important.

=item * (H3) (feature)

Bei Bedarf Karte in mehrere Seiten aufteilen?

=item * (M2)

Überprüfen, ob der Massstab noch auf die Karte passt, ansonsten von
1km verkleinern. Der entsprechende Code müsste auch für andere
BBBikeDraw::*-Module verwendet werden. (in BBBikeDraw::GD und
BBBikeDraw::PDF bereits implementiert, Teile von draw_scale müssten
nach BBBikeDraw.pm ausgelagert werden)

=item * (H3)

Straßenbeschreibung: Labels intelligent positionieren. Das
::PDF-Objekt führt eine Liste der belegten BBoxes. Jede neue
potentielle Text-BBBox wird dagegen geprüft. Auch prüfen, ob man sich
innerhalb der PageBBox befindet. Falls kein Platz ist, werden zunächst
die Himmerlsrichtungen versucht und dann per Verbindungslinie eine
entferntere Position. Kann man Texte auch rotieren? (Ja, mit
L<http://sourceforge.net/tracker/index.php?func=detail&aid=1857255&group_id=2464&atid=302464>!)

Besser: feststellen, wo sich die Route befindet (Pseudo-BBox dafür
erstellen?) und Überlappungen der Route somit vermeiden. Der
Algorithmus für Pseudo-Boxes könnte so aussehen: Box um einen
Linienabschnitt zeichnen. Falls der Linienabschnitt genau horizontal
oder vertikal ist, wird die Breite/Höhe der Box auf 1 gesetzt. Jetzt
muss es eine Entscheidungsfunktion geben, die ausgibt, ob die Box
klein genug ist (Area darf nicht n% größer als die minimal mögliche
Area sein?). Falls nicht, wird die Linie in der Mitte geteilt und der
Prozess wird wiederholt.

Weiterhin sollten Labels immer von Osten nach Westen positioniert
werden, jedenfalls bei links-nach-rechts-Schreibweise. Dadurch wird
die Wahrscheinlichkeit einer Kollision niedriger gehalten, glaube ich.

Oder ganz alternativ: wie sieht die PDF-Unterstützung des Mapservers
aus?

Weiterhin kann man Strasse::short verwenden, wenn es nicht passt.

=item * (M1)

Via im Titel erwähnen: Start -> Goal über Via. Dazu muesste vianame im
CGI übermittelt werden.

=item * (H2)

Untersuchen, ob man mit 8-Bit-GIFs und PDF::Create arbeiten kann. Wenn
ja, dann 8-Bit-Varianten für U/S-Bahnsymbole erstellen. (Oder
vielleicht liegt es an der Transparenz?)

=item * (M5)

Check: wird das richtige gemacht, wenn die Route Landscape und die
Routenliste weiterhin Portrait ist? Veraenderungen bei Route::PDF
notwendig?

=item * (M2)

E<quot>(A -) BE<quot> zu E<quot>-> BE<quot> optimieren (mit leftarrow)

But: it seems that PDF does not know anything about Unicode
characters; and the PDF::Create documentation states that the ZingBats
and Symbol fonts are not useable.

=item * (H3)

Bessere Platzierung der Labels in der PDF-Ausgabe. U- und
S-Bahn-Symbole sind suboptimal, evtl. GIFs stattdessen verwenden (geht
zurzeit nicht, weil PDF::Create anscheinend GIFs mit 8 Bit Farbtiefe
erwartet (extra dafuer erzeugen?). JPEGs gehen, aber ohne Transparenz
(schlecht für das S-Bahn-Symbol), außerdem geht es nur mit xpdf, aber
nicht mit acroread). Wenn Platz ist, könnten auch die Bahnhöfe mit
Labels versehen werden. Wenn ich rotierte Fonts zeichnen kann, dann
auch wichtige Straßen.

=item * (H1)

Migrate to PDF::API2 (beginnings in BBBikeDraw::PDF2, Route::PDF2
should also be created) or another pdf package, which is supported (in
opposite to PDF::Create).

=item * (M4)

Komprimierung von PDFs. Ich habe die PDF::API2-verwendende Funktion in
BBBikeDraw::PDFHeavy abgelegt. Die pdftk-verwendende Funktion sollte
auch dorthin wandern. Weiterhin brauche ich eine Methode can_compress,
eine Factory-Methode compress. Compress => 1 im BBBikeDraw-Konstruktor
sollte angeben, welche Komprimierer man bevorzugt. Falls alles gut
läuft (Testsuite mit vielen automatisch generierten PDFs und
anschließendem Aufruf von xpdf/acroread?) kann ich es auf radzeit
aktivieren.

=item * (H3) (feature)

Ein User hat sich halbtransparente Labels gewünscht, damit man die
Route immer sehen kann.

Folgendes habe ich durch manuelles Manipulieren einer erzeugten
PDF-Datei geschafft. Zuerst GStates für halbtransparent und opak
erzeugen:

    4711 0 obj
    << /Type /ExtGState /ca 0.6 /CA 0.6 >>
    endobj
    4712 0 obj
    << /Type /ExtGState /ca 1 /CA 1 >>
    endobj

Diese müssen nun referenziert werden. Aus dem Objekt:

    3 0 obj
    <</XObject <</Image5 6 0 R
    /Image4 7 0 R
    /Image1 8 0 R
    >>
    /Font <</F2 9 0 R
    /F1 10 0 R
    >>
    /ProcSet [/PDF /Text]
    >>
    endobj
    
habe ich das Objekt:

    3 0 obj
    <</ExtGState<</GS3 4711 0 R /GS1 4712 0 R>>
    /XObject <</Image5 6 0 R
    /Image4 7 0 R
    /Image1 8 0 R
    >>
    /Font <</F2 9 0 R
    /F1 10 0 R
    >>
    /ProcSet [/PDF /Text]
    >>
    endobj

gemacht. Nun stehen /GS3 und /GS1 zur Verfügung. Verwendet werden sie,
um den Rechteckhintergrund halbtransparent zu zeichnen:

    42.9182584753054 79.8199105145409 55.12 10 re
    /GS3 gs f /GS1 gs

Leider scheint es nicht möglich zu sein, dass mit PDF::Create
hinzukriegen. Und auch Monkeypatching scheint kompliziert zu sein.

=back

=head3 BBBikeDraw::Imager

=over

=item * (M3) (bug)

Manche Straßenbegrenzungen laufen spitz aufeinder zu (z.B.
Hochkirchstr., Viktoria-Quartier). Gut zu sehen mit bbbikedraw.t.

=item * (M3) (feature)

Implement some icon drawing: U-Bahnhof, S-Bahnhof, Start/Goal flag ...

=item * (H3) (feature)

Implement street labeling.

=item * (M2) (bug)

Draw street outlines above areas. Siehe
Viktoria-Park/Kreuzbergstr./Katzbachstr.

=item * (M1) (feature)

Verwendung von $self->{_Layers} wie bei BBBikeDraw::PDF, damit das
Layer Stacking insbesondere bei Outlines richtig ist.

=back

=head2 BBBikeDraw::SVG

=over

=item * (H2) (bug)

U/S train stations look strange. See t/bbbikedraw.t -display for an
example.

=item * (M2) (feature)

In smaller map scales, streets should be broader, like in the GD
output.

=item * (M2) (feature)

The route should be drawn differently, e.g. as a dashed red/blue line,
like in the GD output.

=back

=head2 Strassen and Strassen-related

=over

=item * (M4)

The cache files should use Digest::MD5 everywhere if the module is
available (in core since 5.8.0). Maybe the cache filename should be
modified to give a clue about city and user, that is preserve b_de and
user id, digest only the rest of the filename.

=item * (M5)

The behaviour of PreserveComments in Strassen->new is currently
broken. Comments are handled as normal data and occur also if used in
init/next. Better approach: rename PreserveComments into
PreserveCommentsInData and adjust existing scripts. The new
PreserveComments should work like preserving the directives.

=item * (M4)

Weiteres KML-Feature: die wichtigsten Kategorien an einer Route per
Farbe kodieren (z.B. Kopfsteinpflaster rot, gute Strecke grün, Radwege
blau) und in KML einbauen.

=item * (H2)

Das Studium von
L<http://wiki.openstreetmap.org/index.php/De:Map_Features> könnte
interessant sein, um eine Vereinheitlichung der Attributnamen zu
bekommen.

=item * (H2)

Daten direkt von einer Postgres/Mysql-Datenbank auslesen und
darstellen (Strassen::Pg weiterschreiben, Strassen::Mysql neu
schreiben, oder sogar Strassen::DBI?).

=item * (M3)

Alternative implementation of nearest_point with Strassen::QuadTree
(which must be made official!). Use in match_bbd_data.

Strassen::QuadTree could also be used in BBBikeExp.

=item * (H2)

[Do I really need this?]

Mapinfo.pm converter: add new attributes Author, AcquireAuthor,
CreationDate, AcquireDate (maybe better names for AcquireDate?) (from
by directive), FromDate, ToDate (from temporary directive). Implement
first the directive stuff above.

New output scheme: create one mapinfo file per layer. Use real
pen/symbol for lines.

=item * (H1)

AI implementation for detecting street parts (from crossing to
crossing, or just a crossing) from normal text.

=back

=head2 Other

=over

=item * (M1)

Sometime take a look at L<http://search.cpan.org/dist/Geo-Shapelib/>
Only needed if my functions would be too slow one day.

=item * (M1)

Maybe write an BBBikeAreaPlugin for displaying the current route's
area (in a balloon or additional label/toplevel).

=back

=head2 BikePower

=over

=item *

BikePower: Profile laden/speichern, evtl. auch direkt aus bbbike
sichtbar. Erst einmal das Problem mit dem Komma (Linux, Solaris mit
LANG gesetzt) lösen.

=back

=head1 MapServer

=over

=item * (M3)

Use new mapserver features like ANTIALIAS TRUE, WIDTH ... and probably
more.

But: this needs the newest mapserver (4.x, probably 5.x). That means:
I probably need to switch to debian first.

=item * (H4)

Cartography, symbols and Mapserver:
L<http://mapserver.gis.umn.edu/docs/howto/cartosymbols>

=item * (M5)

Funktioniert coordset=start mit dem MapServer unter MSIE6.0? Ich sehe
Warnings im errorlog, das mit dieser Konstellation img.x/img.y fehlt
und somit eine Suche in MapServer gar nicht möglich ist.

=item * (M5)

Was sind die gepunkteten Linien bei der MapServer-Ausgabe von
bbbikedraw.t? -> Steigungen! Nicht bzw. schöner zeichnen! Siehe auch
brb.map-tpl, mount.

=item * (H5)

Verbleibende Issues mit mapserver 4.4.1:

 * Siehe MIGRATION_GUIDE.TXT im mapserver-CVS bzgl. Segfaults und
   einem GD-Patch. Könnte das bei meinen Problemen helfen?
 * Detailanzeige geht sehr oft nicht (Keine Details für diesen Punkt
   vorhanden.)
 * Segfault (?) bei einige Zoomstufen+Layerkombinationen (!!!)
   Problematisch scheint zu sein: U/S-Bahnhof-Symbole als Bild. Wenn
   ein Quadrat/Kreis stattdessen gezeichnet wird, funktioniert es
   nicht. Vielleicht hat das Problem auch was mit den fehlenden
   Bild-Symbolen, s.o., zu tun? Problematische PNGs? Nein, es scheint
   das Label zu sein. Die Bilder werden nicht angezeigt, aber das
   scheint keinen Segfault auszulösen...
 * falls dieser Fehler mit meiner Testsuite nicht getriggert wird:
   nachholen!
 * fast alle Bild-Symbole werden nicht angezeigt (Ausnahme: Fähre,
   Start, Ziel)
 * Einbahnstraßen sind durch E<quot>>E<quot> markiert (das ist aber
   OK).
 * Das Grenzen-Symbol (Punkt Strich) wird nicht gezeichnet.

 * CVS-Version (2006-09-25) scheint viel besser zu funktionieren! Noch
   kein einziger Segfault! Ich habe allerdings auch den GD-Patch oben
   angewandt (der aber mit mapserver 4.4.1 nicht geholfen hat).
 * alpha in Symbolen scheint nicht zu funktionieren, und es gibt wohl
   Bugreports auf Bugzilla. Aber die *noalpha*png-Bilder funktionieren
   nun.

=item * (M4)

Ich sollte maptemplate durch TT oder ähnliches ersetzen können. Ein
erster Schritt wird gerade gemacht: jeder maptemplate-Platzhalter wird
durch [% t(...) %] ersetzt. Dann kann ich mit

   --define template_type=TT

entscheiden, ob ich TT-Templates direkt verwenden oder Maptemplates
bauen will. Die Platzhalter bekommen im TT-Modus ein
E<quot>msE<quot>-Prefix, also aus

   [program]

wird

   [% msprogram %]

(Theoretisch wäre ms.program schöner, aber das kann man (noch) nicht
mit tpage setzen!)

=item * (M2)

bundesstrasse_table_32.png auch hier verwenden.

=item * (H1)

Legend: start/goal flags are to high and may overlap the
E<quot>MarkierungE<quot> circle. Maybe a mapserver problem, fixed in a
new version? Or is the flag simply to large, so it is overflowing? To
solve this, probably I can build my own legend with
L<http://mapserver.gis.umn.edu/docs/howto/html_legend/>.

=item * (H3)

Make it easy to show additional custom layers (with limited mapserver
mapfile functionality???). E.g. integrate somehow
miscsrc/bbd2mapservhtml.pl

=item * (M2)

Zurzeit werden innerhalb Berlin Radroutennummern angezeigt. Soll das
so bleiben? Vielleicht maßstabsabhängig? Leider muss ich in Berlin
(eng) und Brandenburg (viel Platz) unterschiedliche Regeln anwenden.

=item * (H4)

Fehlende Layer: Baustellenzeichen. Die Symbole von BLOCKED_CARRY/_BNP
sind nicht gedreht. Keine Unterscheidung zwischen handicap und
qualitaet. Spezieller Modus für das Erzeugen von Mittelpunkten (e.g.
Schwerpunkt mit Zusatzregeln wie bei den Gewässern). Diese könnten für
Sehenswürdigkeiten verwendet werden.

=back

=head1 Other languages (Java, Tcl, C++)

=over

=item * (H1)

Tcl version is too slow --- startup is fine, but calculation of the
route may be quite slow, up to a minute.

=back

=head1 Distribution/Installation/other development

=over

=item * (H2)

Towards a modern repository system, e.g. git. Idea: one crucial thing
is to merge the RCS and CVS commits. Then go step by step and commit
changes into RCS and CVS in a interleaved manner. Try to find Attic
stuff.

Maybe try to copy RCS ,v files into a CVS repo layout and hope that it
is useful as a CVS repository for git cvsimport? It's probably easier
to do the interleaves thing with the help of git. -> yes, it works!
Try the E<quot>make git-updateE<quot> rule.

Tasks:

 * identify private stuff in the RCS-controlled files.
   git submodule seems to be suited for dealing with multiple
   repositories --- so I can have a private and a public one

 * check for my few branches --- are they dealt in the conversion?

 * check if git cvsimport can deal with deleted/Attic files

 * deal with automated dollar Id: dollar generation

 * what about not-yet-RCS controlled files? just copy over, or put
   everything to git?

=item * (M3)

Try to build a PAR-based distribution. There seem to be some pitfalls,
e.g. I rely on a working $FindBin for getting the data files, which
does not work under PAR. And somehow X11 does not work at all on my
system, I get a

    couldn't connect to display ":0.0" at Tk/MainWindow.pm line 55.

failure.

Also some decisions have to be done, e.g.: which modules should be
additionally included into the .par, include additional external
programs like ghostview, netpbm, gpsbabel.

=item * (H5)

Move Windows distribution to Strawberry Perl 5.10.0.

Prerequisite: have a Strawberry Perl which can actually compile
programs under Vista. Alternative path: use Strawberry Perl + PPMs
from free PPM repositories.

If this is solved, then do the following steps:

=over

=item * The distribution should contain all modules from
Bundle/BBBike_windist.pm. Learn how to create a custom Perl
distribution.

=item * Create the infrastructure to run a specific set of tests (e.g.
everything but cgi, everything interesting for the windows
distribution).

=item * Define a test set for a windows distribution

=item * For a intermediate time, it should be possible to create both
a SiePerl and a Strawberry Perl-based BBBike distribution. This means
the bbbike.tpl.iss needs some switches or there should be another
template file for the Strawberry-based distribution.

=item * It should be possible to have something like a sub-version for
the distribution (like PORTREVISION in FreeBSD or the _<number> bit in
Debian). It's likely that 3.16_2 for Windows will come out before
3.17.

=back

=item * (M1)

There is CDB_Perl on CPAN which could be used as a fallback for
CDB_File.

=item * (H2)

Marek::Pod::HTML seams to have a problem, maybe inherited from
Pod::Checker: 2nd argument set to \*STDERR for parse_from_file does
not work. See my hack in Marek/Pod/HTML.pm in the perl5.8.0 tree.

=item * (M3)

bbbike/html: add bbbike_small.html.spp to CVS, but maybe first convert
to use TT?

=item * (M2)

GNOME-Desktop-Icon in ~/.gnome-desktop/BBBike.desktop mit folgendem
Inhalt ungefaehr erstellen:

    [Desktop Entry]
    Encoding=UTF-8
    Version=1.0
    Type=Application
    Exec=/mnt/suse/usr/bin/perl -e 'for (@INC) { push @_INC, "/mnt/suse$_" } @INC = @_INC; $0= "/mnt/suse/home/slavenr/work2/bbbike/bbbike"; do $0 '
    TryExec=
    X-GNOME-DocPath=
    Terminal=false
    Name[en_US]=BBBike
    GenericName[en_US]=
    Comment[en_US]=

und in
~/.nautilus/metafiles/file:%2F%2F%2Fhome%2Fslavenr%2F.gnome-desktop.xml

    <?xml version="1.0"?>
    <directory><file name="starthere.desktop" icon_position="30,91"/><file name="slavenr's%20Home" icon_position="30,10"/><file name="Trash" icon_position="30,172"/><file name="BBBike.desktop" icon_position="30,260" custom_icon="file:///mnt/suse/home/slavenr/work2/bbbike/images/srtbike32.xpm"/></directory>

=item * (M1)

Das Erzeugen von GIF-Bildern benötigt netpbm, von JPEG-Bildern
die JPEG-Distribution und alle brauchen ghostscript. Eine bessere
Methode wäre WinPhoto (wenn es korrekt und unter Win32 überhaupt
funktionieren würde). Kann ich in die win32-dist einige weitere
Binaries unterbringen (ppmtogif o.ae.).

=item * (M1)

install.pl: Falls Tk nicht installiert ist und PPM vorhanden ist, mit
PPM nachinstallieren. Bei Bedarf eine Reihe weiterer Module
nachinstallieren (siehe Bundle::BBBike).

=item * (M5)

install.pl: Should be tested on another system.

=item * (M1)

FreeBSD-Port anpassen, so daß install.pl verwendet wird. PLIST
von install.pl abhängig machen. -kdeinstall in
Abhängigkeit von HAVE_KDE angeben.

=item * (H1)

Check if it would be feasible to create a BBBike Windows distribution
using L<Perl::Dist>. Note that the current Perl::Dist (0.0.5) has many
very serious problems (up to making the current perl unusable!).

=item *

Secure deployment to radzeit.de:

  * cp on server: bbbike => bbbike~ etc.
  * rsync to ~ version
  * test ~ version (maybe name the test scripts bbbike~.cgi etc.)
  * exch ~ and "" version
  * test "" version

=back

=head1 Tests

=over

=item * (M1)

Cgiinfo in cgi2.t funktioniert leider nicht, weil openURL als zweiten
Parameter nur true oder false zuläßt. Workaround:
Schreiben eines Multiplexers, der per Javascript neue Fenster
öffnet.

=item *

 ... reveals problems if started first time without any cache files ---
 many warnings, sometimes even coredumps on RedHat (?). The 2nd pass is
 usually OK.

Z<>=> maybe the cache build should be done in a separate process. This
 would save memory which probably can't be given back to the process.

 add another full-test rule which calls some tests with their
 -slow/-all/-full/-doit options

=back

=head1 BBBike on the public Server

=over

=item * (H1)

Maybe I should create a tiny wrapper around mapserver-3.6.4, and if
this fails (segfaults) call mapserver-3.6.6. So I will get the nicer
images of 3.6.4, but the fallback safety of 3.6.6.

=item * (E3)

Regularly check the CVS version/latest release of mapserver. Maybe it
will run my mapfile again...

=back

=head1 Documentation

=over

=item * (M5)

There should be a document for design decisions. For example, thoughts
which were developed in this file and later implemented, could go
nearly unchanged into this new document.

The new file could be named F<design_decisions.pod> if no better name
pops up.

=item * (M1)

Eine öffentliche FAQ bereitstellen, vielleicht auch ein
(ChangeE<verbar>B)Log.

=item *

Alle Anregungen von anderen Leuten (z.B. per Mail) hier eintragen.

=back

=head1 Obskures

=over

=item * (H1) (feature)

PerlPlusPlugin ausprobieren und BBBike dafür portieren. Sachen,
die mir dafür einfallen: Ich brauche ein open(), das über
LWP funktioniert (vielleicht mit LWPng?). Ich brauche ein hyperuse und
hyperrequire. Z.B.

    @HYPERINC = qw("http://user.cs.tu-berlin.de/~eserte",
                   "file://tmp");
    hyperuse BBBikeEdit;
    hyperrequire Strassen;

Irgendwo habe ich so etwas schon implementiert gesehen ... suchen!

=back

=head1 Revolutionen

=over

=item * (H1) (improvement)

Ein Widget zum Kartenrendern (CanvasMap) schreiben und alles darauf
umstellen.

=item * (H1) (improvement)

BBBikeContext.pm schreiben: gibt alles aus, was ich so brauche: $os,
Strassen-Objekte, Crossings, Netze etc. Caching bei Belieben
einstellen, evtl. mit Ties arbeiten, die sich selbst umwandeln oder
durchgängig mit Methoden. AutoLoading verwenden.

Z<>=E<gt> Teilweise erledigt BBBikeRouting.pm einige dieser Sachen...

=back

=head1 Sonstiges

=over

=item * Nichts ...

=back
