"operator" field not indexed on some (?) objects

[jarek]

https://nominatim.openstreetmap.org/details.php?place_id=3601277 gives Name: Railyards (name) Victoria Harbour Ferry (operator). The underlying OSM node is https://www.openstreetmap.org/node/373729935

https://nominatim.openstreetmap.org/details.php?place_id=16751979 gives Name: Empress Dock (name) but no operator. However the underlying OSM node https://www.openstreetmap.org/node/1522688474 has had operator=Victoria Harbour Ferry since 2017.

This came up in https://www.openstreetmap.org/note/1740508, where it was reported that searching for "Victoria Harbour Ferry" doesn't return the Empress Dock at all.

The complete sets of tags on the two nodes, as far I can see:

amenity=ferry_terminal
name=Railyards
operator=Victoria Harbour Ferry

amenity=ferry_terminal
name=Empress Dock
operator=Victoria Harbour Ferry
wheelchair=limited

Railyards was last updated in Nominatim Sun, 19 Aug 18 00:42:18 +0000; Empress Dock was last updated Sun, 24 Feb 19 05:11:22 +0000 - have you perhaps stopped indexing the operator field since August 2018?

One more difference that I see: Empress Dock is also part of a footway.

Am I possibly overlooking something? Is tagging on the Empress Dock somehow subtly wrong or weird? Is this intended behaviour, import problem, or another bug?

[lonvia]

There was a change in behaviour when changing to a configuration style forthe osm2pgsql import. I did narrow down the inclusion of operator further because the tag tends to be problematic. In particular when there are many objects with the same operator then the search results tend to become useless.

We can reintroduce the operator tag for selected amenity types, if necessary. ferry_terminal would surely be less problematic. Question would be: when searching for 'Victoria Harbour Ferry' do you expect the ferry route to show up or the terminals.

[jarek]

Ah okay. The confusion was from change of behaviour and other nodes not having been reindexed yet. If it'll be eventually consistent (when the other nodes get the operator dropped too) it's probably fine, changes aren't strictly required.

I would leave the decision on reintroducing it to you then.

I would imagine the largest ferry operators could operate perhaps up to a hundred ferry terminals? BC Ferries claims to have the world's second largest fleet and I count around 45 piers/terminals. For Alaska Marine Highway I count around 30 terminals. Both of these are rather spread out geographically, unlike Victoria Harbour Ferry. I don't know how problematic this scale is for search results (I suppose it's better than thousands of bus stops in a city).

I'm used to Nominatim returning points (or closed ways like buildings) so I guess personally I would expect searching for "Victoria Harbour Ferry" to return the piers/terminals - if anything. But by now I have some expectation of how OSM works internally (and if I wanted to find ferry stops in Victoria I'd head to Overpass), so I'm not the most neutral source.

[lonvia]

30-50 points are not problematic in a sense that they throw off search. But the results are not particularly useful either anymore as Nominatim will basically return 10 random results out of all of them.

Alright, I'll leave it as is then for now. Searching for ferry routes unfortunately looks to have the same issues as search for other routes. So that is not simple to solve.

Closing here. If somebody has requests for indexing operator for specific objects, please open separate issues.