assignLabels: improve duplicate label handling#1507
Conversation
|
Yeah, this is great. We definitely should have built in some simple functionality to "extend" the labels before. And like you said, it's not actually complicated (at least not yet, I bet this system will grow 😇 ) |
|
Hum, nice use case ! And I found an issue with my current PR 😅 |
|
I drafted something for Starbucks 🤔 (streets only for venues with |
|
This is huge from a user experience perspective, ❤️ it |
|
I agree ! 😄 |
ee365c8 to
79280ef
Compare
79280ef to
bcca87e
Compare
|
PR rebase to master. The CI failed because of Fastly outage 😕 |
|
back to normal 👍 |
bcca87e to
b4982aa
Compare
|
Updated and sync with #1565 |
|
Thanks, I have reviewing/merging this on my TODO list. |
fb586b4 to
1205687
Compare
1205687 to
fd1d0e5
Compare
|
I've updated this PR to reflect changes from pelias/labels#42 The interesting change here is this part: https://github.com/pelias/api/compare/1205687cf7ec73ac84ac699f4fa88db6f5fb2f31..fd1d0e5273a1439530ab1713a7b189bbbdd3263c Now |

This is the API part of pelias/labels#42, this will improve the user experience and developer experience.
Sometimes, we can see several identical labels, this is very annoying because we can not distinguish them. This was a long time issue for us @jawg.
Our first response was, this is a integration issue, so update the name when you need to... So we implemented this in our demonstrator to say "hey, it's possible to do it on integration".
Now I realize it's awful for the developer experience... I blame myself terribly for not having thought of putting it in the API earlier... Especially since it's not complicated 😭
So with this PR, Bagneux will return:
And Sao Paulo will return:
Well known localities are still unchanged, for example Paris:
TODO: Change package.json before merge
related: pelias/labels#41 pelias/labels#42