Archive for the ‘XML’ Category

h1

Landkarten aus dem OSM-Datenmaterial erstellen

20. Mai 2009

Grundlagen

Das Datenmaterial von Open Street Map (OSM) liegt im XML-Format vor. Jeder „Node“ ist mit seinen Koordinaten und verschiedenen zusätzlichen Informationen wie Name, Art des Nodes und Ersteller bis hin zu Öffnungszeiten, erlaubter Fahrtrichtung und vielem anderen mehr erfasst.

Mit einem Script, das selber wiederum im XML verfasst wurde (XSLT) wird dieses Material in eine Verktorgrafik umgewandelt. Als Vektorformat kommt dabei SVG zum Einsatz, das selbst ebenfalls ein XML-Format ist.

Da man recht unterschiedlich aussehende Karten aus ein und dem selben Basismaterial erstellen kann, kommen noch weitere Dateien (Typdefinitionen) bei der Umwandlung zum Einsatz. Diese legen dann beispielsweise fest, welche Deatils angezeigt werden, welches Symbol für zum Beispiel eine Apotheke verwendet wird oder in welcher Farbe Straßen erster Ordnung gezeichnet werden.

Erstellung einer Landkarte

Um eine Karte zu erstellen muss man einerseits sich die Tools dazu besorgen anderseits die XML-Daten für das gewünschte Gebiet.

Installation der Tools

Die Tools sind am einfachsten via svn auf den loaken Rechner zu spielen

$ svn co http://svn.openstreetmap.org/

XML-Daten

Die  XML-Daten für den gewünschten Kartenausschnitt, kann man sich direkt von der Webpage herunterladen mittels der dort via Browser verfügbaren Exportfunktion. Als Format ist klarer Weise XML auszuwählen. Exportiert wird der aktuelle Kartenausschnitt. Falls man größere Kartenausschnitte benötigt, gibt es auch alternative Downloadmöglichkeiten bis hin zum gesamten Datenbestand (=Weltkarte). Wenn man der Datei gleich den Namen data.osm gibt, spart sich im nächsten Schritt das Umbenennen.

Das Komando zur Erstellung einer Karte lautet dann:

$ mv data.osm svn.openstreetmap.org/applications/rendering/osmarender/xslt
$ cd svn.openstreetmap.org/applications/rendering/osmarender/xslt
$ xsltproc osm-map-features-z17-Ingo.xml > map04.svg

xsltproc ist der XSLT-Prozessor (ähnlich dem Perl-Binary das Perlscripte interpretiert); xsltproc ist auf OS X (zumundest ab 10.5) vorinstalliert.

osm-map-features-z17-Ingo.xml ist das von mir leicht veränderte Stylesheet; es teilt dem Prozessor mit, was wie umgewandelt und somit dargestellt werden soll. Dort habe ich z.B. eine Regel ergänzt, die Apartments mit einem von mir definierten Symbol auf der Karte anzeigen.

map04.svg ist die im Verktoformat auszugebende Karte

Und die eigentlichen XML-Daten sind in der Datei data.osm, deren Name ist in dem Stylsheet „hart“ definiert (data=“data.osm“).

Advertisements
h1

SCOM 2007 (OpsMgr) – meine ersten Eindrücke

11. Juli 2007

Microsoft Operationsmanager MOM hat einen Nachfolger bekommen, den System Center Operations Manager 2007 (kurz SCOM2007 oder OpsMgr)

Die Oberfläche

Der System Center Operations Manager (OpsMgr) präsentiert sich mit einer Konsole, von der aus alles erledigt werden kann: Einrichten, Überwachen, Tunen. Er stellt definierte Rollen für Zugriff und Berechtigungen zur Verfügung und bindet sehr intensiv das Active Directory ein. AD wird konsultiert für Discovery, Benutzerkonten, Agent Configuration, die auf OU-Ebene durchgeführt werden kann.

OpsMgr RAM Usage

„Self Tuning Thresholds“ erleichtern die Arbeit des Nachjustierens der Schwellwerte. Erstaunlich ist der Ressourcenverbrauch: 2 GB RAM sind weg wie nix. Wenn ich da an meinen Nagios auf der Soekrisbox denke …

Überwachen

Model-Based Architecture

Mit der Service Modeling Language (SML) würde ein echter W3C Standard mit tatsächlich breiter Unterstützung und offener Spezifikation zur Verfügung stehen.

System Modeling Language

