Geodaten in SQL Server Reporting Services – Teil 2: Die Karten – Reporting Services Map Control

23. Februar 2012 3 Kommentare

Miniserie zu Geodaten in SQL Server Reporting Services

  • Intro
  • Teil 1 befasst sich mit der Verarbeitung von Geodaten im Microsoft SQL Server 2008.
  • Teil 2 zeigt die Visualisierung dieser Daten auf Karten innerhalb der Reporting Services.

Zum Erzeugen eines Reports lassen sich wahlweise das Business Intelligence Development  Studio oder der Report Builder 3.0 verwenden. Bei der folgenden Beschreibung setzen wir voraus, dass ein grundlegendes Verständnis über die Arbeit mit SQL Server Reports vorhanden ist.

Wir benötigen in unserem Report eine Data Source und ein Dataset, die alle Spalten aus unserer Tabelle mit einem GeoDatentyp enthalten.

Mit einem Rechtsklick in den Report und ‚Insert‘ -> ‚Map‘ fügen wir ein neues Kartenelement in den Report ein. Das Kontextmenu der Karte erlaubt, die Layer der Karte zu definieren. Wir fügen einen neuen ‚Point Layer‘ sowie einen ‚Tile Layer‘ ein. Über das Kontextmenu der Layer lassen sich die jeweiligen Eigenschaften festlegen. Im Tile Layer lässt sich z.B. festlegen, ob Straßenkarten oder Satellitenansicht gezeigt werden soll. Interessanter sind allerdings die Einstellungen, die wir an dem Point Layer vornehmen müssen.

Zuvor müssen wir aber die Daten aus dem Dataset für unseren Zweck aufbereiten. Dazu machen wir einen Rechtsklick auf das Dataset und wählen ‚Query‘. Der Querydesigner erlaubt uns komfortabel die Daten auszuwählen, die wir auf der Karte anzeigen wollen. Wir wählen sämtliche Spalten der Tabelle und fügen einen Filter auf die ‚trackID‘ hinzu, den wir auch als Parameter des Reports ausweisen. Auf diese Weise bekommen wir sämtliche Punkte eines Tracks zu einer gegebenen trackID.

Danach gehen wir wieder in das Menu der Karte. Im Kontextmenu des Point Layer klicken wir auf ‚Layer Data‘. Im Tab ‚General‘ wählen wir aus, dass unsere Geodaten aus einem ‚spatial field‘ in einem Dataset stammen. Dataset und Spaltenname lassen sich auswählen.

Nun sind wir bereit, den Kartenreport zum ersten Mal auszuführen. Das Ergebnis ist noch nicht hübsch, aber es läuft schon mal.

Als letzten Schritt werden wir nun die Farbe der Punkte in Abhängigkeit eines Wertes aus der Datenbank setzen. In unserem Beispiel bietet sich dazu die Höhe über Normal Null an, deren Wert zu jedem Punkt im Feld ‚ele‘ steht. Dazu gehen wir wieder in das Kontextmenu des Point Layer und wählen dort ‚Point Color Rule…‘. Dort im Reiter ‚General‘ -> ‚Change color rules for Points‘ wählen wir ‚Visualize data by using color ranges‘, dann aus der Dropdown Box ‚Data field‘ das Feld ‚#ele‘. Die Werte für Start, Middle und End color lassen wir auf grün gelb und rot. Im nächsten Reiter ‚Distribution‘ setzen wir das Feld ‚Change distribution options to divide data into subranges‘ auf ‚Optimal‘; die ‚Number of subranges‘ auf 5; ‚Range start‘ auf 0 und ‚Range end‘ auf 1000.

Danach sieht der Report mit Karte wie folgt aus und visualisiert das Höhenprofil der Strecken in fünf Farbverlaufsbereichen von grün bis rot.

Credo

Diese Artikelserie zeigt praktisch, wie sich Geodaten in Microsoft SQL Server einfügen lassen um sie daraufhin in den Reporting Services grafisch anzuzeigen. Ein Punkt, der bei diesem (und ähnlichen) Lösungsszenarien nicht ausser Acht gelassen werden sollte, ist die Frage der Nutzungsrechte für die Online Karten. Als Fausregel gilt, dass die Benutzung der Karten dann kostenlos ist, wenn die Darstellung öffentlich im Internet erfolgt. Wenn die Nutzung in einem geschlossenen Benutzerkreis vorbehalten ist, werden in der Regel Lizenzgebühren fällig.

