Nominatim swaps one class/type pair per place for an array of ltree category paths

The hierarchy lives in the column because ltree understands a path. Matching descendants is `WHERE categories <@ 'osm.amenity'::ltree`, and an exact test is `WHERE 'osm.amenity.restaurant'::ltree = ANY(categories)` ^[10]. The importer never writes the prefixes out ^[9]. Agasta had tried a `TEXT[]` column with prefix expansion and a GIN index, which avoids the extension dependency but moves hierarchy handling into application code and stores more data ^[11]. Agasta wrote that `ltree[]` fit better after testing the alternatives on real Nominatim data; the post does not include the comparison measurements ^[12].

Normalization is where the model gets lossy. Some of the PostgreSQL versions Nominatim supports restrict which characters an ltree label can hold, and OSM tag values use more than that ^[13]. So the importer rewrites hyphens as underscores and substitutes `yes` for values it cannot represent, leaving the original reachable through class, type and extratags ^[14]. A fallback label of `yes` is not a category anyone would design, and it is one every supported PostgreSQL version can store. Both rules are many-to-one, so two different tag values can end up as the same category path ^[16].

`class` and `type` are Nominatim's internal encoding of an OSM main tag such as `amenity=restaurant` ^[2], and they stay in API responses for compatibility while categories take over filtering and classification ^[8]. A place with several main tags still needs one pair to win, and the choice comes from a fixed ordering. "The current rule is deliberately boring: use a stable ordering so that the same set of tags always produces the same legacy value," Agasta wrote ^[21]. A randomly changing winner, Agasta wrote, would make an update look like a different place to downstream logic even when the OSM tags had not changed ^[22].

Sarah's review made the import cheaper. The first version produced one row per main tag and merged the rows afterwards, which she flagged as creating rows only to collapse them again ^[18]. The merge moved into `process_tags()`, where the Lua code collects the categories and issues a single insert ^[19]. For an object with more than one main tag, that is one insert instead of several and a merge ^[20].

Ranking took more work than Agasta expected, and `search_rank` and `address_rank` are computed from the place classification ^[23]. A row holding several categories therefore needs a rule for which category sets the rank ^[24]. Administrative boundaries had needed special handling through `admin_level` ^[4].

For an operator the upgrade is a schema migration with an extension attached, and PR #4106 shipped migration support next to the new column on `place` and `placex` ^[17]. Integrators reading class and type out of the API get the same fields as before ^[8].