Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Index ref, left, right and short 'names' #377

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hendrikmoree
Copy link
Contributor

Some name variants aren't indexed. This also adds these properties

@hendrikmoree
Copy link
Contributor Author

It looks like there also indexes created for:
name.alt.raw, name.int.raw, name.loc.raw, name.old.raw and name.reg.raw
But these are unused. Shouldn't they be removed from the mappings.json?

@lonvia
Copy link
Collaborator

lonvia commented Apr 22, 2019

Sorry for the late reply.

So, the left and right variants should be fine, no objection there.

ref tends to be problematic in my experience as it interferes in strange ways with the other search terms. Might be different with the analyser we use but I'd like to see some tests for that.

I'm not sure that photon needs name:short. The main uses are that it contains a partial variant of name which the index should then have already or it contains a reference for which the objections above apply.

@hendrikmoree
Copy link
Contributor Author

I think name:short and short_name adds useful extra information for example on this nodes: https://www.openstreetmap.org/node/588503900
https://www.openstreetmap.org/way/547703999
This short variant of the same name wont be indexed by the current Photon because it's more of an abbreviation

I see i've included short_name in this PR, not name:short. But i think both will be usefull

@ghost
Copy link

ghost commented Apr 8, 2021

I'd also like to see short_name used, though I'm not familiar with how it would interfere with other search terms. Without short_name you have to remember the full name of some locations, names that are often never used in reality.

@b3nn0
Copy link

b3nn0 commented Aug 17, 2021

Is the ref-indexing still problematic? Because this seems to be quite a significant issue, or am I missing something?
E.g. https://photon.komoot.io/api/?q=K%208279&lang=de does certainly not find the "K 8279"
https://www.openstreetmap.org/search?query=48.057746%2C9.115506#map=16/48.0574/9.1150

The same issue exists for reverse.. It will simply return no usable road name at all:
https://photon.komoot.io/reverse?lat=48.057746&lon=9.115506

Is that something that is planned to be resolved? Feels like quite a severe limitation...
Wouldn't it at least be appropriate to have ref as extra tags so it works at least for reverse?

@CutestNekoAqua
Copy link

yea short_names should be indexed.. example BER short_name for Berlin Brandenburg Airport. Many people use BER instead of the full name because.. I dunno tbh but photon obv just fails finding it for "BER" atm lol

@laem
Copy link

laem commented Jun 5, 2024

Hi, just found this PR looking for why "short_name" isn't indexed.

In France, the Direction du Numérique (French state's head of public IT) is well known by its acronym DINUM.

Lots of places, especially administrative places are known by their acronym.

@CutestNekoAqua
Copy link

Hi, just found this PR looking for why "short_name" isn't indexed.

In France, the Direction du Numérique (French state's head of public IT) is well known by its acronym DINUM.

Lots of places, especially administrative places are known by their acronym.

same in germany :)

@CutestNekoAqua
Copy link

@lonvia what are your thoughts on indexing these?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants