GIS, UNIGIS und andere Kleinigkeiten

WMS-Verzeichnisse

Peter Schär — Sun, 07 Mar 2010 19:37:41 +0000

Es tut sich was in Sachen WMS-Verzeichnisse. Zumindest sind mir in den letzen Tagen einige WMS-Verzeichnisse aufgefallen:

Geopole: In diesem Verzeichnis sind bereits 400′000 Layer aufgelistet. Es kann über eine Volltextsuche, eine Tag-Cloud oder geographisch gesucht werden. Die Suchtreffer können selbstverständlich in einer Karte betrachtet werden. Es gibt auch einen RSS-Feed mit allen neuen WMS-Diensten. Das Verzeichnis durchforstet das Netz selbstständig nach neuen Diensten. Ich habe jedenfalls kein Formular gefunden, mit dem neue Dienste gemeldet werden können. Über geopole können auch WMS-Dienste überwacht und die Verfügbarkeit und Performance über die Zeit beobachtet werden.
mapmatters.org: Dieses Verzeichnis ist ähnlich aufgebaut wie geopole. Es enthält z.Zt. 111′768 Layer. Auch hier können WMS-Dienste überwacht werden.
GeoMonitoring: Ein Angebot im Rahmen der Geodateninfrastruktur Deutschland (GDI-DE). Es ist ziemlich ähnlich wie die beiden obigen Verzeichnisse, einzig die Suchfunktion ist etwas weniger ausgebaut. Neue Dienste werden jedoch nicht automatisch eingefügt, dies geschieht manuell durch die Mitarbeiter.
geometa.info: Schon seit längerem ist die Suchmaschine der HSR Rapperswil dabei. Sie ist ganz einfach strukturiert. Die Stärke dieses Verzeichnisses ist sicherlich die Vielfalt. Es kann nicht nur nach Geodiensten sondern auch nach Geodaten gesucht werden.
Geocat 2: Auch der Schweizer Metadatenkatalog Geocat kann mit Version 2 Metadaten zu Geodiensten aller Art aufnehmen. So ist z.B. der WMS-Dienst des Geoportals der BGDI dokumentiert.

Diese Entwicklung ist sicherlich erfreulich. Meiner Meinung nach gibt es noch ein Problem im Bereich der Metadaten. Ein kurzes Browsen in verschiedenen Einträgen hat gezeigt, dass nur sehr selten informative und aussagekräftige Metadaten zu den Diensten vorliegen. Meistens sind nur die automatisch ableitbaren Metadaten im GetCapabilities-Dokument verfügbar. Irgendwelche Angaben zu Nutzungsbedingungen, den enthaltenen Daten etc. sind in der Regel nicht zu finden. Das ist natürlich nicht das Problem der WMS-Verzeichnisse. Ich frage mich, ob das GetCapabilities-Dokument der richtige Ort ist, wo die Metadaten beschrieben werden sollen, weil es erstens keine vernünftigen Editoren für diese Metadaten gibt und das GetCapabilities-Dokument häufig (je nach verwendeter WMS-Version) im Browser nicht angezeigt wird, sondern als kryptischer Dateityp zum Download angeboten wird. Das alles ist nicht wirklich befriedigend.

Interessanter ist da der Ansatz von Geocat. Hier werden die Dienste-Metadaten normiert abgelegt (GM03? ISO 19119?) und zwar in derselben Applikation wie die Metadaten zu den Geodaten. D.h. man verwendet dieselbe Oberfläche, die Terminologie ist ähnlich und man kann ausserdem einen Link von den Geodaten zu den Geodiensten herstellen. Erst damit werden vollständige und aussagekräftige Dienste-Metadaten möglich. Dienste-Metadaten ohne einen Link zu den darin enthaltenen Geometadaten machen aus meiner Sicht keinen Sinn. Bei Geocat fehlt allerdings jedoch (noch?) die Monitoring-Komponente. Ich bin der Ansicht, dass der Ansatz von Geocat, sich auf die Normen zu stützen und Metadaten von Diensten und Daten am gleichen Ort mit dem gleichen Werkzeug zu verwalten, die momentan bessere Variante ist.

