13. Regions and border areas

Canopies and passages in every state. ALKIS records canopies and carports as structures next to the buildings, and building passages and arcades as building parts. freemapper reads them from the buildings it already fetches, with no extra download. Canopies and carports become map objects (522) on both map kinds, cut at the buildings as in Berlin. Building passages and arcades become 522 candidates, and the building stays whole. Underground ones are left out. The data currency is the date of the ALKIS object. Saxony and Saxony-Anhalt record no canopies or passages in this data, so maps there get none. Berlin takes them from its own layers (below). An existing map gets the canopies only with run --force.

Brandenburg and Bremen: full ALKIS; Potsdam trees. In Brandenburg freemapper also reads the full ALKIS from the LGB's NAS service (dl-de/by-2-0), in Bremen from the service that also gives its buildings and land use (CC BY 4.0). It holds what the simplified ALKIS lacks: surveyed walls and wall edges, fences, hedges, monuments, fountains, ditches and brooks, and on sprint maps also embankment tops and bridges. They become walls 515, fences 518, hedges 410.1, monuments 526, fountains 311, ditches 306, brooks 305, embankment tops 104 and bridges 501.5; the content profile decides whether they go onto the map or stay candidates (chapter 8). The code in the cadastre picks the symbol, never the height. The layers are stored in data/alkis-nas/, about 1 MB per km². At Park Sanssouci (0.74 km² with the buffer) the six layers hold 780, 146, 315, 4, 1 and 0 objects in 0.6 MB. Each of these objects carries freemapper:source=alkis-nas/<layer> and freemapper:alkis with the cadastre's name, e.g. Mauerkante, rechts. Its data currency is the date the object version entered the cadastre (beginnt). Two edges of one wall closer than 0.55 mm on paper become a single 515 line in the middle (chapter 9). freemapper takes canopies and building parts from the simplified ALKIS only, so they are not drawn twice. Brandenburg records no stairs, retaining walls or single trees in the full ALKIS. Bremen records stairs with their bottom edges and retaining walls, but neither hedges nor single trees in the city centre; in the old town of Bremen (0.7 km² with the buffer) 64 stairs, 13 retaining walls, 13 monuments, 16 embankment tops and 4 bridges come from it. If the service sends more objects than it allows in one answer, freemapper splits the area into quarters, at most four levels deep.

Hesse: full ALKIS and landscape model. Hesse serves both from the HVBG (dl-de/zero-2-0), and freemapper reads both. Its full ALKIS records surveyed stairs: in the old town of Marburg 54 go straight onto the map, with the content profile balanced. The landscape model adds candidates as in Bavaria: in Marburg 4 named trees, 3 small watercourses, a dam and a wall, on the Feldberg a rock, a spring and a watercourse.

North Rhine-Westphalia and Lower Saxony: full ALKIS. Both serve their full ALKIS as well (Geobasis NRW, dl-de/zero-2-0; LGLN, CC BY 4.0), Lower Saxony with at most 10 000 objects per request. In North Rhine-Westphalia it holds much: in the old town of Monschau 25 walls and retaining walls, 33 embankment tops, 14 stairs, 15 bridges, 17 walls along the Rur and 13 single trees go straight onto the map, in the Siebengebirge 90 embankment tops and about 30 walls and stairs; OpenStreetMap lines and trees they double go. Lower Saxony records less: in Herrenhausen 4 bridges and a fountain, in Bad Harzburg 12 bridges, a wall and an embankment top.

Schleswig-Holstein: landscape model. The LVermGeo SH serves its landscape model as well (CC BY 4.0), with at most 10 000 objects per request. In the Hüttener Berge it adds 48 earth walls (105), a watercourse and 4 tracks; the banks the terrain model finds along those walls go. In Lübeck it adds a watercourse.

Mecklenburg-Vorpommern: full ALKIS and landscape model. The LAiV M-V serves both (CC BY 4.0), each with at most 10 000 objects per request. The full ALKIS records many stairs: in the old town of Wismar 630 go onto the map, most of them short steps in front of house doors, along with 138 walls and 2 bridges; OpenStreetMap walls they double go. The landscape model adds 6 trees, 2 watercourses and a structure there as candidates, in the Granitz 5 paths.

Rhineland-Palatinate: landscape model. The LVermGeo RP serves no full ALKIS, but its landscape model (dl-de/by-2-0), in the Shape schema of the AdV instead of NAS. freemapper reads it and treats it as in the other states: its objects stay candidates. In Cochem it adds 19 monuments and wayside crosses, 2 watercourses and a well, near Dahn a rock, 3 watercourses and, on the forest map, 6 tracks and paths.

