Presentation Open Access

HistoGIS: Vom Punkt zur Fläche in Raum und Zeit

Andorfer, Peter; Schlögl, Matthias


JSON Export

{
  "files": [
    {
      "links": {
        "self": "https://zenodo.org/api/files/8fcd0766-071b-49e1-af9f-b63db66f1471/DHd2019.pdf"
      }, 
      "checksum": "md5:be2a0c1dd7924d7fc1ab0435b55e11a2", 
      "bucket": "8fcd0766-071b-49e1-af9f-b63db66f1471", 
      "key": "DHd2019.pdf", 
      "type": "pdf", 
      "size": 2017278
    }
  ], 
  "owners": [
    38161
  ], 
  "doi": "10.5281/zenodo.2611667", 
  "stats": {
    "version_unique_downloads": 136.0, 
    "unique_views": 236.0, 
    "views": 256.0, 
    "version_views": 256.0, 
    "unique_downloads": 136.0, 
    "version_unique_views": 236.0, 
    "volume": 294522588.0, 
    "version_downloads": 146.0, 
    "downloads": 146.0, 
    "version_volume": 294522588.0
  }, 
  "links": {
    "doi": "https://doi.org/10.5281/zenodo.2611667", 
    "conceptdoi": "https://doi.org/10.5281/zenodo.2611666", 
    "bucket": "https://zenodo.org/api/files/8fcd0766-071b-49e1-af9f-b63db66f1471", 
    "conceptbadge": "https://zenodo.org/badge/doi/10.5281/zenodo.2611666.svg", 
    "html": "https://zenodo.org/record/2611667", 
    "latest_html": "https://zenodo.org/record/2611667", 
    "badge": "https://zenodo.org/badge/doi/10.5281/zenodo.2611667.svg", 
    "latest": "https://zenodo.org/api/records/2611667"
  }, 
  "conceptdoi": "10.5281/zenodo.2611666", 
  "created": "2019-03-27T15:19:33.593322+00:00", 
  "updated": "2020-01-20T17:20:59.889937+00:00", 
  "conceptrecid": "2611666", 
  "revision": 6, 
  "id": 2611667, 
  "metadata": {
    "access_right_category": "success", 
    "doi": "10.5281/zenodo.2611667", 
    "description": "<p>Vortrag:&nbsp;<strong>HistoGIS: Vom Punkt zur Fl&auml;che in Raum und Zeit</strong>&nbsp;</p>\n\n<p>Geographische Angaben k&ouml;nnen in historischen Kontexten nicht als simple 2-dimensionale Daten (L&auml;ngen- und Breitengrade) verstanden werden. Punkte die auf der Karte nur wenige Kilometer voneinander entfernt sind waren vor 500 Jahren wegen geographischer H&uuml;rden (Berge, Schluchten, Fl&uuml;sse etc.) vielleicht ewig weit voneinander entfernt. &Auml;hnliches gilt f&uuml;r politische Grenzen: Vor 30 Jahren waren Orte in Deutschland die heute wenige Autominuten voneinander entfernt liegen durch den eisernen Vorhang voneinander getrennt. Kamzelak (2018) hat es so formuliert: &ldquo;Orte haben eine historisch-politische Dimension, die bei einer &uuml;bergreifenden Registererfassung erst sichtbar zu einem Problem wird. [...] F&uuml;r die Visualisierung von Briefen etwa sind historische Karten ein Desiderat; generell auch Geodaten f&uuml;r Fl&auml;chen. Und alle mit Geodaten versehenen Eintr&auml;ge m&uuml;ssen mit einem Zeitstempel kombiniert sein, denn beispielsweise die Altstadt von Jerusalem ist eben heute nicht am selben Ort wie vor 2.000 Jahren.&rdquo;.</p>\n\n<p>Trotzdem arbeitet eine Vielzahl an Digital Humanities Projekten auch heute noch mit 2-dimensionalen geographischen Angaben. Unserer eigenen Erfahrung nach liegt das Haupts&auml;chlich an der Verf&uuml;gbarkeit von Daten und Services. Moderne Punkt-Daten k&ouml;nnen einfach als geonames, openstreetmap etc. dump heruntergeladen werden bzw. &uuml;ber API Schnittstellen abgefragt werden. F&uuml;r historische Daten existieren diese Services noch nicht vollumf&auml;nglich. Mit Pelagios gibt es ein &Ouml;kosystem an Services f&uuml;r Ortsdaten in der antiken Welt (http://commons.pelagios.org/), das im Zuge des &ldquo;World-Historical Gazetteer&rdquo; Projektes (http://whgazetteer.org/) auch in j&uuml;ngere Zeiten ausgedehnt wird. Abgesehen von diesen notwendigen Initiativen und sehr wertvollen Datens&auml;tzen fehlen den Digital Humanities immer noch Polygondaten zu politischen Entit&auml;ten im Verlauf der Zeit.</p>\n\n<p>HistoGIS hat sich zum Ziel gesetzt genau diese L&uuml;cke zu f&uuml;llen in dem:</p>\n\n<ul>\n\t<li>ein Repository historischer Polygondaten mit einheitlichen Metadaten aufgebaut und zum Download angeboten wird. F&uuml;r dieses Repository werden zun&auml;chst schon existierende Polygondaten eingesammelt, aufbereitet und erst in einem zweiten Schritt f&uuml;r historisch wichtige Zeitspannen neue Polygone erstellt. Dabei setzt sich HistoGIS zun&auml;chst zum Ziel die Periode zwischen dem ausgehenden 18. Jhdt. und 1918 f&uuml;r das Gebiet der KuK Monarchie und des deutschen Bundes abzudecken.</li>\n\t<li>und RestAPI Services zur einfachen Anreicherung historischer Daten mit Hilfe des Repositories angeboten werden. Z.B.: Wo war Punkt X/Y zum Zeitpunkt Z&nbsp;? Die API antwortet mit den Metadaten zu den einzelnen &uuml;berlappenden Polygonen die f&uuml;r den Zeitraum (oder Zeitpunkt) G&uuml;ltigkeit haben. Nehmen wir an: Ein Projekt hat Reiseberichte in seiner Datenbank. Eine Station war Bolzano 1910. Die Geokoordinaten (46.49067, 11.33982) wurden &uuml;ber Geonames gefunden. Schickt man diese mit dem Jahr an die API bekommt man die Metadaten f&uuml;r Bozen Stadt, An der Etsch, Tirol und &Ouml;sterreich-Ungarn zur&uuml;ck&nbsp;.</li>\n</ul>\n\n<p>Eine Fokussierung auf die politischen Verwaltungseinheiten und ihre Grenzen erlaubt es in vielen Bereichen - zumindest f&uuml;r j&uuml;ngere Zeiten - einen Mix aus modernen Daten/Methoden und historischen zu verwenden ohne historisch falsche Daten zu generieren. So k&ouml;nnen bei oben angef&uuml;hrten Beispiel Bozen die Google Maps API, Geonames oder Openstreetmap zur Geolokalisation verwendet werden (die Geokoordinaten von Bozen haben sich ja nicht ge&auml;ndert) und die HistoGIS API um die Eingliederung in die Verwaltungshierarchien zu verbessern (Bozen war 1910 Teil der KuK Monarchie). Dieses Vorgehen reduziert nicht nur den Aufwand f&uuml;r die Erstellung/Kuratierung der Daten drastisch, es erm&ouml;glicht es auch leichter Punkte denen schon L&auml;ngen- und Breitengrade zugewiesen wurden politisch/historisch zu verorten.</p>\n\n<p>Datenmodell, Technische Grundlage und Workflow</p>\n\n<p>Die Modellierung historischer Verwaltungsr&auml;ume hinsichtlich ihrer r&auml;umlichen und zeitlichen Ausdehnungen erfolgte bewusst in einer &auml;u&szlig;erst vereinfachten Art und Weise. Das mittels Python (bzw. GeoDjango) definierte und als Postgresql implementierte Datenmodell besteht in seinem Kern aus den drei Hauptklassen bzw. Tabellen &ldquo;TempSpatial&rdquo;, &ldquo;Source&rdquo; und &ldquo;TempSpatialRel&rdquo;</p>\n\n<p>Ein historischer Verwaltungsraum (Temporalized Spatial Entity oder eben &ldquo;TempSpatial&rdquo;) definiert sich &uuml;ber die im gesamten Datenset einzigartige Kombination der Eigenschaften zeitliche Ausdehnungen (&ldquo;start_date&rdquo; und &ldquo;end_date&rdquo;, Datumsfelder), r&auml;umliche Ausdehnung (&ldquo;geom&rdquo;; Multipolygon) sowie einem Feld &ldquo;date_accuracy&rdquo;, welches Auskunft &uuml;ber den Grad der Genauigkeit der angegebenen Datumswerte gibt. Erg&auml;nzt wird diese Klasse um die Eigenschaften &ldquo;name&rdquo; f&uuml;r, entsprechend den Projektkonventionen einen zeitgen&ouml;ssischen Namen der Entit&auml;t, &ldquo;alt_names&rdquo; f&uuml;r alternative Namen sowie einem Feld &ldquo;additional_data&rdquo;, welches das Speichern arbitr&auml;rer weiterer Daten im JSON Format erm&ouml;glicht.</p>\n\n<p>Das Feld &ldquo;administrativ_unit&rdquo; zeigt auf eine Hilfsklasse (&ldquo;SkosConcept&rdquo;) f&uuml;r kontrolliertes Vokabular, welche in weiten Teilen das SKOS Datenmodell implementiert.</p>\n\n<p>Die Quelle jeder Instanz der Klasse TempSpatial bzw. jeder im Datenset erfassten historischen Verwaltungseinheit wird mit Hilfe der Klasse &ldquo;Source&rdquo; beschrieben. Darin werden URLs zu verwendeten Daten anderer Projekte gespeichert wie auch eine Beschreibung der (weiteren) Datenerhebung und Kuration im Rahmen des Projektes sowie ein Zitationsvorschlag. Jedes Source Objekt ist au&szlig;erdem auch mit einem ESRI-Shapefile verbunden welches Projektintern als prim&auml;res Datenformat dient. Mehr dazu im Abschnitt Workflow.</p>\n\n<p>Die Modellierung beliebiger Relationen zwischen beliebigen historischen Verwaltungsr&auml;umen ist im Datenmodell durch die Klasse TempSpatialRelation grundgelegt. Hier k&ouml;nnen jeweils zwei TempSpatial Objekte (&ldquo;instance_a&rdquo; und &ldquo;instance_b&rdquo;) f&uuml;r eine Zeitspanne (&ldquo;start_date&rdquo; und &ldquo;end_date&rdquo;) in eine typisierte (Verweis auf die bereits erw&auml;hnte Hilfsklasse &ldquo;SkosConcept&rdquo;) Relation gebracht werden. Hierbei ist jedoch weniger an die in Gazetteern &uuml;blichen &ldquo;part of&rdquo; Beziehungen gedacht, sondern an Relationen wie beispielsweise &ldquo;ist Vorg&auml;nger von&rdquo; oder &ldquo;wurde zusammengelegt mit&rdquo;. Allerdings muss darauf hingewiesen werden, dass im derzeitigen Status des Projektes noch keine derartigen Beziehungen erfasst werden.</p>\n\n<p>Die Art und Weise wie eben erw&auml;hnte &ldquo;part of&rdquo; Beziehungen erfasst werden sollen, wurde im Projekt ausgiebig diskutierte, wobei hier neben formal- konzeptionellen Argumenten vor allem auch die konkreten Arbeitsvoraussetzungen und -bedingungen im Projekt ber&uuml;cksichtigt werden mussten.</p>\n\n<p>Schlussendlich wurde eine explizite Modellierung hierarchischer Strukturen der erfassten Verwaltungseinheiten verzichtet, sprich im Datenmodell wird nicht ausdr&uuml;cklich festgehalten, dass z.B. die Verwaltungseinheit A f&uuml;r einen gegebenen Zeitraum, Teil der Verwaltungseinheit B und diese Teil der Verwaltungseinheit D war. Dies erscheint deshalb als zul&auml;ssig, weil im Projekt von der Pr&auml;misse ausgegangen wird, dass, zumindest f&uuml;r den f&uuml;r das Projekt prim&auml;r interessante (Zeit)Raum, die Fl&auml;che der &uuml;bergeordnete Einheit stets die Summe aller ihr untergeordneten Einheiten bildet. Dies erm&ouml;glicht es, dass part-of Beziehungen zwischen TempSpatial Objekten &lsquo;on the fly&rsquo; mit Hilfe von spatial queries und unter Ber&uuml;cksichtigung der jeweiligen Start- und Enddatumswerten berechnet werden k&ouml;nnen. Und dies wiederum erleichtert einerseits die Arbeit der DatenkuratorInnen im Projekt, da diese keine expliziten Verbindungen pflegen m&uuml;ssen, andererseits erm&ouml;glicht dieses Flexibilit&auml;t die Integration anderer Datensatz mit relativ geringem Aufwand.</p>\n\n<p>An dieser Stelle muss jedoch betont werden, dass die bis dato kuratierte Menge an Daten noch nicht ausreicht um konkrete Aussagen hinsichtlich der Belastbarkeit des hier vorgestellten Datenmodells treffen zu k&ouml;nnen. Erste Tests diesbez&uuml;glich fielen jedoch durchwegs positiv aus, sowohl was die Genauigkeit der spatial queries, vor allem aber auch was deren Performanz betrifft.</p>\n\n<p>Die technischen Komponenten des Projektes sind &uuml;berschaubar. Als Storage Layer fungiert eine Postgresql Datenbank mit PostGIS erweiterung. Die Interaktion damit erfolgt &uuml;ber einen mittels dem Python basierten Webframework (Geo)Django implementierten Applikation Layer, wobei mit (Geo)Django, respektive django-rest-framework sowohl die HistoGIS-Webapplikation als auch ein entsprechender REST Webservice implementiert wurde bzw. wird.</p>\n\n<p>Die eigentlich Datenkuration erfolgt davon v&ouml;llig unabh&auml;ngig und unter Verwendung der open source Software Qgis. Bis dato wurden damit vorwiegend bereits existierende Daten harmonisiert und als ESRI shapefiles gespeichert. Das Schema dieser Dateien entspricht dabei weitgehend dem oben skizzierten Datenmodell. Als &lsquo;fertig&rsquo; erachtete Datens&auml;tze (gezippte Shapefiles) werden dann &uuml;ber ein Webformular in HistoGIS als sogenannte &ldquo;Source&rdquo; objekte hochgeladen, entpackt, die Features der Shapfiles als TempSpatial Objekte gespeichert und mit dem Source Objekt verkn&uuml;pft.</p>\n\n<p>Neben der Kuration und Harmonisierung bereits bestehender &ldquo;Vektordaten&rdquo; werden im Projekt aber auch selbst Daten erzeugt. Dazu w&auml;hlt ein Historiker im Team verwertbare (historische) Karten aus, welche idealerweise bereits digitalisiert (gescannt) sind. Die Datakuratorinnen georeferenziert diese Scans (geotiffs) und extrahieren die darin auffindbaren Informationen zu historischen Verwaltungsgrenzen als Vektordaten.</p>\n\n<p>Kartenmaterial bis dato und Ausblick</p>\n\n<p>Bis dato befinden sich knapp 4000 Polygone in der Production Instanz des Systems. Das Anpassen und Einspielen schon vorhandener Polygone wurde mit Daten aus dem Census mosaic Projekt (https://censusmosaic.demog.berkeley.edu/) und dem HGis Archiv (http://www.hgis-germany.de/) begonnen. Damit k&ouml;nnen gro&szlig;e Teile des 19. Jhdts f&uuml;r die Gebiete &Ouml;sterreich-Ungarns und des Deutschen Bundes (inkl. der jeweiligen Nachfolgeentit&auml;ten) bereits abgedeckt werden. Die Daten werden nicht nur technisch aufbereitet, sondern auch inhaltlich von einem Verwaltungshistoriker &uuml;berpr&uuml;ft. HistoGIS implementiert daf&uuml;r ein Ampelsystem. Vom HistoGIS-Team technisch wie inhaltlich &uuml;berpr&uuml;fte Daten werden mit Gr&uuml;n markiert, vom HistoGIS-Team ausgew&auml;hlte Daten die noch nicht &uuml;berpr&uuml;ft wurden mit Gelb und von Usern zur Verf&uuml;gung gestellte, nicht &uuml;berpr&uuml;fte Daten mit Rot (momentan befinden sich lediglich gelbe und gr&uuml;ne Daten im System).</p>\n\n<p>Die Aufbereitung der Daten, wie auch die Entwicklung des technischen Systems schreitet erfreulicher Weise schneller voran als geplant. Es wurde deshalb erst k&uuml;rzlich beschlossen in HistoGIS schon w&auml;hrend der Projektlaufzeit auch Daten au&szlig;erhalb der geplanten r&auml;umlich-zeitlichen Grenzen aufzunehmen.</p>\n\n<p>In unserer Pr&auml;sentation werden wir vor allem das Datenmodell und die RestAPI Schnittstellen des Systems diskutieren und vorstellen.</p>", 
    "contributors": [
      {
        "affiliation": "ACDH-OeAW", 
        "type": "DataCurator", 
        "name": "Piechl, Anna"
      }, 
      {
        "affiliation": "ACDH-OeAW", 
        "type": "DataCurator", 
        "name": "D\u00fcckelmann, Antonia"
      }, 
      {
        "affiliation": "ACDH-OeAW", 
        "type": "DataCurator", 
        "name": "Marckhgott-Sanabria, Peter Paul"
      }
    ], 
    "title": "HistoGIS: Vom Punkt zur Fl\u00e4che in Raum und Zeit", 
    "license": {
      "id": "CC-BY-4.0"
    }, 
    "relations": {
      "version": [
        {
          "count": 1, 
          "index": 0, 
          "parent": {
            "pid_type": "recid", 
            "pid_value": "2611666"
          }, 
          "is_last": true, 
          "last_child": {
            "pid_type": "recid", 
            "pid_value": "2611667"
          }
        }
      ]
    }, 
    "language": "deu", 
    "keywords": [
      "GIS", 
      "Digital Humanities"
    ], 
    "publication_date": "2019-03-27", 
    "creators": [
      {
        "orcid": "0000-0002-9575-9372", 
        "affiliation": "ACDH-OeAW", 
        "name": "Andorfer, Peter"
      }, 
      {
        "orcid": "0000-0003-1451-0987", 
        "affiliation": "ACDH-OeAW", 
        "name": "Schl\u00f6gl, Matthias"
      }
    ], 
    "access_right": "open", 
    "resource_type": {
      "type": "presentation", 
      "title": "Presentation"
    }, 
    "related_identifiers": [
      {
        "scheme": "doi", 
        "identifier": "10.5281/zenodo.2611666", 
        "relation": "isVersionOf"
      }
    ]
  }
}
256
146
views
downloads
All versions This version
Views 256256
Downloads 146146
Data volume 294.5 MB294.5 MB
Unique views 236236
Unique downloads 136136

Share

Cite as