Aber auch das löst das Metadatenproblem nicht vollständig. Wenn einfach keine Metadaten abgefüllt werden, nützt auch die beste Metadatenlösung nichts. Die öffentliche Verwaltung sollte hier eine Vorbildrolle einnehmen und ihre Geodienste mit Metadaten beschreiben, v.a. da sie auch durch die Geoinformationsgesetzgebung dazu aufgefordert werden.

News von der ESRI Federal User Conference

Peter Schär — Sun, 21 Feb 2010 16:04:44 +0000

Diese Woche ist in den USA die ESRI Federal User Conference zu Ende gegangen. Das Mitverfolgen ist dank Twitter und Blogs jederzeit möglich, ohne selbst vor Ort zu sein. Die aus meiner Sicht interessantesten Infos in Kürze:

ESRI hat eine Partnerschaft mit Amazon verkündet. Damit soll ArcGIS Server 10 auf der Elastic Cloud angeboten werden. Vorerst aber nur für Kunden mit einem Enterprise License Agreement.
Es wurde erstmals die schon früher angekündigte iPhone-Applikation gezeigt. ArcGIS Server 10 wird einerseits eine vorkonfektionierte iPhone-Applikation anbieten (im AppStore) und andererseits eine spezielle API für iPhone. Das ist an und für sich recht spannend. Ich bin jedoch nicht mehr so überzeugt, ob es der richtige Weg ist, im mobilen Bereich nur Angebote für einzelne Plattformen (iPhone oder Windows Mobile) anzubieten und andere Plattformen aussen vor zu lassen. Es entwickelt ja zum Glück niemand Webapplikationen, die nur in bestimmten Browsern funktionieren. In der mobilen Welt sollte das nicht anders sein. Recht drastisch zusammengefasst hat dieses Thema Peter-Paul Koch.
ArcGIS Explorer wird es in einer neuen Version geben (Build 1200) und — das ist neu — auch als Webapplikation “ArcGIS Explorer online“. Da bin ich wirklich gespannt, welche Funktionalität hier integriert ist. Das könnte eine sehr interessante und kostengünstige Alternative sogar zu ArcView werden. Der Wermutstropfen dabei: ArcGIS Explorer online ist eine Silverlight-Applikation.
Was auch schon angekündigt war, ist nun präzisiert worden. Mit ArcGIS 10 wird es mit Python möglich sein, auch die bisher “unberührbaren” MXDs und LYR-Files zu verarbeiten. Davon erhoffe ich mir einen erheblich einfacheren Umgang mit ungültigen Datenquellen und ein sehr einfaches Auslesen von MXD-Informationen (welche Layer sind enthalten etc.). Das wäre ein Quantensprung.
Und last but not least: die Entwicklung von ArcGIS 10 soll 400 Millionen Dollar gekostet haben! Wow! Kann das stimmen oder soll die Zahl die Lizenzkosten rechtfertigen

Wer mehr Informationen sucht, findet diese in den Konferenz-Videos bei ESRI. Schon sehr gespannt bin ich auf den Developer Summit (22.3. – 25.3.). Dort werden mit Sicherheit noch mehr Details zu ArcGIS 10 präsentiert werden.

Arbeiten im Amt für Geoinformation?

Peter Schär — Wed, 10 Feb 2010 12:52:01 +0000

Mein Arbeitgeber, das Amt für Geoinformation des Kantons Bern, hat diese Woche eine Stellenausschreibung publiziert. In dem Team,das für den Betrieb der kantonalen Geodatenbank verantwortlich ist und in dem auch ich mitarbeite, wird die Stelle der Fachverantwortung frei. Eine sehr spannende und interessante Position, eine Bewerbung lohnt sich auf jeden Fall.

Neues Zuhause für mein Blog

Peter Schär — Sun, 07 Feb 2010 18:39:40 +0000

Willkommen im neuen Zuhause meines Blogs. Nach einigen Jahren auf der Freeflux-Plattform habe ich mich entschlossen, meinen Blog auf meine eigene Domain umzuziehen und mal einen Versuch mit WordPress zu machen. Viel Spass!

Swisstopo in der Wolke

Peter Schär — Sun, 20 Dec 2009 13:58:08 +0000

Letzten Freitag habe ich Wabern das Swisstopo-Kolloquium zum Thema “geo.admin.ch, das Geodatenportal des Bundes” besucht: ich war sehr beeindruckt. Bereits der Untertitel der Veranstaltung “Cloud Computing und Web 2.0 im operationellen Betrieb” liess mich aufhorchen. Bisher hätte ich diese Begriffe nicht unbedingt mit Swisstopo in Verbindung gebracht, nun aber schon.

Vordergründig ist map.geo.admin.ch einfach der Mapviewer der Bundesgeodateninfrastruktur (BGDI), d.h. aller Bundesstellen. Er basiert – wie auch andere Angebote der Swisstopo – auf der bewährten WebGIS-Plattform des Bundes (Mapserver, MapFish, PostGIS, TileCache etc.). Er wirkt auf den ersten Blick sehr aufgeräumt und übersichtlich und bietet die bekannten Funktionen (Navigation, Drucken, Suche). Der Viewer kann in einer Beta-Version bereits jetzt ausprobiert werden. Bemerkenswert an der Oberfläche sind für mich zwei Funktionen:

Die Suchfunktion. Es gibt nur eine einzige Suchbox, in der nach Flurnamen (SwissNames?), Orten, Postleitzahlen aber auch Koordinaten gesucht werden kann. Der Anwender muss nicht zuerst entscheiden, was er genau suchen will und sich dann die richtige Suchbox raussuchen, er kann einfach den Suchbegriff eingeben und los geht’s. Wenn das noch z.B. um eine Adressensuche erweitert wird, ist das schon sehr komfortabel.
Die Druckfunktion. Wenn ich die auswähle, erscheint ein kleines Fenster, in dem ich den Massstab auswählen kann. Gleichzeitig sehe ich auf der Karte ein rotes Rechteck, das mir den Bereich anzeigt, der dann auch ausgedruckt wird. Dieses Rechteck kann ich auch verschieben, so dass ich ganz präzise meinen Druckausschnitt definieren kann. In vielen anderen Mapviewern ist das Drucken immer etwas hakelig, weil der angezeigte Kartenausschnitt nie genau mit dem gedruckten übereinstimmt. Das wird hier sehr elegant gelöst. Erzeugt wird ein PDF, das dann abgespeichert und/oder ausgedruckt werden kann. Die Druckqualität ist dabei sehr gut. Selbst wenn ich das PDF auf A3 hochskaliere, erhalte ich eine Ausgabe, die man schon fast als Poster an die Wand hängen kann. Einziger Wermutstropfen ist die Tatsache, dass dem generierten PDF keine Legende beigefügt würde. Das ist sehr schade, da sehr viele der angebotenen Fachdaten ohne Legende kaum zu lesen sind. Da müsste noch nachgebessert werden.

Was ausserdem auffällt, ist die Performance. Der Viewer ist sehr schnell. Das ist auch kein Wunder, ist er doch – wie schon SchweizMobil – komplett gecached. Keiner der Datensätze, die angezeigt werden können, wird dynamisch angezeigt. Alles ist vorgerechnet! Einzig bei der Suchfunktion und beim Tooltip wird wahrscheinlich direkt auf die eigentlichen Daten zugegriffen. Das bringt mich zu den bemerkenswerten Eigenschaften auf technischer Ebene:

Die gesamte Infrastruktur dieses Viewers wird nicht innerhalb der Bundesverwaltung implementiert (z.B. beim BIT), sondern ist komplett in die Cloud von Amazon (EC2 und S3) ausgelagert. Swisstopo hat dort eine ausgeklügelte Architektur aufgebaut, die sehr schnell und einfach “on demand” skaliert werden kann und damit sehr schnell auf Lastspitzen (z.B. bei Pressemitteilungen etc.) reagieren kann. Das scheint mit einem “traditionellen” Rechenzentrum vorderhand nicht oder nur mit viel Aufwand möglich zu sein. Da ausschliesslich OpenSource-Komponenten eingesetzt werden, muss auch kein Gedanken an allfällige Lizenz-Probleme verschwendet werden. Und da auch nur die effektiv benötigte Serverzeit verrechnet wird, halten sich die Kosten in ganz engen Grenzen.
Diese einfach skalierbare Architektur ermöglicht auch das Cachen jedes Datensatzes. Wenn ein Datensatz aktualisiert wird und neu gerechnet werden muss, können einfach einige zusätzliche TileWorker-Server gestartet und zum Rechnen verknurrt werden, ohne dass die übrigen Server damit belästigt werden. Das Rechnen eines Caches wird somit zu einer kontrollierbaren Sache und kann ruhig für jeden Datensatz eingesetzt werden.
Der Viewer ist nicht die einzige Möglichkeit, wie map.geo.admin.ch genutzt werden kann. Wer den Viewer in eine eigene Webseite integrieren will, kann das sehr einfach über die Geoadmin-API erreichen. Darüber kann ich mittels einiger weniger Ergänzungen meines HMTL-Codes einen Mapviewer in meine Webseite integrieren, ohne dass ich dazu einen Programmierer beschäftigen muss. Ein mögliches Anwendungsgebiet, dass die Swisstopo damit anstrebt, sind z.B. Anfahrtsskizzen, die jede Amtsstelle der Bundesverwaltung nach eigenem Gusto bereitstellt. Sei es mit Google Maps, sei es mit map.search.ch oder mit einer selbstgestrickten statischen Karte. Mit der API können solche Anfahrtspläne einfach umgesetzt werden und gleichzeitig auf die Geodaten des Bundes zugegriffen werden. Die API ist momentan für den Einsatz auf Seiten Bundesverwaltung vorgesehen, daher ist auch eine Registrierung notwendig.

Das ganze hat auch noch einen “wunden” Punkt. Im Mapviewer kann nach Geodaten (in der Regel Geobasisdaten des Bundes) gesucht werden. Ausserdem können für jeden angezeigten Datensatz auch die dazugehörigen Metadaten angezeigt und ausgedruckt werden. Das wertet die Daten auf. Allerdings kommen diese Metadaten nicht (oder noch nicht?) aus der kürzlich aufgeschalteten Metadaten-Applikation des Bundes (Geocat 2)! D.h. die Metadaten werden z.Zt. redundant gehalten. Ich bin der Meinung, dass diese Vernetzung noch stattfinden muss. Erst dann kann wirklich von einer Geodateninfrastruktur geredet werden.

Von diesem Manko abgesehen hat mich geo.admin.ch überzeugt. Ein Besuch der BETA-Seite lohnt sich auf jeden Fall. Auch die Folien des Kolloquiums sind sehr interessanter Lesestoff für über die Festtage!

Job im Amt für Geoinformation

Peter Schär — Thu, 17 Dec 2009 10:10:50 +0000

Das Amt für Geoinformation des Kantons Bern (mein Arbeitgeber) sucht per 1. April 2010 eine/n Geomatikingenieur/in ETH oder FH für die Projektleitung “Bezugsrahmenwechsel LV03 – LV95″. Mehr Informationen sind in der offiziellen Stellenausschreibung zu finden.

Geocat 2 ist online

Peter Schär — Mon, 14 Dec 2009 16:00:33 +0000

Letzte Woche wurde mit etwas Verspätung endlich das komplett überarbeitete nationale Geometadatenportal Geocat in Betrieb genommen. Die Vorgängerversion wurde durch eine komplette Neuentwicklung auf Basis von Geonetwork ersetzt. Auf den ersten Blick fällt mir auf, dass das Hauptproblem der ersten Version — die verteilte Suche in verschiedenen Datenbanken — nicht mehr akut ist. Neu sollen Metadaten per CSW-Harvesting von entfernten Servern (z.B. der Kantone) regelmässig repliziert werden. Ob dies jetzt schon der Fall ist, kann ich nicht beurteilen, die Suche funktioniert jedoch ansprechend schnell.

