-
Notifications
You must be signed in to change notification settings - Fork 884
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
Have the matcher handle generic/common words too #4924
Comments
This lets us store properties per kv in preparation for #4924 Also upgrade code to use es6 Maps instead of objects
The recent planet scan added "NHS" to the ambulance_station.json file, which I removed, but "npm run build" put it back again - as the operators are already locally defined, would the below code exclude it from returning? "properties": { |
Does NHS operate ambulance stations? |
NHS is like the parent organisation, and under it is regional organisations which run the ambulance stations / service, such as: ... so while I think it's reasonable for people to mark an ambulance station as being run by the NHS, it would be more correct for the regional organisation to be tagged (such as those listed above), and perhaps "NHS" to be a matchname for each region. |
Makes sense - yes it would be ok to |
Currently the matcher code is only used for matching canonical items in NSI:
But it doesn't do anything for generic names
generic/named?
Up until last week, NSI had a bunch of discard regular expressions in both the
config/genericWords.json
file, but also in thekeepKV
anddiscardKVN
properties in theconfig/trees.json
file. This was confusing so I changed it - NSI now can differentiate between generic/named words, and these are stored with each category (#4906).This relates to openstreetmap/iD#6055 - it's basically saying that iD needs to be smarter about whether a word is really a generic word or whether it's a common name in some contexts.
A note on terminology (I need to document this, sorry):
going forward
So what I'd really like to do is have the matcher do a bit more and handle the generic words too.
This will make things simpler on the iD validator side, because it will mean fewer files to fetch and all the code for matching names can be in one place.
The text was updated successfully, but these errors were encountered: