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

Do not use directly discardNames name-suggestion-index #6055

Closed
matkoniecz opened this issue Mar 18, 2019 · 6 comments · Fixed by #8305
Closed

Do not use directly discardNames name-suggestion-index #6055

matkoniecz opened this issue Mar 18, 2019 · 6 comments · Fixed by #8305
Labels
considering Not Actionable - still considering if this is something we want

Comments

@matkoniecz
Copy link
Contributor

matkoniecz commented Mar 18, 2019

See #5930

discardNames from name suggestion index is directly used by iD.

So listing names there will cause iD to list them as invalid and encourage people to delete them.

To avoid this one may add names to discardKeys that are not brands but can be used but it makes contributing to name-suggestion-index more complicated. See osmlab/name-suggestion-index#2488 (comment)

I think that it would be preferable to have iD maintain its own list, based on name-suggestion-index.

Just list filters in discardNames that are discarding invalid names (and use them in validator), list of filters that are harmful in iD and have ability to list filters not appearing in either first or second list.


In case of creation of separate set of entries it may be worth syncing with JOSM - see https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss#L93

@bhousel
Copy link
Member

bhousel commented Mar 18, 2019

Worth mentioning too that name-suggestion-index only looks at a subset of OSM, so it wouldn't contain generic words like "park" or "school" which are worth warning the user about. So maybe 2 lists does make sense.

@bhousel bhousel added the considering Not Actionable - still considering if this is something we want label Mar 18, 2019
matkoniecz added a commit to osmlab/name-suggestion-index that referenced this issue Mar 27, 2019
@matkoniecz
Copy link
Contributor Author

matkoniecz commented Apr 20, 2019

Also amenity=place_of_worship religion=muslim name=mosque, amenity=place_of_worship religion=muslim name=cami ("mosque" in Turkish and used 1500+ in Turkey as a descriptive name), amenity=place_of_worship religion=christian name=church, amenity=place_of_worship religion=christian name=Biserica (meaning "church" in Romanian), amenity=toilets name=Toilet.

( from proposed JOSM patch https://josm.openstreetmap.de/ticket/17629#comment:7 that was created based on things spotted in name-suggestion-index )

@matkoniecz
Copy link
Contributor Author

One of mappers reported that Kebabai is a valid name in some contexts, despite being (correctly) placed in discardNames.

@bhousel
Copy link
Member

bhousel commented Dec 16, 2020

One of mappers reported that Kebabai is a valid name in some contexts, despite being (correctly) placed in discardNames.

For stuff like this we usually just move it out of discardNames into one of the other discard lists.

bhousel added a commit to osmlab/name-suggestion-index that referenced this issue Dec 16, 2020
@empersOSM
Copy link

Hey, the mapper that said that Kebabai may be a valid name is me, empers. In Lithuania, a lot of Kebab-style places are just named Kebabai, or something else generic. So thank you for doing something about it and thank you to Mateusz for raising the issue.

@matkoniecz
Copy link
Contributor Author

@bhousel Thanks for a fix! I was unaware (or forgot) about this workaround.

@empersOSM Note that effect will not be visible immediately. NSI likely needs to make a release and so on.

Nice that it turned out to be fixable despite my earlier claims :)

And in cases of similar validator false positives - in general it makes sense to report them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
considering Not Actionable - still considering if this is something we want
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants