Vor fast zwei Wochen hat in Bern und Lausanne das erste Open Data Camp stattgefunden. Es scheint ein voller Erfolg gewesen zu sein (s. Bericht auf datavisualization.ch). Im Wiki sind die bisher realisierten Projekte aufgelistet. Ein Stöbern ist mehr als lohnenswert. Sehr interessant ist “Gesagt im Parlament“, vielversprechend scheint auch openpolititcs zu werden. Daneben gibt es aber auch Projekte mit Geodaten (des Bundes, OpenStreetMap u.a.). Diese Projekte sind deshalb interessant, weil sich hier ganz andere Entwickler und kreative Köpfe mit Geodaten auseinandersetzen und sie einsetzen als die üblichen Verdächtigen aus der “klassischen” GIS-Ecke. Schon das allein lohnt den Besuch der Seite…
|
||||||
 Morgenberghorn mit Kondensstreifen  Richtung Brienzersee  Rückseite  Gipfelfahne  Dreigestirn |
Aus der heutigen Medienmitteilung des Berner Regierungsrates: “Kredit für Aufbau eines Katasters der öffentlich-rechtlichen Eigentumsbeschränkungen Der Regierungsrat des Kantons Bern hat einen Kredit von 884′000 Franken für den Aufbau eines Katasters der öffentlich-rechtlichen Eigentumsbeschränkungen genehmigt. In diesem Kataster werden alle öffentlich-rechtlichen Eigentumsbeschränkungen wie Bau- und Schutzzonen oder belastete Standorte für die einzelnen Grundstücke zentral und zuverlässig dargestellt. Grundeigentümer, Bauwillige und Investoren erhalten damit wertvolle Informationen für künftige Bauvorhaben. Der Kataster ergänzt das Grundbuch, das nur privatrechtliche Einschränkungen enthält.” Jetzt geht’s an die Arbeit… Letzthin musste ich ein ArcGIS Geoprocessing-Script analysieren, das eine sehr lange Ausführungszeit aufwies. Das Script verbindet verschiedene Layer per Join und schreibt das Ergebnis in eine neue Feature Class raus. Zwar war die betroffene Datenmenge relativ gross (> 400′000 Features), aber das Script lief etliche Stunden (>10). Ein Blick auf den Task Manager zeigte jedoch, dass während der meisten Zeit kaum etwas gerechnet wurde! Nach langer Fehlersuche hatte ich dann das Problem gefunden. Im Script wurde an verschiedenen Orten die folgende Befehlsabfolge ausgeführt: gp.MakeFeatureLayer_management(Input2, TEMP_Layer1, "", "", "") gp.MakeFeatureLayer_management(Input3, TEMP_Layer2, "", "", "") gp.SelectLayerByAttribute_management (TEMP_Layer2, "NEW_SELECTION", "STATUS=1 AND IM_GEBAEUDE=0") gp.AddJoin_management(TEMP_Layer1, "GEBAEUDENAMEPOS_VON", Input1, "OBJECTID", "KEEP_ALL") gp.AddJoin_management(TEMP_Layer1, "" + I1Q + "GEBAEUDENAME_VON", TEMP_Layer2, "OBJECTID", "KEEP_COMMON") gp.MakeFeatureLayer_management(TEMP_Layer1, TEMP_Layer3, "", "", FieldInfo) gp.Append_management(TEMP_Layer3, Output, "NO_TEST") gp.MakeFeatureLayer_management(Input2, TEMP_Layer1, "", "", "")gp.MakeFeatureLayer_management(Input3, TEMP_Layer2, "", "", "")gp.SelectLayerByAttribute_management (TEMP_Layer2, "NEW_SELECTION", "STATUS=1 AND IM_GEBAEUDE=0")gp.AddJoin_management(TEMP_Layer1, "GEBAEUDENAMEPOS_VON", Input1, "OBJECTID", "KEEP_ALL")gp.AddJoin_management(TEMP_Layer1, "" + I1Q + "GEBAEUDENAME_VON", TEMP_Layer2, "OBJECTID", "KEEP_COMMON")gp.MakeFeatureLayer_management(TEMP_Layer1, TEMP_Layer3, "", "", FieldInfo)gp.Append_management(TEMP_Layer3, Output, "NO_TEST") In dieser Konstellation lief das Script viele Stunden lang. Nachdem ich dann – nach langem Trial and Error – den Befehl in Zeile 3 (SelectLAyerByAttribute) auskommentierte und die dort enthaltene Selektion in Zeile 2 in den Befehl MakeFeatureLayer integrierte (als dritter Parameter), lief das Script dann in wenigen Minuten durch. Die meiste Zeit verging nur noch mit dem Hin- und Herschaufeln der Daten von einer DB zur anderen. Das Ergebnis hat mich an und für sich zufriedengestellt. Allerdings bin ich schon etwas erstaunt, dass die eine Konstellation so viel langsamer ist als die andere… PS: Das ganze ist sowohl in ArcGIS 9.2 als auch in ArcGIS 10.0 festzustellen. Angeregt durch diverse Blog Posts (Thematic Mapping, Google Geo Developers Blog, Spatially Adjusted) habe ich einen Versuch mit Googles Fusion Tables gemacht. Mit Fusion Tables können beliebige tabellarische Daten hochgeladen, manipuliert und v.a. visualisiert werden. Der Clou an der Sache ist der, dass auch räumliche Attribute möglich sind. Entweder man lädt die Koordinaten in KML-Notation hoch oder lässt sie durch eine Geokodierung von Fusion Tables erstellen. Anschliessend kann der Datensatz auf Google Maps visualisert werden. Ich habe mir von unserem Geoportal die Berner Gemeindegrenzen (Shapefiles) runtergeladen, mit ogr2ogr in ein KML-File umgewandelt und gleichzeitig die Projektion auf WGS84 (EPSG:4326) geändert. Das resultierende KML-File sieht in Google Earth brauchbar aus:
Anschliessend habe ich das KML-File nach Fusion Tables hochgeladen. Der Upload klappte gut, die Geometrie wurde erkannt, ich konnte die Tabelle visualisieren; allerdings mit einem etwas bescheidenen Resultat:
Die Grenzen sind deutlich ungenauer, es sind auch etliche Sliver-Polygone entstanden. Insgesamt ein unschönes Bild. Scheinbar werden beim Upload die Geometriedaten manipuliert. In der Dokumentation habe ich dazu nichts gefunden. In der dazugehörigen User Group habe ich immerhin den Hinweis gefunden, dass beim Upload alle Koordinaten auf sechs Stellen nach dem Komma gerundet werden. Ob das das Phänomen ganz erklärt, glaube ich nicht. Irgendwie habe ich den Eindruck, dass gewisse Vertices auch ganz weggelassen werden. Der Grund dafür könnte eine Begrenzung der Geometriegrösse sein. Eine Zelle kann nämlich maximal 1 Million Zeichen enthalten. Möglicherweise gerate ich bei grossen Gemeinden in die Nähe dieser Limitation, so dass beim Import eine gewisse Menge an Punkten ausgelassen wird. Da muss ich wahrscheinlich noch etwas Zeit investieren… UPDATE: In der API-Dokumentation habe ich folgendes gefunden: “When displayed on the map, polygons and lines may be dynamically simplified for performance and visual quality. Up to 500 coordinates are used to display each polygon and line. The ten largest-area components of a multi-geometry are shown.” Das erklärt wahrscheinlich die obigen Beobachtungen. Mehr als 500 Vertices pro Feature sind demnach nicht möglich. Letzten Freitag hat an der HSR in Rapperswil der vierte UNIGIS-Tag Schweiz stattgefunden. Nachdem ich an der ersten Austragung teilgenommen hatte, konnte ich es mir dieses Jahr wieder einmal einrichten. Der Tag bestand aus zwei recht unterschiedlichen Teilen. Am Vormittag gab es diverse “klassische” Konferenzvorträge. So hatte auch der Kanton Bern Gelegenheit, sich und seine GI-Aktivitäten zu präsentieren. Das ist meiner Meinung nach gut gelungen. Am meisten Diskussionen hat sicherlich unser Pilotprojekt zur “dezentralen Datenerfassung auf einem zentralen Produktionssystem” ausgelöst, in dem wir zwei Pilotbüros schreibenden Zugriff auf unsere Geodatenbank gewähren, damit sie dort im Auftrag des Kantons Daten zur Richtplanung erfassen können. Wir weichen damit ganz bewusst von der reinen Lehre ab, die besagt, dass basierend auf einem sauberen Datenmodell die Auftragnehmer (Büros) die Daten mit ihren Methoden und Programmen erfassen, dann die Ergebnisse nach Interlis transformieren und dann dem Kanton schicken, der die Interlis-Dateien integriert. Die Erfahrungen der letzten Jahre haben gezeigt, dass ein solches Vorgehen zu sehr hohen Aufwänden bei der Datentransformation bei allen Beteiligten führen. Deshalb versuchen wir hier andere und effizientere Lösungen zu suchen. Ebenfalls vorstellen konnte sich der Kanton St.Gallen. Hier standen jedoch eher organisatorische Themen und Mängel im Vordergrund, die eine geordnete GIS-Entwicklung erschweren. Sehr interessant fand ich auch die Master Thesis von Kathrin Wunderle, die sich mit der Frage beschäftigt hat, wie Landschaftsqualität und -empfindlichkeit gemessen werden können. Das Thema erinnert mich an die Master Thesis meines Arbeitskollegen Marcel Droz, der sich mit dem Begriff Landschaftsästhetik auseinandergesetzt hat. Alles sehr spannende Fragen. Der Nachmittag war dann den Workshops gewidmet. Ich hatte mich für das Thema GeoDesign entschieden. Das taten mir nur wenige andere Teilnehmer gleich, so dass wir den Workshop in kleiner Runde abhielten, was uns jedoch nicht von interessanten Diskussionen abhielt und die Zeit wie im Flug vergehen liess. Der Begriff GeoDesign war mir Anfang Jahres aufgefallen, weil er von ESRI anlässlich des GeoDesign Summit sehr stark gepusht wurde. Ich hatte damals jedoch keine Zeit, mich damit zu beschäftigen, so dass mir die Gelegenheit gerade recht kam. Eine abschliessende Definition konnten wir natürlich nicht finden. Es geht jedoch um die Rolle von Geodaten im Planungsprozess. Momentan ist die Lage so, dass sich Planungsbüros bei ihrer Arbeit immer mehr auf Geodaten abstützen und auch vermehrt GIS-Software einsetzen. Mit Hilfe der Geodaten kann die bestehende Situation sehr genau analysiert werden und der Plan mit Hilfe von GIS-Software präzise gezeichnet werden. GIS unterstützt die Planer jedoch kaum im eigentlichen Planungsprozess. Im Planungsprozess geht es meiner Meinung nach darum herauszufinden, welche Auswirkungen diese oder jene Massnahme hat, um damit einschätzen zu können, welche Massnahmen sinnvoll sind oder nicht. GIS-Software ist hier kaum in der Lage, irgendeinen Beitrag zu leisten. Sie müsste angereichert werden mit verschiedenen Wirkungsmodellen. Wenn der Planer dann eine Massnahme einzeichnet (z.B. eine Schutzzone o.ä.), würden verschiedene Modelle durchlaufen werden und die zu erwartenden Auswirkungen anzeigen. Das ganze sollte nach Möglichkeit interaktiv ablaufen. Solche Wirkungsmodelle müssten natürlich aus der Forschung kommen und es müssten natürlich in der GIS-Software viele verschiedener solcher Modelle zum Einsatz kommen, da es ja natürlich verschiedene Theorien und Ansätze gibt. Ausserdem müsste es dem Planer ermöglicht werden, an den Orten das Modell manuell zu übersteuern, wo er – aus Erfahrung – weiss, dass das Modell nicht stimmen kann. Das ganze ist also eine recht komplexe Angelegenheit, die nicht so ohne weiteres in bestehende GIS-Pakete integriert werden kann. ESRI hat für ArcGIS 10 GeoDesign-Funktionen angekündigt, bei meinen ersten Gehversuchen im ArcGIS 10 Prerelease habe ich davon jedoch noch nichts bemerkt. Ich bin aber mehr als gespannt, ob es GIS-Software geben wird, die die Versprechungen von GeoDesign einhalten kann. Lohnend wäre es allemal, da es letztendlich eine vollständigere Integration von Geodaten in den Planungsprozess bedeuten würde. Insgesamt hat sich der Besuch in Rapperswil für mich v.a. wegen des nachmittäglichen Workshops gelohnt, der sich mit dem direkten Einbezug der Teilnehmer erfreulich vom üblichen “Frontalunterricht” abheben konnte. Am 7. Mai organisiert die HSR bereits zum vierten Mal den UNIGIS-Tag Schweiz. Die letzen beiden Male konnte ich ferienhalber nicht teilnehmen. Dieses Mal sollte es wieder reichen, zumal ja der Kanton Bern im Infoblock “GIS in den Kantonen” vertreten ist. Auch das übrige Programm scheint ziemlich vielversprechend zu sein. Alle Infos inkl. Online-Anmeldung sind auf der Homepage des UNIGIS-Tages zu finden. Gestern ist in der NZZ am Sonntag ein fast ganzseitiger Artikel zum Thema Kataster der öffentlich-rechtlichen Eigentumsbeschränkungen (ÖREB) erschienen. Das ist zumindest in meiner Wahrnehmung das erste Mal, dass dieses so bedeutende Thema auch einer breiten Öffentlichkeit vorgestellt wird. Eine breite Kommunikation ist auch wichtig, weil der ÖREB letztendlich ein Vorhaben ist, das für die Bürger und die Wirtschaft gemacht ist. Der Artikel ist vorderhand noch online abrufbar (Stand: 29.3.2010). Wer sich mehr in die Thematik vertiefen will, dem sei die Lektüre von “Umsetzung des Katasters der öffentlich-rechtlichen Eigen-tumsbeschränkungen im Kanton Bern“, der Masterarbeit meines Amtschefs im AGI empfohlen. Einer der interessantesten ESRI-Events aus meiner Sicht ist jeweils der Developer Summit, werden da doch jeweils die Features der neuen Software-Versionen nicht nur auf ein zwei Folien sondern auch im (technischen) Detail vorgestellt. Dadurch ergibt sich eine recht gute Einschätzung darüber, ob ein neues Feature wirklich einen Zusatznutzen bringt und sich der Umstieg auf eine neuen ArcGIS-Version lohnt. Mittlerweile geht das auch ohne, dass man in Palm Springs anwesend sein muss. Eine Vielzahl an Konferenzteilnehmern haben über ihre Eindrücke per Twitter undBlogs berichtet. ESRI stellt ausserdem viele Videos und Präsentationen sehr schnell ins Netz. Dieses Jahr hat sich natürlich alles um das bevorstehende ArcGIS 10 gedreht. Es hat sich auch gezeigt, dass die Umbenennung von ArcGIS 10 auf 9.4 doch berechtigt war. Es ändert sich doch so einiges. ArcGIS Server Obwohl angekündigt wurde, dass eigentlich 9.3.1 das Server-Release war, gibt es doch auch im Server-Bereich einige sehr interessante Neuerungen:
Aufgefallen ist mir die Tatsache, dass praktisch nichts über das Web ADF zu hören war. Ich gehe davon aus, dass ESRI die Zukunft im Server-Bereich eher bei den neuen Web APIs sieht, als beim Web ADF. Ich habe das Gefühl, dass das Web ADF etwas auf dem Abstellgleis steht. Was auch erwähnt wurde, ist die Tatsache, dass der Server auch in ArcGIS 10 kein 64bit-Produkt sein wird. ESRI hat jedoch bestätigt, dass an einer solchen Version entwickelt wird (development project). Es besteht also Hoffnung. ArcGIS Mobile Hier ist sehr vieles im Umbruch. Bisher basierte ArcGIS Mobile auf Windows Mobile. Das wird sich ändern. ESRI wird neu auch aktuelle Plattformen wie iPhone, Android oder Windows Phone 7 unterstützen. Als erste Plattform startet das iPhone. Hier bietet ESRI eine out of the box-App (via Apples App Store) sowie ein SDK zur Entwicklung eigener Applikationen. Die weiteren Plattformen folgen später. ArcGIS Desktop Hier sind die interessantesten Neuerungen zu finden:
Geodatabase Auch die Geodatabase wird nicht verschont:
Cloud Das buzz word schlechthin war die Cloud. Was auch immer darunter verstanden wird, ESRI bewegt sich stark in diese Richtung. Dies belegen drei neue Angebote von ESRI:
Fazit ArcGIS 10 ist wohl zu Recht ein Major Release. Die vielen interessanten Neuerungen dürften einen Umstieg wohl rechtfertigen. Der Releasetermin ist der Juni (vor der ESRI User Conference). Bereits diese Woche (1. April) soll ein Prerelease erscheinen. Ich bin gespannt. Letzte Woche habe ich im RSS-Feed von Geocat.ch die Metadaten zum CSW-Dienst von Geocat.ch entdeckt. Das wollte ich doch gleich mal ausprobieren. Da in ArcGIS defaultmässig kein CSW-Dienst eingebaut ist (schade!), musste ich den CSW-Client von der ESRI-Homepage runterladen und installieren (ArcGIS Server Geoportal Extension 9.3.1 CSW Clients Update). Das ging problemlos (Anleitungen gibt’s hier und hier). Ich konnte anschliessend im vorkonfigurierten US-Portal suchen. Danach habe ich die Geocat-URL eingetragen und das Profil GeoNetwork CSW 2.0.2 APISO ausgewählt. Das ganze funktioniert jedoch nicht. Ich erhalte regelmässig eine Fehlermeldung (The server committed a protocol version. Section=ResponseStatusLine):
Eine Protokollier-Aktion mit Fiddler im HTTP-Verkehr hat folgendes ergeben. Auf den GetCapabilites-Request erhalte ich das GetCapabilities-Dokument zurück. Der Client nimmt sich dann die dort definierte URL für den GetRecords-Befehl (http://www.geocat.ch/geonetwork/srv/en/csw) und schickt den POST-Request dorthin. Als Antwort erhält er jedoch den HTTP-Status 302, d.h. eine Umleitung (moved temporarily) auf eine andere Adresse (http://www.geocat.ch/geonetwork/srv/eng/csw). Der Client holt sich diese neue Adresse und schickt einen Request dorthin, jedoch keinen korrekten (ohne Parameter), so dass es zu einem Fehler kommt. Entweder der Client kann nicht korrekt mit dem Redirect umgehen oder mit den Geocat-URLs stimmt etwas nicht. Das Fiddler-Log habe ich mal hier angehängt: Hat jemand den CSW-Dienst von Geocat schon erfolgreich testen können? [Update]: Ich habe noch etwas weitergetestet (u.a. mit handgemachten Requests). Der Dienst hat tadellos funktioniert. Der Fehler liegt somit wohl beim ArcGIS-Client, der nicht korrekt mit dem Redirect umgehen kann. Am Swiss eGovernment Forum von letzter Woche in Bern wurde u.a. auch die SuisseID vorgestellt. Die SuisseID ist ein elektronischer Identitätsnachweis; daneben ermöglicht sie auch eine rechtsverbindliche elektronische Unterschrift. Damit soll ein wichtiges Hindernis auf dem Weg zu mehr und besseren eGovernment-Angeboten der Schweizer Verwaltungen beseitigt werden, denn mit der SuisseID sollte es möglich sein, sich bei verschiedenen Online-Angeboten zu authentifizieren und dort auch elektronisch zu unterschreiben. Als Anwender und Bürger muss ich dann nicht bei jeder Online-Anwendung separat anmelden, sondern kann mich dort, wo die SuisseID unterstützt wird, damit anmelden. Das würde die Passwortflut reduzieren. Sehr interessant ist natürlich auch die Möglichkeit der digitalen Unterschrift, so dass ich dann z.B. bei der Steuererklärung alles online machen kann und kein Papier mehr ausdrucken, unterschreiben und abschicken muss. Alles in allem sehr interessante Perspektiven. Der Erfolg der SuisseID ist jedoch noch nicht garantiert. Zunächst braucht es Anwendungen, die die SuisseID unterstützen. Der Bund (SECO) sucht da natürlich Pionierprojekte. Auf der anderen Seite müssen natürlich auch AnwenderInnen da sein, die eine SuisseID besitzen. Da ist der Preis entscheidend. Die definitiven Preise sind noch nicht publiziert, der Bund wird jedoch im Jahre 2010 SuisseIDs mit 65 Franken subventionieren. Das zeigt wahrscheinlich auch, dass eine SuisseID nicht ganz billig ist. Daher wird die Durchdringung nicht allzu schnell vonstatten gehen. Am eGovernment Forum habe ich auch die Vermutung gehört, dass die Verbreitung der SuisseID eher über Arbeitgeber gehen wird, die ihren Mitarbeitern eine SuisseID zur Verfügung stellen werden. Deshalb wäre es doch keine schlechte Idee, wenn die öffentliche Verwaltung, sei es der Bund oder z.B. der Kanton Bern, ihren Angestellten eine SuisseID ausstellen würden. Ich bin schon gespannt, welche Anwendungen ab 1. Mai 2010 die SuisseID unterstützen und werde mir dann vielleicht auch eine SuisseID zulegen. |
|||||
|
Copyright © 2012 GIS, UNIGIS und andere Kleinigkeiten - All Rights Reserved |
||||||
