-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add region to default labels if different from city #43
Conversation
I think this can serve as a replacement for #41, with a bit of refinement. It more closely follows our existing logic to use |
d46e1a1
to
ea52ea2
Compare
A couple of caveats to this approach, just putting them out there in case they are easy fixes:
Happy to punt those topics, just need to add some Issues for them. |
ea52ea2
to
5003348
Compare
Ok, after some testing we definitely needed some basic normalization. I borrowed some code from the API that looks perfect for the task: |
5003348
to
89c56f5
Compare
Tests should verify behavior, not implementation details like the number of properties on an object
This adds the region to the default labels, but only if the _region name_ is different from the _city name_ (defined as locality or localadmin name). The intent is to handle major world cities like Berlin, Sao Paulo, Paris, etc that are contained within an administrative region of the same name, and are so well known that they do not require any additional specifiers. Differences such as capitalization and accents are ignored for comparison purposes, since they often exist in real data. In the more common case where the region and city names are different, the region abbreviation is preferred, with the region name being returned only if the abbreviaton is not available.
92d8af6
to
85c36e4
Compare
As a small country, the regions in Singapore are not particularly useful, and they do not appear to be used in address labels. By adding a Singapore specific label schema, we can avoid regions appearing in Singapore labels after we enable them by default in #43.
Some quick examples of how this looks now: Likewise for Berlin. Some other cities with berlin in the name in Berlin Brandenburg have an abbreviation: |
As a small country, the regions in Singapore are not particularly useful, and they do not appear to be used in address labels. By adding a Singapore specific label schema, we can avoid regions appearing in Singapore labels after we enable them by default in #43.
The classic testcase for Germany is that Frankfurt am Main and Frankfurt an der Oder produce different labels. |
I think this is a much better default to have, there may be some improvements to be made on a per-country level but this raises the bar for anything using the |
As a small country, the regions in Singapore are not particularly useful, and they do not appear to be used in address labels. By adding a Singapore specific label schema, we can avoid regions appearing in Singapore labels after we enable them by default in #43.
This includes improvements for: - the default label format, adding region, including handling major cities in a region of the same name (pelias/labels#43 - a new label format for Singapore, handling current and future WOF data (pelias/labels#45)
This includes improvements for: - the default label format, adding region, including handling major cities in a region of the same name (pelias/labels#43) - a new label format for Singapore, handling current and future WOF data (pelias/labels#45)
This adds the region to the default labels, but only if the region name is different from the city name (defined as locality or localadmin name).
The intent is to handle major world cities like Berlin, Sao Paulo, Paris, etc that are contained within an administrative region of the same name, and are so well known that they do not require any additional specifiers.
In the more common case where the region and city names are different, the region abbreviation is preferred, with the region name being returned only if the abbreviation is not available.