Moorhuhnjagd im Springpfuhlpark (Teil B)

Und nun mal was völlig Neues für den Cachetalk - eine B-Nummer. Erstmalig kommen wir mit einer Viertelstunde nicht mehr klar. Diesmal brauchten wir schon drei davon, um die Stimmung am Springpfuhl vor, während und nach dem Spiel richtig rüberzubringen.

Der Teil B spielt auf der Loge des Hauptstadtstudios. Ähnlich wie bei der Muppet-Show, wo Waldorf und Statler als ergraute Herren Kommentare aus der Loge abgaben, wird von hier aus der Spielverlauf zusammen mit dem Geometer verfolgt, aber auch der eine oder andere Geocaching-Klatsch kommt zur Sprache.


Hätte ich bei den Kollegen aus Schwerin genau aufgepasst statt mich auf die Technik zu verlassen, wäre jeder Podcast auch in einem eigenem Beitrag gelandet. Nur so bekommen iTunes-Abonnenten den auch einwandfrei zugestellt. Also nicht wundern, das wird nun grad nachgeholt. Hier also nun - tätäätäätääää! - die erste B-Nummer. Im übrigen bleiben wir bei der fortlaufenden Nummerierung.

cachetalk020.mp3

Moorhuhnjagd im Springpfuhlpark

Das Ballerspiel aus alten Windows-Zeiten kennen viele sicher noch - für die Geocaching-Variante war die Moorhuhnjagd im Springpfuhlpark eine Premiere.

Die Moorhühner in Form von Reißzwecken mit Reflektorfolie wurden freigelassen und mussten bei diesem Event mit der Taschenlampe erlegt werden.


Im ersten Teil werden die Spielregeln und möglichen Strategien kurz erklärt und die Geocacher stürmen mit ihren Lichtschwertern bewaffnet und durch Zielwasser gestärkt in die Moorhuhnjagd.

cachetalk019.mp3

OpenStreetMap Stammtisch in Berlin

Wie der Zufall es wollte trafen diesmal gleich zwei Dinge zusammen: Im Geocaching-Lexikon war O wie OpenStreetMap dran und grad an diesem Donnerstagabend der Berliner OpenStreetMap-Stammtisch in einem Café am Nordufer in Wedding.

Grund genug, mal bei den Kollegen mit dem anderen Hobby mit GPS-Empfängern vorbeizuschauen! Gibts denn vielleicht irgendwie Berührungspunkte zwischen den Mappern und den Geocachern? Und könnte das mit dem mappen vielleicht auch für den einen oder anderen Geocacher interessant sein?

Darüber talken wir heute live und draußen im Schutze des Raucherzelts - hier waren wir vor lärmenden Weihnachtsfeiern und prasselndem Regen einigermaßen sicher.

cachetalk018.mp3

OpenStreetMap

Was Wikipedia für die Welt der Nachschlagewerke ist soll OpenStreetMap für die Vermessung der Welt sein.

Aber nicht nur Straßen und Orte werden von den ehrgeizigen Amateuren des OpenStreetMap-Projekts kartographiert, auch Sehenswürdigkeiten und andere interessante Orte werden von ihnen mit günstigen GPS-Empfängern erfasst, dann in die Geo-Datenbank des Projekts eingezeichnet und automatisch zu Karten gerendert.

Da die Daten von der Community erhoben werden sind sie frei verfügbar jeder darf sie lizenzkostenfrei einsetzen und beliebig weiterverarbeiten. Auch eine Anfahrtskizze auf der Homepage geht bei OpenStreetMap ohne Lizenz für proprietäres Kartenmaterial.

Zustandsdiagramme

Zustandsdiagramme sind eine Form in UML die den Zustand von Objekten darzustellen und gehören zu den Verhaltensdiagrammen.

Der Zustand ist vor allem dadurch gekennzeichnet, welcher Wert in den Attributen gespeichert ist und gilt für alle Objekte einer Klasse. Da ein Objekt während seines Lebens verschiedene Zustände annehmen kann, ist es interessant darzustellen, durch welche Aufruf von Methoden des Objekts sich welche Attribute ändern.

Die Methoden können entweder direkt aufgerufen werden oder das Objekt bekommt Nachrichten, die dazu führen, dass die Methoden aufgerufen werden. Man kann das Zustandsdiagramm sozusagen als Verfeinerung der Darstellung einer Klasse in UML betrachten.

Alle Zustände sollten einen Namen bekommen der den Zustand verbal beschreibt, wie "aktiv" oder "wartend". Diese Namen sollten auch nicht verwechselt werden können, innerhalb einer Klasse sind sie ohnehin einmalig. Wenn in anderen Klassen ähnliche Zustände erreicht werden können, dann sollten Verben und Adjektive mit einem Begriff ergänzt werden, der deutlich macht wozu der Zustand gehört.

Natürlich kann man gar nicht alle möglichen Zustände abbilden, aber die wesentlichen Zustände des Objekts und wie es dazu kommen kann (Zustandsübergänge, sog. Transitionen "feuern") sollten dargestellt werden.

Ereignisse die zu der Transition führen werden neben den Pfeil geschrieben, der die Zustände miteinander verbindet ("nach einer Sekunde", "täglich um 3:00 Uhr", "bei Druck auf Abbruch-Button"), bei Voraussetzung einer Bedingung kommt diese in eckige Klammern.

Unbedingt darzustellen sind der Anfangszustand und ein oder mehrere Endzustände, insbesondere der Fall, wann das Objekt gelöscht wird.
tweetbackcheck