I found inconsistencies in the division theme for many cities. The data in my examples is taken from 2025-10 release.
I guess this is connected to #235 but I want to point out a potential reason/solution for this bug.
I reverse geocoded a location in the center of Berlin.
I expect to find a division that has Berlin as city.
But in fact the division hierarchy indicates the city name of Berlin would be "Mitte" which is obviously not the case.
id = 1a6a8f16-265c-4c99-83dd-7b2d2dc2aabd
sources = [{'dataset': OpenStreetMap, 'license': ODbL-1.0, 'record_id': r16347@143}]
cartography = {'prominence': 49, 'min_zoom': NULL, 'max_zoom': NULL, 'sort_key': NULL}
subtype = locality
names = {'primary': Mitte, 'common': {de=Mitte, ru=Митте, ja=ミッテ}, 'rules': NULL}
region = DE-BE
local_type = {en=locality}
hierarchies = [[
{'division_id': 567d1698-7209-4b94-b7b8-0bc71bde0104, 'subtype': country, 'name': Deutschland},
{'division_id': 59f212f3-4e73-45d4-aca6-a8c5cb0c2bfd, 'subtype': region, 'name': Berlin},
{'division_id': 1a6a8f16-265c-4c99-83dd-7b2d2dc2aabd, 'subtype': locality, 'name': Mitte}
]]
parent_division_id = 59f212f3-4e73-45d4-aca6-a8c5cb0c2bfd
population = 383360
theme = divisions
type = division
I'm aware that Berlin is a independent city, and it's on region level, not on locality level.
But there's more to it:
The divisions theme contains the correct information, but it's not linked with division_area.
And it's not bidirectionally linked with the other divisions you see above.
The fitting locality/city division is the one with id=9187e609-5a2f-4535-85ec-e2b88399eea3
Interesting fact: In this special division, the other divisions are included and the hierarchy is complete:
id = 9187e609-5a2f-4535-85ec-e2b88399eea3
sources = [{'property': , 'dataset': OpenStreetMap, 'license': ODbL-1.0, 'record_id': n240109189@176, 'update_time': 2025-08-23T20:44:40Z, 'confidence': NULL, 'between': NULL}]
cartography = {'prominence': 93, 'min_zoom': NULL, 'max_zoom': NULL, 'sort_key': NULL}
subtype = locality
class = city
names = {'primary': Berlin}
wikidata = Q64
region = DE-BE
local_type = {en=city}
hierarchies = [[
{'division_id': 567d1698-7209-4b94-b7b8-0bc71bde0104, 'subtype': country, 'name': Deutschland},
{'division_id': 59f212f3-4e73-45d4-aca6-a8c5cb0c2bfd, 'subtype': region, 'name': Berlin},
{'division_id': 1a6a8f16-265c-4c99-83dd-7b2d2dc2aabd, 'subtype': locality, 'name': Mitte},
{'division_id': 9187e609-5a2f-4535-85ec-e2b88399eea3, 'subtype': locality, 'name': Berlin}
]]
parent_division_id = 1a6a8f16-265c-4c99-83dd-7b2d2dc2aabd
norms = NULL
population = 3769962
capital_division_ids = NULL
capital_of_divisions = [{'division_id': 567d1698-7209-4b94-b7b8-0bc71bde0104, 'subtype': country},
{'division_id': 59f212f3-4e73-45d4-aca6-a8c5cb0c2bfd, 'subtype': region}]
theme = divisions
type = division
So in the end, this is a case where data is inconsistent within division theme.
I guess I can rework the data on my side in order to meet my expectation, but I suggest it's fixed directly in the delivery.
I found inconsistencies in the division theme for many cities. The data in my examples is taken from 2025-10 release.
I guess this is connected to #235 but I want to point out a potential reason/solution for this bug.
I reverse geocoded a location in the center of Berlin.
I expect to find a division that has Berlin as city.
But in fact the division hierarchy indicates the city name of Berlin would be "Mitte" which is obviously not the case.
I'm aware that Berlin is a independent city, and it's on region level, not on locality level.
But there's more to it:
The divisions theme contains the correct information, but it's not linked with division_area.
And it's not bidirectionally linked with the other divisions you see above.
The fitting locality/city division is the one with id=9187e609-5a2f-4535-85ec-e2b88399eea3
Interesting fact: In this special division, the other divisions are included and the hierarchy is complete:
So in the end, this is a case where data is inconsistent within division theme.
I guess I can rework the data on my side in order to meet my expectation, but I suggest it's fixed directly in the delivery.