Hamburg: street tree cadastre. Hamburg serves its street trees with genus, species and crown diameter (dl-de/by-2-0). freemapper fetches them like the Potsdam trees; on sprint and schoolyard maps they become single trees, a crown of 10 m or more as a 417, the others as a 418. In Blankenese 13 street trees go onto the map and 4 to the candidates; the OpenStreetMap trees at the same places go. The cadastre has no survey date, so the fetch date is its currency. Trees in parks and in the port are not in it.

Lübeck: tree cadastre. The Hansestadt Lübeck publishes its tree cadastre as one CSV file of the whole city (CC0, 8 MB). freemapper downloads it whole on every fetch and keeps the trees of the map area; empty planting spots (Fehlplatz) go. It has neither a crown diameter nor a survey date, so every tree is a 418 and the fetch date is its currency. In the old town 384 trees go onto the map and 43 to the candidates, mostly lindens and maples in rows along the streets; the OpenStreetMap trees at the same places go (78 to 25).

Leipzig, Frankfurt (Oder), Kiel and Norderstedt: tree cadastres. These four cities serve their trees through a WFS, with genus or species and crown diameter (Leipzig, Frankfurt (Oder) and Norderstedt dl-de/by-2-0, Kiel CC BY 4.0). freemapper fetches them for a map area in the city like the other tree cadastres; a crown of 10 m or more makes a 417. Leipzig keeps felled trees with their felling date; those go. None of the four has a survey date, so the fetch date is the currency. Dresden's tree cadastre is missing: its WFS gives no GeoJSON.

Köln, Dortmund and Frankfurt am Main: tree cadastres. These three cities publish their trees with the crown diameter as well: Köln through a WFS, Dortmund as an OpenDataSoft export and Frankfurt am Main as a CSV file (17.5 MB, downloaded whole on every fetch). Köln and Dortmund under dl-de/zero-2-0, Frankfurt under dl-de/by-2-0.

In Bavaria the cadastre has no service. There freemapper asks the landscape model of the agency instead, the ATKIS Basis-DLM (CC BY 4.0). It is made for the scale 1:25 000 and accurate to about 3 m. freemapper takes cave entrances (203), springs (312), named rocks (205), free-standing towers (524, 525), monuments and wayside crosses (526), fountains (311), fences (518), dams and walls (105), small watercourses (305) and named trees (418) from it, on forest maps also paths and tracks (504 to 507). These objects stay candidates in every profile but full. Where another source has the same object, the one of the landscape model goes: a point when a point with the same symbol lies within 15 m (a tree beside a tree, large or small, and a tower beside a tower), a line when at least 80 % of its length runs within 10 m of a line of the same kind. For paths every path class counts as the same kind. A path stays or goes as a whole. The object that stays names the dropped one in freemapper:also. The layers lie in data/alkis-nas/ too, as dlm-…; their objects carry freemapper:source=atkis-dlm/<layer>. On the Schmausenbuck 14 of 152 objects stay as candidates, 6 of them paths OpenStreetMap lacks; in the old town of Regensburg 8 of 35. freemapper does not take church towers, town gates, canals, power lines or areas.

Saxony-Anhalt has only the simplified ALKIS, and freemapper asks its landscape model in the same way (© GeoBasis-DE / LVermGeo ST, dl-de/by-2-0). There most rocks are lines: freemapper offers them as cliff candidates (201), whose ticks point downhill by the terrain model like those of the other cliff candidates. In the Bode valley that gives 27 cliffs and 20 rocks, 3 dams, a spring, a monument and 11 paths OpenStreetMap lacks; in Quedlinburg 7 small watercourses.

If an OSM line (fence, wall, hedge, brook or ditch) lies with at least 80 % of its length within 1.5 m of a full ALKIS line with the same symbol, freemapper drops the OSM line, as in Berlin. The order is the same in every state: register before ALKIS before the street survey before OSM.

In and around Potsdam freemapper fetches the trees of the Potsdam city map (Bäume der Stadtkarte, dl-de/zero-2-0). They are stored in data/trees/; the size estimate counts 1 MB per km². The data has no crown size, so every tree becomes a 418 point; with safe it stays a candidate, with balanced it goes onto the map. Stumps are left out. Each tree carries its own survey date as data currency, from 1993 to 2026, and its kind in freemapper:baum, e.g. Laubbaum. An OSM tree less than 2 m from a Potsdam tree is dropped. A Berlin area makes no request there, even inside the Potsdam data's extent. At Park Sanssouci freemapper fetches 1964 trees; 1646 of them lie in the map area with its buffer. In the example 773 stay points; the others lie in tree-group areas or are dropped by the thinning. If the disk has too little room, freemapper leaves out the full ALKIS and the trees together. The stored ones then stay. An answer larger than 256 MB is stopped while it is read.

Berlin: structures, trees and the K5. When a map area touches Berlin, freemapper fetches six more layers from Geoportal Berlin (dl-de/zero-2-0): the ALKIS structures as areas and as lines, the embankment edges (for sprint maps only), the hedges, and the street and park trees. They are stored in data/berlin/. From them come:

• Canopies and carports as map objects (522) on both map kinds. A canopy with 90 % or more of its area inside a building is left out. An existing map gets the canopies only with run --force.
• Candidates: stairs (532.6 to 532.9) with the walking direction from the terrain model, walls (515), retaining walls (513.2), fences (518), hedges (410.1), building passages and arcades (522) and monuments (526); on sprint maps also bridges (501.5) and embankment tops (104). The ALKIS name alone picks the symbol.
• Trees from the tree cadastre: 417 for a crown of 10 m or more, otherwise 418. If an OSM tree stands less than 2 m from a cadastre tree, freemapper drops the OSM tree.
• Fences, walls, retaining walls and hedges are often in both ALKIS and OSM. If at least 80 % of an OSM line lies within 1.5 m of an ALKIS line with the same symbol, freemapper drops the OSM line. The ALKIS line names it in the tag freemapper:also, e.g. osm/way/123. Lines with different symbols for the same object are cut after that (chapter 9, overlapping walls, fences and hedges).

freemapper picks the stair symbol by the stair's width on paper. On sprint maps a stair 3.5 m wide or more becomes 532.9, on schoolyard maps one from about 1.1 m. So nearly every schoolyard stair is 532.9. A stair wider than three times 532.9 (12 m on sprint maps) becomes parallel 532.9 lines.

The Freitreppe lines of the ALKIS structures are step edges. freemapper joins parallel edges up to 2 m apart that overlap along their length into one stair. A doubled edge counts once. The stair runs across the edges, as wide as the edges are long and as long as the whole flight. A single edge gives no stair.

Each candidate names its origin in the object tags: freemapper:source=geoportal-berlin/<layer>, freemapper:alkis with the ALKIS name (e.g. Mauerkante, rechts), and for trees freemapper:baum with species and crown. The layers have no date of their own, so the data currency (freemapper:currency) is the date of the fetch. freemapper does not take curb lines from ALKIS, but it takes those of the street survey.

Berlin: street survey, registers and building dates. freemapper also fetches the street survey (Straßenbefahrung), the lighting cadastre, the registers of ornamental fountains and of drinking fountains, and the building heights of 2022 from the Umweltatlas, all under dl-de/zero-2-0. In the city centre that adds about 6.5 MB per km² (6.4 MB at Viktoriapark). The street survey recorded Berlin's public street space from 2014 to 2016. There is no newer one, so the data is about ten years old. That is why it never replaces ALKIS. Apart from the green cut-out, it gives only candidates. From these layers come:

• On sprint maps: freemapper cuts the surveyed green strips out of the paved areas (501.5) where the overlap is at least 1 mm wide on paper, but at most 2 m in the terrain. Tree pits stay. Each green strip is also a 401 candidate, except where it lies on paving that freemapper did not cut. Surveyed sidewalks, carriageways, cycle paths, parking areas and squares outside the drawn ALKIS areas become 501.5 candidates, such as park paths and forecourts. Here too, narrow pieces from 2 m wide stay. Curbs become 501.1 candidates, advertising columns 531. A curb that runs around a tree pit is straightened: a detour under 1.5 mm² on paper (24 m² at 1:4000) becomes a straight line, and a lone ring of that size goes.
• On both map kinds: stairs (532.6 to 532.9, like the ALKIS stairs; the field trs, probably the number of steps, comes as berlin:trs), walls (515), railings, traffic barriers and crash barriers (518, like fences), bus shelters (522), fountains (311) and drinking fountains (313) from the street survey and the fountain registers.
• On schoolyard maps: benches (543), hydrants (321), bollards, masts and flag poles (544), play equipment (541) and the lamps of the lighting cadastre (545), only those in operation.
• On sprint maps, as control sites (531, candidates only): bollards, masts, flag poles, benches (the middle of the surveyed line), the lamps of the lighting cadastre (only those in operation) and advertising columns. A site of one kind within 25 m of another is left out, so of the 1 077 bollards at Viktoriapark 3 remain. Hydrants and play equipment are not taken: ISSprOM names hydrants as not to be mapped.
• Buildings: each ALKIS building that the building heights of 2022 know gets its Grundrissaktualität (footprint date) as data currency (freemapper:currency). It is the state of the outline in that data, not a survey date. A building without a match keeps no date.

