Relations of type=site won't be found by Nominatim

[ngt-github]

A Relation type=site is not found by nominatim. There a few thousand relations of this type and some are holding addr:* tags. Nominatim should find those addresses! JOSM even has a template preset and therefor this relation type is used. OSM Wiki Relation:site
Nominatimquery for an address using type=site
Relation 6037273 should be found

[lonvia]

According to taginfo there are around 140k relations with type=site of which 70k are site=geodesic (some French import). That leaves 70k additional objects, which is doable.

It should be possible to handle them like multipolygons, just need to do some research what to do with the members. They might need to be excluded from the search.

Changes should be mostly necessary in osm2pgsql. If somebody is interested in helping out, then this one should be a fairly easy and useful task.

[polarbearing]

what to do with the members

Treat ways like areas as in MPs, and ignore nodes?

That leaves 70k additional objects, which is doable

Not sure if I get that correctly, does 'doability' depend on scale or numbers?

[lonvia]

what to do with the members Treat ways like areas as in MPs, and ignore nodes?

That part is clear. The question is, if the members should still be searchable. The problem is similar to waterway relations where Nominatim hides the members. Otherwise they would show up in the results as they are generally tagged with names.

Not sure if I get that correctly, does 'doability' depend on scale or numbers?

Numbers. That was a remark on how much the Nominatim database and import time will grow when site relations are included.

[Codain]

When looking at how the waterway relation is handled (https://github.com/osm-search/Nominatim/blob/199532c802fafaa13ae77d1b24cf969e24e8a9d0/lib-sql/functions/placex_triggers.sql#L868:L889), I suggest to implement a generic mechanism to cover also type=site case:

• Have a list of relation types to index and sanitize (type=waterway and type=site to start with) in a configuration file/db (see below)
• For each relation of one of this type which has a name
  • Index the relation
  • Remove index of all members which are indexed and have the same name (and with an optional list of roles and/or types)

Such file would also be used to generalize following code: https://github.com/osm-search/Nominatim/blob/ce08cb6cd75169b1c7ada612d732aae68467e492/lib-sql/functions/ranking.sql#L219:L224

Exemple of such a configuration file: settings/sanitize-relations.json

[
  {
    "class"="site"
  },
  {
    "class"="waterway",
    "ignoreMembers"=[                         # Optional list of OR conditions
      {                                       # List of AND conditions
        "sameName"="true",
        "roles"=[
          ""
          "main_stream",
          "side_stream"
        ],
        "types"=[
          "river",
          "stream",
          "canal",
          "drain",
          "ditch"
        ]
      }
    ]
  }
]

Unfortunately if the idea is agreed I'm not able to work on a pull request since I don't know how to link such JSON file with a SQL function (I guess by passing via a SQL table? or by having a script which would build an SQL function based from a JSON?). However if there is a similar mechanism in place I can probably try to copy it (but with a very limited ability to test the whole chain).