Wir hoffen, dass der vorgestellte Lösungsansatzt auf Interesse stößt und zur Umsetzung eigener Ideen anregt. Bei weitergehenden Fragen zögern Sie nicht, uns direkt anzusprechen oder einen Komentar in zu diesem Artikel zu posten.

Advertisements

Geodaten in SQL Server Reporting Services – Teil 1: Geodaten erfassen und in den SQL Server einfügen

16. Februar 2012 2 Kommentare

Miniserie zu Geodaten in SQL Server Reporting Services

  • Intro
  • Teil 1 befasst sich mit der Verarbeitung von Geodaten im Microsoft SQL Server 2008.
  • Teil 2 zeigt die Visualisierung dieser Daten auf Karten innerhalb der Reporting Services.

Woher kommen Geodaten und wie müssen diese aufbereitet werden, um sie in den SQL Server einzufügen? Beliebt ist der Satz: Sie alle benutzen doch schon Geodaten in Ihrer Datenbank nämlich in Form von Adressinformationen z.B. von Kunden. Adressdaten müssen bevor sie als Geodaten in der Datenbank noch in den einfachsten Geodatentyp – einen Punkt als Längengrad/Breitengrad umgewandelt werden. Diesen Vorgang nennt man Geocodierung. Er wird z.B. von den gängigen APIs der Onlinekartendienste Google oder Bing unterstützt.

Es gibt sowohl viele frei verfügbare als auch kommerzielle Geodaten im Internet. Viele Beispiele verwenden die ‚Mondial‘ Datenbank der Uni Göttingen, von der auch SQL Skripte für den MS SQL Server existieren.

In diesem Beispiel möchten wir die Geodaten allerdings selber erzeugen – auch um zu demonstrieren, wie sich eigene Geodaten verarbeiten lassen. Es existieren unzählige mobile Anwendungen auf allen gängigen Plattformen, um die eigene Position mittels GPS aufzuzeichnen. Ein gängiges Austauschformat für Geodaten ist das XML basierte .gpx Format. Auf der Routenwebseite für Sportler http://connect.garmin.com beispielsweise lassen sich GPS Strecken als .gpx Datei herunterladen.
Der Inhalt einer solchen Datei enthält folgende XML Elemente, die uns interessieren:

<trk>

<name>Kloster Lluc</name>
<
trkseg>
<
trkpt lon=3.1172070745378733lat=39.808602472767234>

<ele>36.400001525878906</ele>
<
time>2011-10-27T08:03:15.000Z</time>

</trkpt>
<
trkpt lon=3.11720154248178lat=39.80860289186239>

<ele>36.400001525878906</ele>
<
time>2011-10-27T08:03:16.000Z</time>

</trkpt>


Leicht lässt sich hier die hierarchische Datenstruktur erkennen: Ein Track (<trk>) enthält einen Namen (<name>) und Tracksegmente (<trkseg>). Ein Tracksegment enthält mehrere Trackpunkte (<trkpt>) und ein Trackpunkt besitzt die Eigenschaften longitude und latitude (lon,lat) sowie die Elemente Elevation (<ele>) und Time (<time>).

Ein kleines Windows Forms Programm liest eine gegebene .gpx Datei ein und erzeugt daraus die SQL Kommandos, welche dann auf der Datenbank ausgeführt werden und diese mit den entsprechenden ‚geography‘ Werten befüllt. Interessenten stellen wir das Programm incl. Code gerne auf Anfrage zur Verfügung.

Der erzeugte SQL Code sieht folgendermaßen aus:

