Feasibility: Local ML Pipeline for Hydrant Data¶

Status: research of 2026-11-01. Question: can a small team (1–3 people, local hardware, one GPU) build an ML pipeline that adds hydrants missing from OSM and siting attributes (sidewalk vs. carriageway, sidewalk width, distance to curb) from official, public data?

Sources: data-sources.md; literature in references.bib, cited below by BibTeX key.

1. Short answer¶

Partly viable, as a semi-automatic pipeline with human review, not as a fully automatic inventory.

Bebauungspläne won't give hydrants. They don't contain them. They are useful as rule-based context without ML.
Orthophotos won't give hydrants. At 20 cm per pixel, an underground hydrant cover is 1–2 pixels. They are useful for sidewalk and curb segmentation, which yields width and curb distance.
Street-level imagery is the most promising way to find hydrants missing from OSM. The key is the red-and-white hydrant sign (DIN 4066), not the cover. No published detector or dataset exists for it, so this would be new work.
The utility's hydrant register beats any ML pipeline. Asking for it comes first.

No German city or utility has published an ML-based hydrant inventory.

2. Approaches compared¶

Approach	Input (Kiel)	Delivers	Evidence	Effort	Verdict
A. B-Plan / XPlanung	SH WMS/WFS (dl-de/by-2.0), Kiel PDFs	Planned traffic areas, pedestrian zones	PlanZV only has a symbol for main supply lines; B-Pläne mark the edge of street land, not sidewalk vs. carriageway	Days, rule-based, no ML	✗ for hydrants · ✔ as context
B. OCR / vectorising scanned plans	Utility plans not public; B-Pläne contain no hydrants	–	No published work on water or hydrant plans; P&ID and cadastral digitisation are the nearest analogues `Rahul2019`, `Ignjatic2018`	High (a research project in itself)	✗ (only if the utility hands over scanned plans)
C. Hydrant covers from orthophotos	TrueDOP20 (20 cm, CC BY 4.0)	–	Manhole covers (60–80 cm) needed 4–5 cm imagery: about 40–50 % recall `Pasquet2016`, `Commandre2017`; F1 0.89 only with 23k labels at 5 cm `Liu2019`	–	✗ resolution about 4× too coarse, covers under parked cars
D. Sidewalk / curb segmentation from orthophotos	TrueDOP20 + OSM sidewalks as starter labels	Sidewalk polygons → width at the hydrant, distance to curb, carriageway vs. sidewalk	Tile2Net: sidewalk IoU 0.83 at about 0.19 m/px `Hosseini2023`; aerial + street-view gap filling P/R ≈ 0.9 `Ning2022`	2–4 weeks, 1 GPU	✔ viable with caveats (trees and parked cars hide the ground; validated only in US cities)
E. Hydrant signs + covers from street-level imagery	Mapillary (CC BY-SA), Panoramax, own 360° captures	Hydrants missing from OSM, main diameter from the sign, photo context	Detection of small street objects P/R ≈ 0.8–0.95 `Boller2019`, `Santos2020`, `Krylov2018`; city-scale hydrant recall 79–83 % with one source, 95 % with two `Hu2016`; positions 1–5 m off	4–8 person-weeks	✔ viable with caveats: human review required, Kiel coverage unknown
F. Mapillary map features (ready-made)	Mapillary API: `object--fire-hydrant`, `object--water-valve`, `object--manhole`	Ready-made detections	Mapillary points match OSM in about 59 % of cases (Portland, SotM 2019); offsets of several metres	1–2 days, no training	✔ quick first test
G. Mobile LiDAR	No open street-survey data for Kiel	Positions accurate to under 20 cm	Manholes F1 ≈ 0.96, 95 % confidence interval 16.5 cm `Mattheuwsen2020`, `Yu2015`; sidewalk width `Ai2016`	Needs data	✗ unless the city or utility has survey data (ask the Tiefbauamt)
H. Google Street View	–	–	–	–	✗ not allowed: terms of use and OSM policy forbid deriving data

3. Recommended path¶

flowchart TD
    S0["0 Ask Stadtwerke Kiel / Feuerwehr<br/>for the hydrant register"] -->|received| DONE["Register = ground truth<br/>ML only for siting attributes"]
    S0 -->|refused or pending| S1
    S1["1 Mapillary map features + coverage check<br/>compare with OSM, 1-2 days"] --> S2
    S2["2 Rule-based context: ALKIS land use,<br/>B-Plan pedestrian zones, OSM sidewalks<br/>2-4 days, no ML"] --> S3
    S3["3 Sidewalk / curb segmentation on TrueDOP20<br/>width and curb distance per hydrant<br/>2-4 weeks"] --> S4{"Large gaps in OSM?"}
    S4 -->|yes| S5["4 DIN 4066 sign detector + OCR<br/>on Mapillary / Panoramax / own captures<br/>4-8 person-weeks"]
    S4 -->|no| REV
    S5 --> REV["Human review<br/>JOSM / MapRoulette"]
    DONE --> S3