When an object comes from several sources, the register wins over ALKIS, ALKIS over the street survey, and the survey over OSM. A lamp of the lighting cadastre replaces OSM lamps up to 5 m away and surveyed masts up to 2 m away. Surveyed masts further off are mostly sign and signal masts. A fountain of a register replaces the OSM and surveyed fountains up to 3 m away. On schoolyard maps a surveyed hydrant, bench, mast, flag pole or play item replaces the OSM one up to 2 m away. freemapper drops a surveyed line with at least 80 % of its length within 1.5 m of an ALKIS line with the same symbol, and a surveyed stair that overlaps an ALKIS stair by at least half. It also drops a surveyed bus shelter that lies at least half under an ALKIS canopy, because the canopy is already on the map. A surveyed wall next to an ALKIS retaining wall stays, because the symbols differ. The object that stays names the dropped ones in freemapper:also, a surveyed one e.g. as geoportal-berlin/sb-gelaender/Li_2015-05-02_1. freemapper also leaves out a fountain of the register or of the street survey inside drawn water, as it does the OSM fountains.

ALKIS and the street survey often split a wall or a railing into short pieces. Where pieces with the same symbol meet end to end, freemapper joins them into one line. Only then does freemapper drop lines under 1 mm on paper (4 m at 1:4000). The joined line names the other pieces in freemapper:also. A surveyed one carries the oldest survey date of its pieces.

Each Berlin candidate carries berlin:layer. For the street survey and the registers it holds the object type (e.g. bd_bordstein, beleuchtung), otherwise the layer name (e.g. bauwerke-linien). The street survey codes (material, hms, pot, bor, gws, sre, hdt, trs) come as berlin:<code>. What they mean is not published. A surveyed candidate has its survey date from the gis_id as data currency. If that is unreadable, it says 2014-01-01 with freemapper:currency_guessed=yes. A paved area that was cut keeps its ALKIS origin and names the green strips at its edge: freemapper:cut=geoportal-berlin/sb-gruenflaeche, freemapper:cut_ids and freemapper:cut_currency. The last one is the oldest real survey date. If there are only guessed ones, freemapper adds freemapper:cut_currency_guessed=yes. An existing map gets the green cut-out and the building dates only with run --force.

Fountains, pumps and drinking fountains come in Berlin from the register, the street survey, ALKIS and OSM. When two points of different sources lie at most 0.75 mm apart on paper, but never under 3 m on the ground (3 m at 1:4000), freemapper keeps the one of the stronger source: register before ALKIS before street survey before OSM. It names the other in freemapper:also. A fountain point in an OSM fountain basin or within 1 m of it is dropped, and the basin names it. Two fountains of the same source both stay, however close they are.

The K5 (Karte von Berlin 1:5000, the Berlin map in colour, dated 02.01.2026) comes as the template templates/k5.png with a world file, at 0.25 m per pixel. If the area with its buffer is longer than 1.5 km, the image gets coarser. It shows park paths, stairs, walls, fences, embankments and monuments, which makes it good for comparing. OOM has it linked but hidden; in OCAD it is a background map. If the disk has too little room, freemapper leaves it out, as it does the surface model. The same goes for the Berlin layers; the stored ones then stay.

The export needs the terrain model for the walking direction of the stairs, the ticks of earth banks and the height of cliffs. In a state whose terrain model comes in tiles, derive therefore keeps the terrain mosaic in the project as data/terrain.tif (about 4 MB per km²), for every map (ADR 0134). This way export works without internet and without the cache.

Allotment gardens are out-of-bounds candidates (520) in every state: the ALKIS land use "Sport-, Freizeit- und Erholungsfläche" with bez "Kleingarten". Parks, sports grounds and playgrounds of the same land use stay open.