Die Oberfläche wurde natürlich ebenfalls neu gemacht. Wie es scheint, wurde hier das ExtJS-Framework verwendet. Auf den ersten Blick wirkt die Homepage auf mich etwas überladen, sind doch praktisch alle Funktionen (Suche, Kartenfenster, Suche verfeinern etc.) eingebaut. Weniger wäre hier wohl mehr gewesen. Sehr schön ist der RSS-Feed mit den letzten Aktualisierungen, der Feed ist sogar ein GeoRSS-Feed inkl. Geometrie (z.B. BoundingBox).

Die einfache Suche ist schon recht praktisch. Die wichtigsten Abfragen können hiermit recht effizient ausgeführt werden. Sehr gut ist auch die Suche nach Diensten (WMS und WFS), jedoch gibt es hier noch keine Resultate. Der Bereich mit den Suchresultaten ist auch praktisch, etwas gewöhnungsbedürftig ist jedoch die Detailansicht. Die wird als separates DIV-Fenster eingeblendet, was mich nicht ganz überzeugt. Das könnte man doch auch in dem Bereich einblenden, in dem die Suchresultate eingeblendet werden (mit Zurück-Knopf). Ausserdem ist die Detailansicht mit ihren vielen Rahmen recht unübersichtlich. Allerdings ist es natürlich nicht ganz so einfach, einen umfassenden Metadaten-Standard wie GM03 auf einer html-Seite übersichtlich darzustellen.

Alles in allem ist Geocat 2 sicherlich ein Fortschritt im Vergleich zum Vorgänger. Wichtig ist jetzt allerdings, dass auch Metadaten abgefüllt werden, damit Geocat 2 zu recht den Namen “nationaler Metadatenkatalog” tragen kann.

Geoinformationsstrategie des Kantons Bern

Peter Schär — Mon, 14 Dec 2009 10:04:04 +0000

Am 2. Dezember 2009 hat der Regierungsrat des Kantons Bern die “Geoinformationsstrategie des Kantons Bern” beschlossen. Damit wurde der Einsatz von Geoinformation und die bisher gelebte Organisation auf ein tragfähiges Fundament gestellt. Ausserdem wirft die Strategie natürlich auch einen Blick in die Zukunft, indem sie eine Vision formuliert und die Handlungsschwerpunkte für die nächsten Jahre vorgibt. Die Vision ist in drei Kernsätzen festgehalten:

“Geoinformationen steigern die Qualität raumbezogener Prozesse und Entscheide in der kantonalen Verwaltung. Bei räumlichen Fragestellungen bilden sie das zentrale Element der Kommunikation und Interaktion mit öffentlichen Verwaltungen, privaten Institutionen, Firmen sowie Bürgerinnen und Bürgern.”
“Die kantonalen und kommunalen Geoinformationen sind in der Nationalen Geodateninfrastruktur gesamtschweizerisch vernetzt und einfach zugänglich. Die digitalen Daten stellen die verbindliche Grundlage dar.”
“Die Mitarbeiterinnen und Mitarbeiter der kantonalen Verwaltung sind in der Lage, stufengerecht die Geoinformationen in ihre Arbeitsprozesse zu integrieren, mit anderen Daten zu kombinieren und wirkungsvoll zu nutzen.”

Geoinformation definiert sich somit nicht als Selbstzweck, sondern sie will in der kantonalen Verwaltung die Rolle eines wichtigen Werkzeuges einnehmen, damit letztendlich die Effizienz und die Qualität der Entscheide und Prozesse erhöht werden kann. Die Vision wird anschliessend in thematisch gruppierten Leitsätzen (Geodaten, techn. Infrastruktur, Organisation, Mitarbeitende, Finanzen) verfeinert. Am konkretesten wird die Strategie dann in den Zielen. Dort werden wichtige Fakten festgehalten, so z.B. dass Geodaten im Zuständigkeitsbereich des Kantons weiterhin als Public Domain frei übers Internet heruntergeladen werden können.

Alles in allem ist die Geoinformationsstrategie ein gelungener Mix aus Dokumentation des Bestehenden und dem Blick in die nähere Zukunft. Der Text ist so gehalten, dass er nicht nur GIS-Spezialisten anspricht. Dies ist mein persönlicher Eindruck. Es gilt jedoch festzuhalten, dass ich nicht neutral bin, da ich in bescheidenem Rahmen bei der Erarbeitung der Strategie mitgearbeitet habe.