Step 1: Mapillary map features (no training)¶

Query the Mapillary API for the Kiel bounding box: object--fire-hydrant, object--water-valve, object--manhole, plus image coverage and capture dates.
Match against OSM hydrants within 10 m. Unmatched detections are candidates, not facts.
Check: does Mapillary detect Kiel's underground hydrants at all, or only the 21 above-ground ones? Expect mostly above ground. That is unverified.

Step 2: Rule-based siting context (no ML)¶

For each hydrant: - intersect it with ALKIS actual land use (Straßenverkehr / Weg / Platz / Grünanlage) - intersect it with the B-Plan layers (VerkehrsflaecheBesondererZweckbestimmung for pedestrian zones) - find the nearest OSM sidewalk or footway and its distance.

The output is new ow_* attributes, for example ow_landuse and ow_pedestrian_zone. These sharpen the M2 rules in criteria.yaml.

Step 3: Sidewalk and curb segmentation (ML, light)¶

Model: Tile2Net-style segmentation Hosseini2023 on TrueDOP20 tiles. Kiel covers about 119 km², roughly 3 × 10⁹ pixels at 20 cm, which one GPU handles in hours.
Labels: bootstrap from OSM sidewalks, then hand-correct a few hundred Kiel tiles.
From the polygons, derive the sidewalk width at the hydrant (polygon area / centreline length, or a perpendicular cut) and the distance to the curb.
Expect accuracy of about ±0.25–0.5 m; the street-view preprint reports MAE 0.25 m Tan2026. Treat it as an attribute with a confidence value, not a measurement.
License: CC BY 4.0 is fine for our analysis. Using DOP20 to edit OSM is disputed, so don't push results to OSM.

Step 4: DIN 4066 sign detector (ML, only if gaps are large)¶

Most hydrants in Kiel are underground (2,171 of 2,207). Their visible trace is the hydrant sign on a post or wall. As commonly described, it carries the main's diameter and the offsets from the sign to the hydrant; check the exact fields against DIN 4066.

Pipeline: 1. Detect the sign with YOLO or RT-DETR, fine-tuned on about 1–2k labelled crops. 2. OCR the sign text. 3. Triangulate the sign position from several images and add the offsets to get a hydrant candidate. 4. Optionally confirm with a close-range cover detection (Vistas class "Water Valve" / "Manhole" Neuhold2017). 5. Review in JOSM or MapRoulette.

No published detector, benchmark or labelled dataset exists for these signs, and none uses the offsets on the sign for geolocation. That is a research gap, and a possible publishable side result.

Pitfalls (from the OSM community): signs can be rotated, moved, wrong or orphaned. That is one more reason to review manually.

4. Realistic expectations¶

These are extrapolated from the cited studies, not measured in Kiel.

Metric	Expected	Basis
Sign / cover detection per image	P/R ≈ 0.85–0.95 after a few hundred labels	`Boller2019` (0.80/0.82), `Santos2020` (AP50 0.94–1.0)
Share of hydrants found citywide (one imagery source)	≈ 70–85 %	`Hu2016` (79–83 %; 95 % with two sources)
Position from triangulation	2–5 m off	`Hu2016` (median 5 m), `Krylov2018` (≈ 1 m for poles), `Boller2019`
Position with sign offsets	probably < 1 m	untested, a research gap
Sidewalk width	± 0.25–0.5 m	`Tan2026` (preprint), `Hosseini2023`
Effort, steps 1–3	about 4–6 weeks for 1 person	estimate
Effort, step 4	about 4–8 person-weeks	estimate

What 2–5 m means: that is too coarse to tell sidewalk from carriageway reliably on its own. Each ML attribute needs a confidence value and a source, and anything near the curb needs human review.

5. Fit with the repository¶

New sources in openwater next to osm.select(), e.g. a Mapillary or ALKIS selection, so a layer script can use them like OSM data.
New generic operations, e.g. "share of land use under the feature" or "sidewalk width at the feature", usable by any layer (see Writing layers).
ML models run outside openwater (own container with GPU and PyTorch) and write their results as files that such a source reads. openwater stays light.
ML results are their own attributes or layers, with a confidence attribute and their source listed in the layer. They never replace OSM tags.
Hydrant candidates from ML become their own layer (e.g. kiel-hydrant-candidates) that the viewer can show next to the OSM hydrants, marked as unverified in its description and assumptions.
Non-open data (for example the utility register) belongs in a separate, non-public data directory (see the license section in data-sources.md).

6. Open questions¶

How much Mapillary and Panoramax imagery covers Kiel, and how old is it?
Is the Mapillary object--fire-hydrant class trained on German pillar hydrants? Does it react to underground covers?
What exactly do the fields on a DIN 4066 sign mean, and what are the cover dimensions (DIN 4055)?
Does the Tiefbauamt Kiel have survey or sidewalk data, and would it share it?