Leider basiert die derzeitige Version des OpsMgr aber auf einer Vorversion dieses Standards. Mit SML könnten Services und Health-Models herstellerübergreifend konstruiert werden. Der Lieferant einer UPS könnte dann für alle SML-basierenden Operations Manager eine Monitoring-Schnittstelle liefern.

xml.png

Zum Teil (sehr zögerlich) machen das auch manche Hersteller, indem sie sogenannte Management Packs zur Verfügung stellen. Diese kommen als sealed packages, also verschlüsselt in den OpsMgr. Die Verschlüsselung hat lt. MS den Hintergrund, dass es sonst laufend zu Fehlern käme, wenn die Admins in dem Management Packs herumbasteln würden. „Soso“, sag ich da nur und frage mich, inwieweit denn diese Managementpacks dann auch für andere Monitoringprodukte verwendbar sind – das ist bis jetzt jedenfalls im Dunkeln.

Enduserperspektive

Eine schöne Sache: Webseiten zum Beispiel können regelmäßig auf deren Verfügbarkeit hin geprüft werden. Sogar nach Schlüsselwörtern in dem empfangenen HTML-Code kann gesucht werden. Das erlaubt ungeahnte Einsatzzwecke: Abfrage bei http://wetter.orf.at und Alarm immer wenn „Regen“ (w/o the quotes, wie es in der MS-Knowledbase heißen würde) gefunden wurde ergibt einen elektronischen Wetterfrosch mit 2 GB Hauptspeicherbedarf.

Im Ernst: Diese als Syntetic Transactions bezeichneten „gescripteten Enduser“ können von verschiedenen „watcher-nodes“ aus ihr Checks durchführen. Das ist ein feine Sache zumal auch komplexere Checks mit „http post“ (Passworteingabe) möglich sind.

Maintanance Mode

Objekte können in Maintanance Mode gesetzt werden. Ab dann werden alle Alerts werden unterdrückt und die Downtime fließt dann nicht in die Verfügbarkeitsstatistik ein.

Interoperabilität

Wie schaut es, abgesehen von dem bisher nicht eingelösten Versprechen sich an einen W3C-Standard zu halten, sonst mit der Interoperabilität aus?

SNMPv2 wird unterstützt, die Version v1 nur mit einem nachzuinstallierenden Patch und v3 wurde angekündigt ohne konkreten Termin. Und tatsächlich, man kann Abfragen (snmp get) starten. Inwieweit diese auch nutzbar sind, wird man sich noch ansehen müssen. Auch SNMP Traps können empfangen und verarbeitet werden.

Bereits der MOM konnte Logfiles von syslog-Clients auswerten. Das kann der OpsMgr auch – nur wie das gehen soll, ist leider nicht so einfach in Erfahrung zu bringen. Wir warten also auf die dazu nötige Doku.

Zusammenfassung

Der OpsMgr ist wohl einfacher als der MOM 2005 zu bedienen: Er hat nur noch eine Konsole und ist weitestgehend in das AD-integriert. Die Self-Tuning-Tresholds sind ein echter Timesaver – aber nur wenn man eine reinrassige MS-Umgebung hat und darauf verzichtet, die darunter liegenden Netzwerkkomponenten überwachen zu wollen.

Theoretisch wäre er offener als der MOM 2005; der W3C-Standard für die Management Packs und SNMP v2, sowie die Integration von Syslogs und Webservices machen Hoffnung. Sehr fraglich ist aber beim derzeitigen Stand der Dokumentation, inwieweit diese wirklich nutzbar sind. Hier tut sich unter Umständen ein interessanter Markt für Firmen auf, die über Knowhow mit alternativen Monitoren wie Nagios haben und für das Thema Interoperabilität aufgeschlossen sind.

Erschreckend finde ich den Ressourcenbedarf. Alleine was an Serverpower nötig ist, um den OpsMgr zu betreiben ist gewaltig. Prüfen würde ich auch, inwieweit die Kommunikation zwischen Agenten und Zentralserver nicht merkbar das Netz belastete; deren Kommunikation erfolgt auf TCP-Basis.

Das eigentliche Drama ist aber die fehlende Dokumentation, ohne die anspruchsvollere Anwendungen, die beispielsweise Netzwerkkomponenten wie Switches und Firewalls mit einschließen, schwer möglich sind.

Link

http://www.w3.org/Submission/2007/SUBM-sml-20070321/