INSERT INTO [intuiGeoDB].[dbo].[trackpoints([trackID],[ptID],[trkpt],[ele],[time])
VALUES(1,0, geography::STGeomFromText( ‚POINT(3.1172070745378733 39.808602472767234)‘, 4326), 36.400001525878906, ‚2011-10-27T08:03:15.000Z‘)

Die Tabelle ‘trackpoints’ der Datenbank ‘intuiGeoDB’ enthält eine Spalte ‘trkpt’ vom Geodatentyp geography:

Der obige SQL Befehl füllt die Werte trackID und ptID des GPS Punktes sowie die eigentliche Koordinate mittels der Funktion geography::STGeomFromText()in die Datenbank. Die Werte für den Längen- und den Breitengrad werden im Textformat übergeben. Der numerische Wert ‚ele‘ entspricht der Höheninformation über dem Meeresspiegel und kommt wie auch der Zeitstempel ‚time‘ aus den XML Elementen.

Nachdem nun die Geodaten im SQL Server gespeichert sind, zeigen wir im zweiten Teil, wie diese Daten mittels der SQL Server Reporting Services grafisch auf einer Karte angezeigt werden können.

Grafische Kartendarstellung von ortsbezogenen Daten in den Microsoft SQL Server™ Reporting Services

13. Februar 2012 2 Kommentare

Miniserie zu Geodaten in SQL Server Reporting Services

  • Intro
  • Teil 1 befasst sich mit der Verarbeitung von Geodaten im Microsoft SQL Server 2008.
  • Teil 2 zeigt die Visualisierung dieser Daten auf Karten innerhalb der Reporting Services.

 GeodatenRS

Seit der Version 2008 unterstützt der SQL Server von Microsoft Geodaten (auch: räumliche Daten, spatial data) als nativen Datentyp. Damit ergeben sich neue spannende Möglichkeiten der Anwendungsentwicklung. Einfache räumliche Daten existieren bereits in vielen Datenbanken in Form von Adressen oder Ländercodes. Immer mehr mobile Geräte sind mit GPS Sensorik ausgestattet. Dadurch erhalten diese Daten eine immer größere Verbreitung und laden ein, interessante Anwendungen mit ihnen zu erstellen. Viele Webanwendungen integrieren Geodaten in Form von interaktiven Anwendungen, die auf Online Kartendiensten wie Bing- oder Google-Maps dargestellt werden.

In einer kleinen Artikelserie möchten wir hier eine alternative Art zeigen, Geodaten auf Onlinekarten anzuzeigen und zwar mittels SQL Server™ Reporting Services. Die Reporting Services sind ein Modul des SQL Servers um Berichte zu erstellen und zu veröffentlichen. Nähere Infos zu Reporting Services finden sich hier. Informationen zu den Geodatentypen (spatial datatypes) des SQL Server finden sich hier.

Besonderer Dank gilt der BLUESITE GmbH, für die freundliche Unterstützung dieses Artikels.

 

Ankündigung Foodie

31. Mai 2011 1 Kommentar

 intuisoft hat die erste Windows Phone 7 Anwendung erstellt.

In Zusammenarbeit mit der Gesellschaft für optimierte Ernährung mbH in Linden (Ernährungs-Webservices) und Susanne Vetter & Thorsten Schmidt (Grafik) hat intuisoft eine mobile Anwendung (App) zur Suche von Lebensmitteln basierend auf Vorgaben zu Inhaltsstoffen entwickelt. Über den App Marketplace steht Foodie zum Download bereit. Weitere Infos zu Foodie

Kategorien:Windows Phone 7

Ortsabhängige Dienste und Privatsphäre

Kurzer Hinweis:
Zum Thema Privatsphäre und ortsabhängige Dienste (LBS) hat Microsoft ein kleines Dokument veröffentlicht, das auch auf die Risiken und Problematik bei der Benutzung von LBS hinweist.

Location Services and Privacy Fact Sheet

Kategorien:LBS

Oh my Google, wo war ich und warum?

4. Februar 2011 1 Kommentar

Alles was sich um Location Based Services (LBS) dreht ist für mich potentiell interessant und daher habe ich mich schon vor geraumer Zeit auf den Google Dienst latitude eingelassen. Ich werde nun hier nicht in die sehr berechtigte allgemeine Diskussion um die damit zusammenhängenden Probleme bezüglich der Privatsphäre eingehen. Google hat nun eine kleine Zusatzfunktion namens enable history eingeführt, die sowohl die zuvor genannten Bedenken als auch die Möglichkeiten, das eigene reale Leben von Google indizieren zu lassen stark erweitert.
Nach dem Aktivieren der history Funktion merkt sich der Dienst sämtliche örtlichen Positionen des Mobiltelefons und die zugehörige Zeit. Je nachdem welche Methode zur Positionsbestimmung möglich ist, wird entweder GPS, WLAN Positionierung oder Bestimmung über die Funkmasten der Mobilfunkanbieter genutzt. Weiterhin wird versucht, die unterschiedlichen Aufenthaltsorte als Wohnort oder Arbeitsplatz zu interpretieren.
Das sogenannte Dashboard zeigt eine Übersicht und Statistiken zu den gespeicherten Aufenthaltsorten. Interessant ist für Entwickler sicherlich die API, über die sämtliche Positionsinformationen abgerufen werden können. Darüber ließen sich beispielsweise zeitlich oder Örtlich gefilterte Informationen weiterleiten und bestimmte Informationen löschen.
Screenshot

Kategorien:LBS

Artikel im .NET Magazin veröffentlicht

Kategorien:How To, SharePoint