Geodata and data projects

Georeferencing · Data model · Vectorisation · 3D derivation

Historical maps as a geodata source: the fortress of Mainz

Historical maps of the Mainz fortifications opened up as a geodata source — from retro-digitisation and georeferencing through to a vectorised data model from which 3D models can be derived.

The map material. A collection from several archives, first reviewed in full and rated by informative value, image quality and referenceability. Georeferencing proceeded chronologically, starting with the most recent sheet; each further sheet builds on one already referenced, so the chain of reference remains fully traceable. The control points come from two sources: from my own field walks through Mainz, recording structures whose fabric reaches back into the period of the maps — from the Roman wall through the citadel to the nineteenth-century forts — and from official orthophoto and cadastral services of Rhineland-Palatinate and Hesse.

The data model. The fortress is divided into substructures, deliberately cut broadly enough that the model applies to other fortifications of the same type. Only the lowest level carries geometry; the levels above describe it. 527 objects are vectorised: 278 glacis surfaces, 66 ditches — 17 of them water-filled — 71 sections of escarp, 74 of counterscarp, and 38 buildings inside the works.

The tilted view shows building volumes only together with the map sheet Mainz today — the historical plans carry no building heights.

Click a structure for substructure, material and source map. The escarp is the inner, the counterscarp the outer wall of the ditch; the two run parallel over long stretches and are therefore separated by colour rather than by dashing. The glacis is the gently rising earthwork in front of them that gave the defender a clear field of fire.

Vectorisation followed the plan of 1781. The plan of 1735 comes from the same chain of reference and shows the same area 46 years earlier. Mainz today lets you check what remains in the modern townscape: the ring of ramparts now lies beneath streets and parks. In the tilted view today's buildings are raised as volumes — their heights come from OpenStreetMap, with nine metres assumed where no figure is recorded.

Sources. Historical map sheets: Riksarkivet Sweden, Stockholm; georeferencing my own work. The vector data model is published under CC BY 4.0. Present-day city map: © OpenStreetMap contributors (ODbL).

Error analysis · Reverse engineering a data pipeline · Geocoding

A pattern that never was

In a published digitisation of the “Bomber's Baedeker” — a British gazetteer of German towns compiled in 1944 — the extracted place coordinates showed a conspicuous clustering. The investigation asked where that pattern came from.

The finding: the pattern arose during data preparation. It is not a property of the historical source. The original coordinates are given in degrees, minutes and seconds. In processing, the degree sign was treated as a decimal separator and the minute sign discarded — 50° 47′ became 50.47. The necessary conversion from arcminutes to decimal degrees never happened. Since minutes only run to 59, no value between .60 and .99 can arise this way.

The gap bands mark the range from .60 to .99 degrees within every graticule cell. Switch them on together with the source data: not a single point falls inside them. That is exactly what created the impression of clusters — all points gather in the south-western part of each cell. After conversion, the same places spread out evenly.

The finding in numbers

Counted here is the first decimal place of the uncorrected latitude across all 515 source points. 507 of them fall between .0 and .5. Not a single value lands on .6 — the range arcminutes cannot reach.

The cross-check. To validate the correction, the adjusted places were compared against an independent geocoding via OpenStreetMap. A difference could be formed for 372 places. The median deviation is 3.3 kilometres; the arithmetic mean sits at 6.1 kilometres, pulled up by twenty outliers of up to 86 kilometres where automatic geocoding hit the wrong place — some of them on other continents. What matters is direction: across the eight compass octants the deviations are distributed almost evenly, between 38 and 61 cases each. No systematic error remains; the historical coordinates are accurate for their purpose.

Sources. Source data from the digitisation project “Bomber's Baedeker — vom Text zum Bild zur Datenquelle”. Correction, geocoding and difference analysis are my own work. Base map: Natural Earth.

Paper (PDF, German) Poster (PDF, German) Source project

Data modelling · Process automation · Document processing

Three systems from current practice

Unlike the three pieces of work above, these systems cannot be shown — they hold internal company information. What can be shown is the method. All three follow the same sequence: first a model that describes the subject cleanly, then an interface on top of it, then automation of whatever repeats. In that order, because automating on top of an unclear model only multiplies the effort.

• A domain data model for infrastructure in space. Records from different operators — inconsistent in origin, accuracy and format — obtained, referenced and merged into one holding. The value lies not in the collecting but in carrying the differences in reliability through the model instead of levelling them out. Only then will the data support decisions about sites and routes.
• An application that does not need IT. Built on the data model and cut so that several departments work in it together — each sees their own section, all work on the same state. Long-running procedures stay traceable even when responsibilities change hands.
• Automated document workflows. Incoming correspondence is captured, parsed by machine and assigned to the matching case; AI comes in where unstructured text has to become structured fields. The gain is less the time saved than the complete documentation that falls out of it.