[admin-boundaries] Misrepresentation of OpenStreetMap Administrative Groupings in Overturemaps

[forwalk-org]

Category Feedback

In Italy (and possibly in Spain), OpenStreetMap relations with admin_level=7 tags are imported into the "overturemaps" theme as division and division_area with the sub_type=locality. However, this mapping doesn't accurately reflect reality. These entities are groupings for institutional and administrative purposes and lack a defined administrative center.

For Example:

OpenStreetMap relation R-1718727 groups the following municipalities: link to Overpass Turbo query

In the "overturemaps" data, this generates two records:

GERS id: 0858ac967fffffff01fd52bdc6aec773 in division_area represents the group perimeter with subtype=locality.
GERS id: 0858ac967fffffff01b8d94c93891622 in division creates a locality with subtype=locality and localtype="hamlet", but this location doesn't correspond to a real place.

Dependency with other categories, if any.

No response

[sasastanojkov]

Hey @forwalk-org!
This is great feedback! Thanks!
Can I please ask you to update your question with actual osm relation id 17187271?
I want to understand more about how this should be mapped. Do you think admin_level=7 in Italy doesn't represent any kind of division (in Overture sense of divisions) and should not be mapped to Overture division or do you think it should be mapped but under other subtype? Does the same mapping go for whole Italy (and perhaps Spain) or is this entity isolated case?

[forwalk-org]

In my opinion, relations with admin_level=7 in Italy and Spain should be mapped to the division_area theme in Overturemaps with subtype=localadmin. These relations effectively represent groupings of localities for administrative purposes.

Furthermore, in Spain, relations with admin_level=9 (civil_parish) should be mapped with subtype=borough (or macrohood), instead of the current mapping to 'neighborhood'.

In both Italy and Spain, not all administrative relations have a defined admin_center on the ground. Currently, these relations are imported into the division (point) theme using the centroid of the boundary, creating nonexistent localities that do not reflect reality.

I suggest that when an administrative boundary relation lacks an associated admin_center, it should only be imported into the division_area theme. However, if there is a need to represent the data in the division theme as a point for data integrity, labeling, or other purposes, the end user should be informed with a specific tag that the point is derived from processing and does not come from direct mapping. This will allow users to develop their own strategies for using this data.

Below are some examples of boundaries that do not have an associated admin_center:

https://overpass-turbo.eu/s/1O3S
https://overpass-turbo.eu/s/1O3T

[stepps00]

Thanks for the detail here, @forwalk-org. Very helpful.

In my opinion, relations with admin_level=7 in Italy and Spain should be mapped to the division_area theme in Overturemaps with subtype=localadmin. These relations effectively represent groupings of localities for administrative purposes.

Furthermore, in Spain, relations with admin_level=9 (civil_parish) should be mapped with subtype=borough (or macrohood), instead of the current mapping to 'neighborhood'.

We've started to review the OSM admin_level <> Overture subtype mappings per subtype, per country to identify coverage gaps and similar issues that you've found in Italy and Spain. This same issue is found in several other countries - Poland, Albania, and Austria, for example - so some work will likely be done to remap these features to new subtypes.

The civil parishes of Spain, as well as locality subdivisions in other countries will also be reviewed. Currently, various sub-locality divisions (especially in large cities) like arrondissements, quarters, and districts, are grouped in the divisions theme as localities. We'll have a proposal to update these features soon.

While a fix isn't slated for a specific release (yet), we'll make sure to reply here with updates as progress is made. If you have any other examples of unexpected placetypes at the locality level, we'd be more than happy to review thes features.

[krizleebear]

@stepps00 As you're explicitly asking for examples..

Here's a prominent Example from Germany (same example as in #441 )
The same issue exists for all independent towns (kreisfreie Stadt) in Germany

Berlin - Mitte borough, admin level = 9 should not be a locality, but a borough
https://www.openstreetmap.org/relation/16347

                  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

In fact there's an excellent per-country explanation/definition from OpenStreetMap that you most certainly already know:
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Country_specific_values_%E2%80%8B%E2%80%8Bof_the_key_admin_level=*

If you need support for mapping OSM admin levels to Overture subtypes, feel free to get in touch. I'm willing to help

EDIT: I just realized, that borough subtype is currently completely empty and opened #443 to report this issue