Hi, I wanted to share a new genealogy project of mine, for those who haven’t heard of it yet. The idea was born while working on Gramps Web’s map view: I’m creating places of type “building” for each house where an ancestor lived. In combination with Gramps Web’s OpenHistoricalMap layer and historical map overlays, this allows me to build little geographical time machines for my ancestors’ home towns. However, I always felt this house history research goes beyond genealogy and could profit from a public, open data repository where local historians could share their (documented) research results about building construction/demolition dates, owners, and inhabitants by period, as well as historical imagery. At some point, I realized Wikidata already allows to publish all of this information, it’s just so general that it’s hard to know which data to add where, and there is no map view to actually browse the data. That’s where Domus comes in: it’s an open data web platform for house history research that runs entirely in your browser, with all data stored openly in Wikidata. It’s hosted by the German association for computer genealogy (CompGen) and you can find it here: Domus Häusergeschichte erforschen und dokumentieren – ein offenes Werkzeug für Genealogie und Lokalgeschichte. It can be used for any house that exists, or has ever existed, world wide. Lots of buildings already show up on the map - mostly landmarks added to Wikidata. Please try it out, add a few buildings and give me feedback! For those who are interested in the technical background, there is also a writeup here: Domus: An Open-Data Web Platform for House History Research Currently, this project isn’t integrated with Gramps (Web) yet, but I’m planning to add Wikidata building pins to the Gramps Web map as ab optional layer. There is already a plugin for Webtrees: GitHub - hartenthaler/hh_external_places: webtrees module for enriching shared places with Wikidata, FactGrid, GOV and GeoNames information · GitHub

I have a regional history project up and running for some time that might fight into or even extend the concept of Domus. Its focus is on farms and the history of their owners and inhabitants in the south eastern corner of Bavaria. You can see it in action here. The technical concept is: (1) Gramps (desktop version on Win10) is being used for data editing and storage. (2) The Gramps NAVWEB report is used to generate HTML files. Those files are then modified, “collected” in a database that is uploaded to a server. (3) The Gramps XML export is used to generate a KML file. The KML file is the main (and currently only) user interface for the data. It is loaded as an overlay in the BayernAtlas and allows to select farms, list their owners, and access the HTML files generated in (2). The KML file could be loaded in any app that supports KML files (e g Google Earth) but since it contains extensive HTML code that is optimized for display in the BayernAtlas, the results will be quite disappointing elsewhere. (4) This sequence runs basically in a fully automated “nightly build” mode meaning that (2) and (3) will run every night and the data are updated daily. As a first guess, I envision two basic approaches how the data might be brought into Domus: (1) The KML file that is currently the only avaible UI could be replaced by Domus. Most of the data will still be in the HTML files that will be accessed from Domus. (2) The more “radical” approach would be to get rid of the HTML files and to transfer their data to Wikidata. What are your comments on that idea?

Thank you very much for this initiative. I’m already registering building data in Gramps for a local history project, so Domus looks to fit very well. I have added a couple of buildings to Domus, but there’s one piece of data I would like to be able to add - a cadastral number (in Danish ‘matrikel nummer’). Historically we had cadastral numbers centuries before addresses were introduced.

[image] csam: Historically we had cadastral numbers centuries before addresses were introduced. Even, today, maybe addresses are not always up-to-date and still a poor source for a large period (more than 50 years on most cities). Having a set of simple lists generated from a census source in 1819[1], I thought that LLM might help me to match most changes (like migration based on individuals and addresses), according to the next census. So, close to a buildings history (dynamic model) via people who lived on these locations. I also thought it was possible to keep a guard (monitoring, safe guard) by using the ‘‘cadastre value’’ (like the cadastral numbers), then set some common combinations like growing sectors with new families or so. On my testing case, the addresse value does not have clear rules during 19th (many changes and models according to the top street or administrative “lord”, even during the ‘german period’). A robust soundex/phonex cache (for residents and their migrations) might be a better solution for looking at house history, than addresses. [1] Census in 1819 : ~ 200 houses

