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

description related to tag starting with name is removed #10521

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

draunger
Copy link

@draunger draunger commented Nov 1, 2024

Description:

approach

i have used slice method which slice the key which are starting with name and checks the condition after slicing

attached screenshot after the fix

image

before this fix

image

attached issue

#10287

@Dimitar5555
Copy link
Contributor

I've just did a quick test and it seems like you can add name: true to this list and it will catch all name:xx variants, without all of the extra code you added. It is likely using some sort of regex under the hood, but I haven't looked for it.

_popularKeys = {
// manually exclude some keys – #5377, #7485
postal_code: true,
full_name: true,
loc_name: true,
reg_name: true,
short_name: true,
sorting_name: true,
artist_name: true,
nat_name: true,
long_name: true,
via: true,
'bridge:name': true
};

@draunger
Copy link
Author

draunger commented Nov 2, 2024

@Dimitar5555 i did this before but it does not working

@draunger
Copy link
Author

draunger commented Nov 3, 2024

@1ec5 please review my PR so that i can make changes

@1ec5 1ec5 linked an issue Nov 11, 2024 that may be closed by this pull request
Copy link
Collaborator

@1ec5 1ec5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your patience. In addition to the following comments, please consider writing a unit test for the change. You can find tests related to this file at test/spec/services/taginfo.js.

@@ -222,7 +222,7 @@ export default {
this.keys(params, function(err, data) {
if (err) return;
data.forEach(function(d) {
if (d.value === 'opening_hours') return; // exception
if (d.value === 'opening_hours') return; //exception
_popularKeys[d.value] = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering how this service excludes name, since it isn’t explicitly listed in _popularKeys. It turns out that name happens to be one of the 100 most popular keys that we add to the _popularKeys here. (There’s some additional explanation at #7485 (comment) that I had forgotten.)

@@ -289,7 +289,7 @@ export default {
values: function(params, callback) {
// Exclude popular keys from values lookups.. see #3955
var key = params.key;
if (key && _popularKeys[key]) {
if (key && _popularKeys[key] || key.slice(0,4)==='name') {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

String.prototype.startsWith is less error-prone than comparing a substring manually. A more thorough fix would catch any key if it’s just a localized version of any of the popular keys. A localized key looks like baseKey:xy, where xy is a language code (not necessarily two characters long). I think what you’ve got is OK, but I’d recommend switching to startsWith and also requiring a colon, like name:, in case someone types in a key that doesn’t have it like name_disaster or name_base.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@1ec5 as you said that start with name: will cause to name that starting without colon shows suggestion, so do i change with this key.slice(0,4)==='name' to this => key.slice(0,5)==='name:' ??

Copy link
Member

@tyrasd tyrasd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to what @1ec5 already suggested, I think it would be preferred if this would not be a hardcoded case inside an if statement deep inside the code, especially given that there is already a list of tags for this. For example, one might want to also add loc_name:xx, or description:xx to this. One possible solution would be to change _popularKeys from a dictionary to a (list of) regular expressions:

_popularKeys = [
    /^postal_code$/,
    …
    /^name:../
];

…

if (key && _popularKeys.some(regex => regex.test(key)) {
    …

As this should not be a performance bottleneck, the lost efficiency compared to the dictionary lookup should be negligible. What do you think?

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.

Don't suggest values from Taginfo for name:xx tags
4 participants