JMeter mit ArcGIS Server

Peter Schär — Wed, 18 Nov 2009 16:50:02 +0000

Das Thema Performance darf beim ArcGIS Server nicht unterschätzt werden. Doch wie misst man Performance? Es gibt von ESRI zwar einige Hilfstools wie MXDPerfStat, das Geodatabase Toolset oder die Map Service Publishing Toolbar. Damit kann man ziemlich gut die Performance einzelner MXDs optimieren und messen. Schwieriger umzusetzen sind grösser angelegte Lasttests (auf mehrere Dienste, mehrere Anwender etc.). ESRI hat hier keine Haus-Lösung anzubieten, das ist aber auch gar nicht nötig, da das Testen von Diensten und Webapplikationen nicht wirklich eine GIS-spezifische Anforderung ist. Deshalb kann hier auf bestehende Tools zurückgegriffen werden.

Eines der überzeugendsten Tools ist sicherlich JMeter, ein Apache-Projekt. Damit können sehr ausgeklügelte und breit angelegte Performance-Tests (z.B. von mehreren Clients aus) gefahren werden. JMeter ist eine Java-Applikation, die somit auf fast jedem Desktop lauffähig ist. Die Dokumentation ist ziemlich gut, so dass hier auf weitere Worte verzichtet wird. Die beste Einstiegshilfe war das Aufsetzen eines JMeter-Proxies, mit dem ganze Sessions im Browser aufgezeichnet werden können. Diese Aufzeichnungen sind perfekte Vorlagen für das weitere Verfeinern eines Testplans. In Bezug auf ArcGIS Server bietet sich die REST-Schnittstelle als Test-Schnittstelle an, da hier alle Parameter einfach über URL-Parameter übertragen werden. Mit JMeter kann aber sicher auch die SOAP-Schnittstelle angesteuert werden. Es kann aber auch eine auf ArcGIS Server aufbauende Applikation wie z.B. WebOffice angesprochen werden. Der erarbeitete Testplan kann gespeichert werden, damit ist garantiert, dass immer derselbe Test ausgeführt wird. Das erleichtert den Vergleich zu verschiedenen Zeiten. Mich hat JMeter überzeugt!

DOM-Punktwolke mit ArcGIS

Peter Schär — Wed, 18 Nov 2009 16:39:15 +0000

Letztens stand ich vor dem Problem eine Punktwolke (DOM für das gesamte Berner Kantonsgebiet) nach ArcSDE zu importieren, ohne genau zu wissen, auf was ich mich da eingelassen hatte. Schon allein die Roh-Daten waren von beeindruckender Grösse. Sie lagen im XYZ-Format vor und nahmen unkomprimiert ca. 130GB Platz ein! Ich öffnete eines der kleinsten Files (30MB) und zählte die Records (Zeilen): 1.2 Millionen! Also ging ich mit einem einfachen Python-Skript durch alle Files durch und zählte alle Records. Das gab die atemberaubende Zahl von 4.3 Milliarden Punkten! Nun ist die OBJECTID in ArcSDE vom Typ Integer32 und damit auf 2³¹-1 (2.1 Milliarden) beschränkt. Da musste ich mich auf die Suche nach anderen Lösungen machen.

ESRI empfiehlt in solchen Fällen die Verwendung von MultiPointZ-Features. Das reduziert die Anzahl Records dramatisch. Glücklicherweise ist im 3D Analyst auch gleich ein äusserst praktisches Tool namens “ASCII 3D to Feature Class” enthalten, mit dem sich ganze Rohdaten-Verzeichnisse auf einen Rutsch in MultipointZ-FeatureClasses umwandeln können. So werden 5000 Features in ein Multipoint-Feature zusammengefasst. Damit resultiert eine Recordzahl von noch ca. 1 Million. Das ist deutlich einfacher zu handeln als 4.3 Milliarden.

Im 3D Analyst gibt es ausserdem noch das Gegenstück namens “Feature Class Z to ASCII“, mit dem man die Features auch wieder rausschreiben kann. Mit diesen Tools werden auch solch gigantische Datenmengen handlebar…