[image] UlrichDemlehner: (2) The more “radical” approach would be to get rid of the HTML files and to transfer their data to Wikidata. I would prefer that option, because it would allow more people to contribute to the database. Your option 1 is a very special solution that cannot be adopted by many users and needs a lifelong maintenance. Option 2 is an effort that has to be done only once.

I see your point but this would basically mean to “re-build” Gramps with Wikidata. Very interesting indeed but beyond my pay grade …:wink: A different approach would be to use GrampsWeb instead of Gramps Desktop as data editing and storage layer. Perhaps David has some comments on that as well.

This sounds super interesting @UlrichDemlehner! Do you have more detailed documentation somewhere so I can assess what could be done?

I have a few papers on Zenodo where I outline some general concepts of my work and dive into some details of the “Briefprotokolle” of the “Landgericht Griesbach” in the 17th century. You can find them here. I’ve always wanted to write a paper on the more technical aspects of my KML overlay solution for the BayernAtlas, but have not yet found enough free time for that. Let me add some more technical details to the outline above: (ad 1) This is standard Gramps functionality which you of course know. The farms are defined as places with geo coordinates, so nothing special to see here. The farm owners are defined by assigning the farm name as their address for a specific time period. Again standard Gramps functionality, only a master data issue (e g the farm names must be unique since they are used as “index keys” and so on). (ad 2) This is also standard Gramps functionality by ways of the NAVWEB report. The report generates a directory tree with static HTML files. I modify those HTML files a bit by adding some JScript code to support the “accordeon” UI with the segments that can be opened and closed. I also add some anchors and minor stuff. The main issue is that the report will generate some 100k small static HTML files and this is not what I wanted to work with (besides the fact that my hoster does not support so many HTML files). So I zip those files and put them into a SQLite database as binary blobs. That database is then transfered to a server. The anchors in the KML overlay file are basically queries for that database that select a single blob and render it as HTML file. Nothing special again, only a way to handle the restrictions of my hoster. (ad 3) The KML file is also standard KML but contains a lot of CCDATA blocks providing the data on the farm owners and other information related to the farm. The BayernAtlas has quite a good support for rendering those CCDATA blocks in a visually acceptable way, so I’m basically writing BayernAtlas specific CCDATA code. Other KML apps (e g Google Earth) also support those CCDATA blocks but only in a very basic and inacceptable manner. This means of course that if the BayernAltas at some point in the future happens to change its support of CCDATA blocks, my UI will probably break down … The KML file is built by using the data in the Gramps XML export which is first fed into a PostgreSQL database. So I basically transfer the Gramps database to a PostgreSQL database and get a fully relational “mirror” of the Gramps data. This step of creating the PostgreSQL database could of course be skipped and the KML file could be generated directly from the XML export, but it’s much more convenient to go this extra step (besides the fact that I need the data in relational form anyway). If you’d like to get some more details on that, I’d propose to meet online so that we can discuss the questions you have.

[image] DavidMStraub: Thanks for the map links You may also find some older one, which I suppose are also good clients for vector scaling (real geometrical maps on 18th!). Category:Carte manuscrite de la Haute-Alsace, de la frontière suisse à la... Category:Carte de la Basse-Alsace depuis Strasbourg jusqu'à Landau -... [image] Category:Carte particulière des pays qui sont situéz entre le Rhein, la... Category:Old maps of the Rhine - Wikimedia Commons etc.

This is another perfect example for why Gramps should support Events on Places.

Just to understand your point better: event/place is already a many-to-one relationship, what would “events on places” add? You mean many-to-many like the ship voyages that have been discussed before?

Domus house history project

Genealogy

romjerome October 2, 2026, 8:58am 21

You may also find some older one, which I suppose are also good clients for vector scaling (real geometrical maps on 18th!).

etc.

Place "genealogy"

Topic		Replies	Views
Societal Events: Events connected to Places Ideas timeline	35	5476	February 8, 2025
Associations, but for Events Ideas	10	275	October 26, 2025
Place "genealogy" Help	5	242	October 10, 2026
Residence as an event Help	21	818	March 20, 2025
What's in development for Gramps 6.2 Development roadmap	43	1365	October 11, 2026

Domus house history project

Related topics