Coordinate system: Brandenburg, Berlin, Saxony and Mecklenburg-Vorpommern deliver in UTM zone 33, Saxony-Anhalt, Hamburg, Hesse, Schleswig-Holstein, North Rhine-Westphalia, Lower Saxony, Rhineland-Palatinate, Saarland, Baden-Württemberg, Bremen and Bavaria in zone 32. Bavaria stays in zone 32 east of 12° E too, like the state's data. Each map gets the zone of the state holding its centre; OOM and OCAD show it in the georeferencing. If you move a map area across the zone line or into another state, freemapper fetches everything again.

At a state border freemapper queries the cadastre of both states and reads both OSM extracts. The orthophoto and terrain come from the state holding the centre of the map area. If the area reaches far across the border, the templates on the other side stay empty where that state's orthophoto and height models end. Some services reach further: the LGLN orthophoto and height models also cover the Hamburg corner at Harburg, and the LVermGeo RP height models reach across the Rhine at Mainz. freemapper tells you when an area crosses a border.

Adapters of your own

The states above are built into the program. A further state or country can be added as a folder, if its services are standard ones: a WFS or an OGC API Features service for the cadastre, a WMS and a WCS for the orthophoto and the height models. The folder has the name of the adapter's id and holds a manifest.toml and a boundary file. freemapper reads such folders from your adapter folder:

The variable FREEMAPPER_ADAPTER_DIR names another folder by its absolute path; a relative path is ignored with a warning. freemapper adapters list shows every adapter with where it comes from, the day it was last checked and the servers it asks, and names your adapter folder in its last line. A folder with a mistake is left out with a warning that names the file and the line; the other adapters still load. An adapter from a folder cannot replace a built-in one. If it lies on the ground of another adapter, the list names that one: a map there gets the objects of both.

The area page and the AI assistant read the adapter folder when they start. If one of them is already running when you add or change an adapter, close it and start it again; until then it does not know the adapter.

An adapter makes freemapper ask the servers it names, and no others. Still, read a manifest before you copy it into your adapter folder: [net] hosts lists every server.

A project folder can bring adapters along in its folder adapters. freemapper loads them only when you say so, with --adapters-from-project on init, fetch, derive, export or run, and then names each in a warning with the servers it may ask. The area page and the AI assistant never load them. Use the switch for a project of your own.

freemapper adapters check <folder> checks the folder of an adapter without asking a server: whether it would load, and what its author should know. With --live --bbox minLon,minLat,maxLon,maxLat it also asks the services of the adapter for a small box inside its boundary (150 m by 150 m is enough) and says what arrived for each capability:

freemapper adapters check ~/my-adapters/elbaue
freemapper adapters check ~/my-adapters/elbaue --live --bbox 12.2430,51.8350,12.2452,51.8364

The exit code is 0 when the adapter passes, 1 with findings and 2 when the check could not run.

How to write an adapter is in the guide for contributors, with a tutorial that builds one step by step and a reference of every key of the manifest. The manifests of the built-in states in crates/adapters/de/manifests/ are examples.

When a service moves

For a built-in state freemapper asks only the servers its adapter names. When an agency moves a service to another server, the fetch fails with a message that starts with the refused address, names the state and ends with a command. With that command you allow the state the one host until a new version of freemapper knows it itself:

freemapper adapters allow-host hessen new-server.hessen.de

The area page and the AI assistant read the allowed hosts when they start. If the fetch failed there, close the page (or quit the assistant) and start it again after the command; until then it refuses the host as before.

Take the host from the message and check that it belongs to the agency of the state. Report the move (chapter 16), so that the next version brings the host. Once a new version brings the host, the next find, init, fetch, derive, export or run says in a warning that your entry is no longer needed and removes it. The area page and the AI assistant through MCP never change the file.

The allowed hosts are in allowed-hosts.toml in your configuration folder (freemapper under ~/Library/Application Support, ~/.config or %APPDATA%), and nowhere else: a project folder, an environment variable of freemapper, a switch of a run or the AI assistant through MCP cannot add a host. Where the configuration folder is, the system says, on Linux and macOS through HOME and XDG_CONFIG_HOME; whoever sets those for freemapper, the configuration of an MCP client for example, picks the file with them. A host must be a DNS name; an IP address, localhost, a name of the local network, a wildcard or a port is refused. For an allowed host, too, freemapper connects to servers on the internet only. freemapper adapters list shows the allowed hosts per state, and freemapper adapters disallow-host hessen new-server.hessen.de takes one back.