Hallo christopher_ernestus,
Leaflet unterstützt standardmäßig nur Web Mercator (EPSG:3857). Für die Nutzung von EPSG:25832 (ETRS89 / UTM Zone 32N) müssen Sie das Plugin Proj4Leaflet einbinden, das auf der Bibliothek Proj4js basiert.
Ich habe aber für meine eigene Darstellung Wetzlars die Original Karten georeferenziert. Aber das ist hier off topic.
Viele Grüße
Uli
Hallo Ulil,
Proj4Leaflet habe ich bei diesem Problem nicht ans Laufen bekommen, trotz Hilfe. Aber das ist tatsächlich off topic.
Viele Grüße, Christopher
Ich vergaß noch zu erwähnen: Die einmal erfassten Daten können dann im Prinzip über auch in spezielle lokalen Häuserbuch-Projekten oder (über semantische Abfragen) in historischen Stadtwikis wie das von @HReinhardt initiierte altes-koeln.de eingebunden werden.
Was die historischen Karten angeht (die habe ich ja seit Freitag für Baden, Württemberg und die Schweiz eingebunden): LAGIS hat anscheinend keine offene Lizenz, was es für uns nicht nutzbar macht. Baden-Württemberg scheint da wirklich Vorreiter und Vorbild zu sein und veröffentlicht seine historischen Karten under der Lizenz dl-de/by-2-0. Wie sieht da in Schleswig-Holstein aus @jzedlitz? 
Welche Karten genau für Hessen meinst Du? LAGIS hat da vielleicht das Problem, dass das Teile der Daten von der Hessischen Verwaltung für Bodenmanagement und Geoinformation beziehen. Aber wenn man dort nachsieht, scheint mir diese Anangabe Metadaten scheint für eine offene Lizenz zu sprechen.
Die Urkataster+ Karten aus dem 18. Jh. sind frei, da sie aus dem Staatsarchiv stammen. Darauf ist zu achten. Die neueren (ab ca. 1870) aus den jeweiligen Katasterämtern stehen anscheinend nicht unter freier Lizenz.
Ich habe das mit dem unklaren Bau-/Abrissdatum mal ausprobiert:
Datum der Gründung, Entstehung, Erbauung
Unbekannter Wert
Noch kann Domus das nicht richtig anzeigen, aber in Wikidata kann man das modellieren.
Cool, das schau ich mir mal an.
Das Matching zwischen OpenHistoricalMap und Wikidata ist bei Daten generell ein bisschen tricky, OHM verwendet das EDTF-Format für nicht-punktförmige Daten.
Ah, interessant, aber der WMS-Link bezieht sich anscheinend auf die neueren topographischen Karten. Bei den alten Karten ist oft (ich bin mir nicht sicher, ob das in Hessen auch so ist) das Problem, dass die Bilddaten zwar gemeinfrei sind, aber die verzerrten und georeferenzierten Karten-Kacheln nicht.
Ja, so war der Hinweis gedacht: Alles, was ich über Wikidata geschrieben habe, geht in WikiData, aber es ist noch nicht in Domus umgesetzt. Dass in Domus unter „Erbaut“ hier eine URL erscheint, ist der unerwünschte Nebeneffekt des jetzigen Ist-Zustands, und nicht das Erwünschte, nehme ich an?
2 „Gefällt mir“
Ja, der Link auf das geoportal.hessen.de bezieht sich vorwiegend auf neuere Karten, allerdings bis herunter zur Ebene der Liegenschaftskarte.
Für das 19. Jahrhundert werden für Hessen die verschiedenen topographische Landesaufnahmen angeboten:
Dort steht zwar nicht direkt etwas von freier Lizenz, aber es wird ausdrücklich nahegelegt, diese in eigene Web-Anwendungen einzubinden.
Die Auflösung dieser topographischen Karten ist natürlich für ein Projekt zur Häusergeschichte zu ungenau, oder was meinst Du?
Auf Häuserebene wäre dann eher das mehrfach genannte Projekt Urkataster+ interessant. Hier stehen die meisten Karten ab 1870 nicht unter freier Lizenz, weil sie nicht aus den Staatsarchiven stammen. Aber für das 18. Jh. und für 1820 (im Falle Wetzlar) sind die Karten als WMTS-Dienste frei.
1 „Gefällt mir“
Und damit ist man weitgehend auf den gregorianischen Kalender und Zeiträume nach dessen Inkraftsetzung fixiert. Als Notlösung spricht EDTF von der Nutzung des “Proleptic Gregorian calendar”. Aber zumindest ist das klar.
Im GOV hat man gar keine Information über den verwendeten Kalender. Dort gilt: Eine Datumsangabe erfolgt entsprechend der Quelle und damit entsprechend dem zum gegebenenen Zeitpunkt am gegebenen Ort gültigen Kalender, welcher auch immer das gewesen sein mag. GOV kennt “ab”, “bis” und “ab bis”, sowie unscharfe Zeitangaben wie Jahr ohne Monat und Tag.
In Genealogieprogrammen wird meist eine an GEDCOM ausgerichtete Notation von Zeitpunkten und Zeiträumen verwendet. Es werden diverse Kalendersysteme unterstützt.
Es treffen hier also vier Welten zur Beschreibung von Zeitpunkten und Zeiträumen aufeinander, was die Übergänge nicht trivial macht:
- Wikidata
- OHM
- GOV
- GEDCOM
Es gibt in den Geschichtswissenschaften (NFDI4memory?) Bestrebungen für ein Datenmodell, das den Austausch von Datumsangaben und Zeitspannen vereinheitlichen soll, aber das ist noch nicht fertig. Ich habe da vor einiger Zeit einmal einen ersten Entwurf kommentiert. Eigentlich ist das ein Thema für eine Doktorarbeit.
1 „Gefällt mir“
Siehe Peter Becker, kleio: ein Tutorial (=Halbgraue Reihe zur Historischen Fachinformatik, A1), Göttingen 1989, S. 64-67. Dort wird der Datentyp tempora erklärt.
Korrekte Formen sind z.B. 1.7.1743, 0.0.1743, KAL MAR 1728, 5 Frum 3, 13 Tam 5127, 6 Rabil 1145, 1.2.1750-, 31.12.1582AS, 1.1.1768PAS, 1.2.1750-1.3.-1750.
Ausführlicher das spätere englischsprachige Handbuch hier. Einschlägig sind u.a. date und chronology.
Neben der Zeitkomponente ist für das hier diskutierte Vorhaben natürlich noch die Raumkomponente wichtig (und die hier noch nicht ausreichend diskutierte Ereigniskomponente). Ich habe Claude gebeten etwas zu den Ortskoordinaten zusammen zu stellen. Sehr ihr es auch so?
Koordinatensysteme in den vier Systemen
Wikidata
Eigener strukturierter Datentyp „globe-coordinate“: Dezimalgrad-Werte für Breite/Länge, eine explizite Präzisionsangabe (in Grad) sowie ein Referenz-„Globus“ (meist Erde, aber auch andere Himmelskörper möglich). Aktuell wird für die Erde ausschließlich der WGS84-Standard unterstützt – andere Systeme (ETRS89, lokale Landesvermessungssysteme) sind nicht vorgesehen.
OHM (OpenHistoricalMap)
Baut auf dem OSM-Datenmodell auf: Knoten werden intern als Dezimalgrad-Koordinaten im WGS84-System gespeichert (EPSG:4326) – genau wie bei OpenStreetMap. Für die Kartendarstellung im Browser (Kachel-/Tile-Rendering) wird daraus aber auf Web Mercator (EPSG:3857) projiziert – das ist aber nur eine Darstellungsschicht, nicht das Speicherformat.
GOV
Dezimalgrad mit „°N“/„°S“/„°O“/„°W“-Notation direkt im Quicktext. Ein explizites Datums-/Referenzsystem-Feld gibt es im Datenmodell nicht – GOV geht implizit von WGS84 aus (weil heutige Koordinaten meist per GPS/Kartendienst ermittelt werden), hält das aber nirgends fest. Negative Vorzeichen sind nicht zulässig, stattdessen wird die Himmelsrichtung ausgeschrieben.
GEDCOM
MAP/LATI/LONG-Tags mit Vorzeichenbuchstabe (N/S/E/W) und Dezimalgrad, Auch hier: kein Datums-/CRS-Feld im Standard – WGS84 wird nur durch Konvention unterstellt, ist aber nicht erzwungen.
Gemeinsamkeit: Alle vier Systeme arbeiten mit unprojizierten geografischen Koordinaten (Breite/Länge in Grad) und setzen WGS84 voraus – bei Wikidata explizit deklariert, bei OHM/GOV/GEDCOM nur implizit. Das ist strukturell dasselbe Problem wie beim fehlenden Kalenderfeld bei GOV/EDTF: Ohne explizite Deklaration kann bei älteren oder aus anderen Quellen übernommenen Koordinaten (z. B. aus Gauß-Krüger/DHDN-Katastervermessung) ein Versatz von mehreren hundert Metern entstehen, wenn man WGS84 unterstellt, es aber nicht war.
Bleibt die letzte Dimension: Ereignisse in der Geschichte eines Hauses, etwa Bau, Brand, Abriss. Und der Bezug zu Menschen als Eigentümer, Architekten oder Bewohnern. Wie sind die vier Systeme da aufgestellt?
Claude meint dazu:
Wie die vier Systeme mit Gebäuden, ihrer Geschichte und dem Bezug zu Personen umgehen
Wikidata
Ein Gebäude ist ein vollwertiges Element (Item) mit eigenem Beziehungsgraphen. Für Bau/Ereignisse gibt es inception (Baubeginn/Entstehung) und dissolved, abolished or demolished date für den Abriss, dazu einen Zustandswert wie „demolished or destroyed“. Für Wiederaufbau nach Brand gibt es explizite Verkettung über structure replaces/structure replaced by – so lässt sich eine Abfolge von Gebäudezuständen als Kette von Items abbilden. Personenbezüge sind eigene, datierbare Aussagen direkt am Gebäude-Item: architect (Architekt), owned by (Eigentümer, mit start/end-Zeitqualifikatoren), occupant (Bewohner/Nutzer), commissioned by (Auftraggeber), creator. Damit lässt sich pro Zeitabschnitt genau festhalten, wer wann Eigentümer oder Architekt war – als strukturierter, abfragbarer Graph.
OHM (OpenHistoricalMap)
Ein Gebäude ist primär eine Geometrie mit Lebensspanne: start_date/end_date sowie Lifecycle-Präfixe (demolished:, disused:, abandoned:, razed:) markieren Bau- und Abrisszeitpunkt bzw. Zwischenzustände. Ein Wiederaufbau nach Brand wird typischerweise nicht als eine fortlaufende Identität, sondern als mehrere überlappende Objektversionen mit eigenen Start-/Enddaten modelliert, die über eine sogenannte „chronology relation“ (Beziehung zwischen aufeinanderfolgenden Repräsentationen) verknüpft werden. Personenbezüge existieren nur als lose Freitext-Tags (z. B. architect=Name), nicht als strukturierte, datierte Beziehung zu einer eigenen Personen-Entität – dafür muss man über ein wikidata=*-Tag auf das entsprechende Wikidata-Item verweisen, das dann die eigentliche Personenverknüpfung liefert. Eigentümer/Bewohner werden in OHM praktisch nicht modelliert – das liegt außerhalb des kartografischen Zwecks.
GOV
Der Objekttyp „Gebäude“ existiert, ist aber bewusst schlank: Er trägt dieselben allgemeinen Eigenschaften wie jedes GOV-Objekt (Name, Typ, Position, Quellenangaben, Zugehörigkeit zu einem Ort). Ereignisse wie Bau, Brand oder Abriss sowie Personenbezüge (Eigentümer, Architekt, Bewohner) gehören nicht zum GOV-Eigenschaftskatalog. Das ist kein Zufall, sondern Konzept: Wie du selbst schon im CompGen-Artikel zu Häuserbüchern gefunden hast, bleibt GOV bewusst auf die geografisch-administrative Verortung beschränkt (Ort/Hof mit Koordinaten), während die eigentliche „Häuserchronik“ mit Eigentümern und Bewohnern in einem externen, genealogisch ausgerichteten System (Ortsfamilienbuch) gepflegt und lediglich über einen Link mit dem GOV-Objekt verbunden wird.
GEDCOM
Hier gibt es überhaupt keinen eigenständigen „Gebäude“-Record. Das Modell ist strikt personenzentriert: Bau, Brand oder Abriss eines Hauses lassen sich nur indirekt als Ereignisse an einer Person anhängen (z. B. PROP/Property-Fakt, RESI/Wohnort, jeweils mit PLAC und DATE), nicht als Historie eines eigenständigen Objekts. Wer mehrere Personen (Eigentümer, Architekt, Bewohner) mit demselben Hausereignis verknüpfen will, ist auf Erweiterungen angewiesen – etwa _LOC-Records (GEDCOM-Addendum). Das erlaubt dann hierarchische Ortsdatensätze und die Modellierung des Gebäudes als durchgängige Entität mit eigener Geschichte.
Für dein eigentliches Interesse (Hauschronik mit Bau/Brand/Abriss und Eigentümer/Architekt/Bewohner) heißt das: Keines der vier Systeme deckt das allein ab. Die praktikable Kombination – die im CompGen-Umfeld ja auch schon angedacht wird – wäre: GOV für die Georeferenz und historisch administrative Einordnung des Standorts, Wikidata für enzyklopädisch belegte Bau-/Architekturdaten, OHM für die reine geometrische Existenzspanne des Gebäudes auf einer historischen Karte, und ein Ortsfamilienbuch/Häuserbuch (auf GEDCOM-Basis mit _LOC-Ortsdatensätzen) für die eigentliche personenbezogene Chronik von Eigentümern und Bewohnern sowie die Haus-bezogenen Ereignisse.
Sehr gute Analyse!
Keines der vier Systeme deckt das allein ab.
Ganz genau! Das war ja auch meine ursprüngliche Motivation - ich bin nach wie vor von OHM begeistert, habe aber diese Limitation bald festgestellt.
Die praktikable Kombination – die im CompGen-Umfeld ja auch schon angedacht wird – wäre: GOV für die Georeferenz und historisch administrative Einordnung des Standorts, Wikidata für enzyklopädisch belegte Bau-/Architekturdaten, OHM für die reine geometrische Existenzspanne des Gebäudes auf einer historischen Karte,
Einverstanden bis hierher 
und ein Ortsfamilienbuch/Häuserbuch (auf GEDCOM-Basis mit _LOC-Ortsdatensätzen) für die eigentliche personenbezogene Chronik von Eigentümern und Bewohnern sowie die Haus-bezogenen Ereignisse.
Die Grundidee von Domus ist, das eben auch in Wikidata abzubilden. Natürlich unter der Einschränkung, dass Wikidata nicht für „original research“ geeignet ist, die Daten müssen also woanders verfügbar sein. Das kann zum Beispiel eines der historischen Adressbücher sein. Es könnte aber auch einfach ein Häuserbuch im GenWiki sein. Oder halt eine Archivsignatur.
Natürlich habe ich trotzdem noch meine eigenen, mit der Genealogie verknüpften Daten, die mit Ortsdatensätzen, Personen und Ereignissen verknüpft sind. Die leben bei mir natürlich in einer Gramps-Datenbank, was aber nicht allzu weit von GEDCOM weg ist.
Der springende Punkt ist, dass es solche Häuserlisten im GenWiki gibt, oder als Excel-Tabellen oder … Alles aber nicht gut für den Austausch geeignet. Wenn es gelänge das besser zu machen, wäre viel erreicht. Ich denke auch, dass man die Informationen in Wikidata unterbringen kann. Die Hürde ist die Erfassung und Präsentation für “normale” Nutzer. Da ist Domus Gold wert! Der andere Ansatz ist die Erfassung in einem Genealogieprogramm. Das geht auch und kann dann als Online-OFB ausgetauscht und präsentiert werden (wenn man Ortsdatensätze nutzt).
Wikidata ist kollaborativ, ein Genealogieprogramm kann es sein (webtrees oder GrampsWeb), muss aber nicht. Wikidata ist für die Modellierung der Häuser gut, bei der Modellierung aller jemals lebenden Menschen (Weltbaum) sehe ich Wikidata eher nicht. Also wird es irgendwo eine Grenze geben. Meine Idee ist es, mich als Genealoge auf die Menschen zu konzentrieren und den Rest kollaborativ in GOV und Wikidata zu erledigen und dann im Genealogieprogramm zu nutzen. Aber ich will zukünftig erkennen können, dass die Taufpaten eines Kindes die Nachbarn waren oder der Besitzer des Mietshauses der Eltern. Das findet man bisher nicht so leicht heraus.
1 „Gefällt mir“
In Wikipedia würde das Angeben einer Archivsignatur als (einzige) Quelle von vielen Admins sofort als „original research“ zurückgewiesen werden und auch jegliches Wiki wird ja als Quelle abgelehnt. Ich kenne mich mit WikiData nicht so aus, hoffentlich ist es dort anders.
Ja, bisher ist mir da noch nichts Restriktives begegnet. Als Quelle kann man auch mal Wikipedia nutzen. Ich habe einen Schwung Bauernhöfe mit Domus angelegt. Die Eigentümer und Bewohner werde ich lieber in webtrees pflegen, aber ich habe zum Ausprobieren auch mal einen (verstorbenen) Verwandten direkt in Wikidata zugeordnet.
Hallo insgesamt,
ich habe einige Ideen für Verbesserungen für DOMUS ( @DavidStraub ). Es es gibt aber ein Sonderproblem bei historischen Gebäuden das man irgendwie angehen sollte meiner Meinung nach. Das ist vor allem, dass man in einer Quelle eine Adresse findet die man über diverse Wege erstmal zuordnen muss, da sie sich geändert hat (Straße + Hausnummer). Ich kann hier für einige Recherchevarianten in Berlin sprechen, wenn die Hausnummer und Straße nicht bekannt sind. Vielleicht kann man eine solchen Prozess in DOMUS abbilden, vereinfachen und gar generalisieren.
Recherche zu Gebäude mit historischer (geänderter) Adressen:
- Einfach: Hausnummer und Straße über Karten herausfinden ab 1910 über HistoMap Berlin (WMS Layer verfügbar)
- Aufwendiger: vor 1910 Hausnummer und Straße über Adressbuch recherchieren anhand von relativen Bezugspunkten wie Nachbarn etc. lokalisieren
- Digital erstmal nicht möglich: In weiteren nicht digitalisierten Karten recherchieren
Verbesserungsideen
Datensätze aus textlichen Quellen neuerfassen und historische Adresse zuordnen, wie z.B. mit Haberlandts-Bauten Anzeiger für Berlin und Umgegend
Vor allem für den ersten Prozess sehe ich Potential für die direkte Recherche/Erfassung in einer Applikation wie DOMUS. So könnte man zumindest so Gebäudedatensätze mit noch nicht zugeordneter (historischer) Adresse für Berlin so die Adressen mit den eingeblendeten Karten von HistoMap Berlin etc. ab 1910 für die Innere Stadt lokalisieren.
Weitere Recherchen nachdem man das Gebäude lokalisiert hat
Des Weiteren könnte man diese Grunddatensätze von Gebäuden, nachdem man sie lokalisiert hat und evlt. kein Abbruchjahr hat weiter recherchieren über HistoMap Berlin oder historische Luftbilder und ein ungefähres Abbruchjahr bestimmen. Dafür könnte man theoretisch ein Feature implementieren, dass die die historischen Luftbilder oder HistoMap Berlin Karten durchblättert und man nur angeben muss, wann das Gebäude nicht mehr existiert. (Hier würde es auch einige Sonderprobleme geben)
Konkrete einfachere Verbesserungen wären:
- Individuelle Hintergrundkarten und Luftbilder von HistoMap Berlin und OpenHistoricalMap/Resources/Germany – OpenStreetMap Wiki .
- Direktes Verknüpfen von OpenHistoricalMap und Wikdiata ermöglichen
Bei Rückfragen können Sie mich gerne kontaktieren.
P.S. bei building - Wikidata Eigenschaften für diesen Typ findet man noch mehrere Properties die man erfassen könnte.
Viele Grüße
Benjamin K.
Hallo Hermann,
ich habe schon viele Gebäude in Wikidata angelegt und kann deshalb aus Erfahrung sprechen, dass Gebäude sehr sehr selten gelöscht werden. Habe bisher eine Löschdiskussion gehabt zu einer lokalhistorischen Fabrik in Berlin (konnte ich abwenden). Aber falls man sich da nicht sicher ist, kann man auch mal hier Wikidata:Project chat - Wikidata generell nachfragen.
Viele Grüße
Benjamin K.