Hi, I have been writing a global mapping application and I noticed that the city field for one of the locations is coming up as Waitematā instead of Auckland. What I’m seeing is that the City is being put inside the State field for New Zealand. This is of course a problem because when I query city, I get an actual city for some countries, but for New Zealand I don’t get a city. Except sometimes, like the SkyTower has Auckland for both the City and for the State.
For those of you wondering NZ doesn’t have states. The names that currently exist in the openstreetmap city field for NZ are not legal cities, they are geographical boundaries within their respective City.
I am hoping this is not intentional as otherwise the only options I see to get actual Cities in the City field are:
Some horrible workaround code - I don’t even know if it’s possible as there may be other countries affected I don’t know about
Use another mapping solution.
I don’t see the point of having a City field if it doesn’t have cities in it, or worse if it’s inconsistently has cities in it. Can anyone shed any light on this or offer a solution? Thanks.
Here are a couple of examples:
Location: (-36.8485, 174.7633)
Address:
suburb: City Centre
city: Auckland
state: Auckland
country: New Zealand
Location: (-36.8568666, 174.7551359)
Address:
suburb: Freemans Bay
city: Waitematā
state: Auckland
country: New Zealand
Location: (-41.278, 174.777)
Address:
suburb: Thorndon
city: Wellington
county: Wellington City
state: Wellington
country: New Zealand
If I understand correctly, you are not actually referring to OpenStreetMap data directly, but to the output of a reverse geocoding tool, most likely Nominatim. So by “city field” you mean a field with that label in the output from the tool, which is itself an interpretation of OSM data, not the raw data. If you can confirm that you are looking at Nominatim output it may help get more precise answers.
It apparently has regions which are mapped as Level 4 administrative areas in OSM. Many countries use this for high level admin entities, which may be locally called "state”, “province”, “region”, “autonomous community”. Some interfaces to OSM data may use the generic label “state” without meaning that is literally the term used in that country.
I don’t know enough about New Zealand to comment further, but generally the concept of a “city” varies worldwide (e.g. cities may be administrative units in their own right with clear boundaries, or simply an urban part of a larger admin unit without a separate legal identity). So it’s possible that inconsistencies you see simply reflect inconsistencies in the real world. Or to put it another way: what do you have in mind when you refer to “an actual city”?
Looking at the details Nominatim Demo you find in a very small area around these coordinates the place=city node of Auckland. This node with address rank of 18 has precedence over the relation with admin_level=8, Waitematā
In other places of Auckland like the second location Query Features | OpenStreetMap the place=city node is not part of the result. Since the admin_level=8 relation does not contain a place node with place type the API result will have city=Waitematā (in this local board of Auckland).
While the question uses somewhere in New Zealand as an example the main issue (as suggested in the first two replies) is what to expect from Nominatim reverse geocoding and how to get what you want from it.
For previous examples of this sort of thing see here in Northern Ireland and this discussion at SOTM EU more generally about that and other countries in the UK. @lonvia’s slides from that talk are relevant to the situation here, too (broadly speaking - administrative areas don’t exactly match human settlements).
Separately to that I wrote a diary entry about treating Nominatim as a “black box”, but feeding in data that means it returns the results you want to see (a tag transform with relatively few lines of lua). Depending on exactly what OP wants to do, a similar approach to my “joke” may actually work, or may be a “horrible workaround”.
Re moving to Communities > Oceania, I can see the logic (most other previous such discussions have occurred in country-specific areas), but I don’t think this is a specific NZ issue - far from it.
For obvious reasons (i.e. Nominatim) I’d be interested in a summary of the discussion and conclusion. If you can give it here or do a write-up in the wiki, that would be awesome. Singing up to and following all local OSM chat channels simply isn’t an option.
The wiki page for admin_level in NZ is accurate. In short:
admin_level=8 should never be part of the address in NZ. It’s used for Community/Local boards, which is a legal concept that is unrelated to street addresses. That’s why Waitematā appears in the result.
In this example, Nominatim includes Auckland, Auckland, …. Repeating the city twice is unexpected. Both the relation and the node have admin_level=4, unclear why nominatim includes it twice.
The discussion on discord also mentioned the government’s controversial proposal to completely get rid of admin_level=4, but that’s unrelated to these two issues.
hello - I’m the Aucklander engaging in that discussion! I can’t speak for the other person on Discord (EleGlobe, looks like they’re not registered on the forum right now), but most of the Auckland examples above use our local board boundaries (admin_level=8) in the city field instead of the actual city (Auckland). I’m probably not going to explain this very well, but basically they only exist as zones for local politicians and nobody uses them in addresses.
I’m not that familiar with the Nominatim address model, but hopefully you get the idea!
These two objects seem to be very different concepts, one is the region of Auckland and the other the city of Auckland. It looks completely correct to me that Nominatim doesn’t link them up. They have different wikidata and wikipedia links after all. If I’m wrong any they are the same, then the node should go with role ‘label’ into the boundary and Nominatim will pick up on that fact.
Auckland is not being shown twice because there are two relations. These two relations are already detected as being identical by Nominatim and the one on level 6 is completely ignored.
Auckland is shown twice because Nominatim will not link up the place node and the boundary. These two are distinct objects right now: one at state level and one at city level. They have different wikipedia link, they have different wikidata IDs. The only link between them is through the role admin_centre and that gets ignored because it only indicates that the node is the capital of the boundary.
In order to have the node and boundary linked internally in Nominatim one of these conditions must be met:
the node is included in the boundary relation with role label
the node and the boundary have the same wikidata entry
node and boundary are conceptually at the same level (for cities that would need to be admin_level=8) and have the same name
So yes, change the role of the node from admin_centre to label and things should sort themselves out. Once Nominatim can figure out that your level 4 boundary actually belongs to a metropolitan area it will reclassify all boundaries inside so that they make more sense.(For some background on this, the Boundary, Places talk explains how Nominatim’s internal heuristics work.
Sometimes you want to check which LGA (place=municipality/admin_level=6) you are in, but always as a specialised search, not as a general place reverse geocode.
Wow thanks everyone for taking my post so seriously, what a wonderful and helpful group of people you all are!
I think sometimes it’s useful to step back and ask the why part: i.e. what is the purpose of having admin_levels?
For me what I was expecting was, “Query level 6 globally, get equivalent administrative divisions everywhere.” A developer shouldn’t need to know that level 6 means counties in the US, territorial authorities in NZ, and LGAs in Australia.
Currently, I believe using admin_level requires maintaining a per-country mapping table to interpret what each level actually means, which is precisely the problem a normalised structure should solve, without which essentially shifts complexity from open street maps onto every consumer of the data.
Even AI models now cite this as a known limitation - a direct quote I got while investigating: “Challenge: OSM admin levels vary by country: NZ level 4 = regions, level 6 = TAs, level 7 = local boards; US level 4 = states, level 6 = counties…”
For a project as mature as OpenStreetMap, I would have expected semantic consistency: level N means the same type of division everywhere, not just “the Nth level down”
Is there appetite for defining levels by function (e.g., “primary local government unit”) rather than by hierarchy depth? Or am I misunderstanding this?
Is this really a limitation of OSM, rather than simply a feature of the real world, that each country distributes its administrative functions in its own way?
Do you have an example of another data source that doesn’t have this limitation as you see it?
Even comparing only the two countries I have lived in, Ireland and Spain, I would find it difficult to define “equivalent administrative divisions”. Ireland has a rather flat and centralised structure - most functions either belong to the central government or counties, with other admin levels having a limited role. Spain has a less centralised and more complex structure, with functions distributed across central government, autonomous communities and cities, provinces, and municipalities (and even within Spain, the functions of the top level autonomous communities have some differences such as taxation and policing). I don’t see how an Irish county could be “equivalent” to any single administrative entity in Spain. Extending that kind of comparison to ~200 countries seems like a daunting task.
