Deduplicate names in gloss; gloss towns #670
Conversation
Replaced the general-purpose find-and-replace expression-generating function with a special-purpose string scanner that can only look for semicolons but also accounts for escaping and space padding in the same pass.
| typeof needle === "object" ? ["length", needle] : needle.length; | ||
| let needleEnd = ["+", needleStart, needleLength]; | ||
| let iteration = numReplacements; | ||
| let rawSeparator = ";"; |
There was a problem hiding this comment.
I spilled a lot of ink in this forum discussion about the need for a reliable delimiter – the semicolon. But as a thought experiment, what if we pretend that one of the popular ad-hoc delimiters is unambiguous enough to split on instead?
| Sad reality | Simulation |
|---|---|
 |
 |
 |
 |
 |
 |
 |
 |
Alas, we can’t just turn every hyphen or slash or space into a value delimiter:
| Sad reality | Sadder simulation |
|---|---|
 |
 |
 |
 |
For better or worse, places that use these other delimiters will simply have to endure suboptimal labeling.
|
Great work! For places with multiple glosses, would it be better if each label has its own parentheses on a separate row? Just thinking that the open parenthesis on one line and the close parenthesis on the last line looks a touch uneven. |
This is probably only hypothetical for now, since so few places with long names or many local languages are using the semicolon in their
The only practical way to resolve this imbalance would be to nix the parentheses and rely on font attributes to distinguish the gloss from the main text. Some maps do rely on italics or a horizontal bar to set off the gloss, but I’m not sure it would work as well in this style, especially since we allow the label to appear above the icon. If the main text and gloss have fonts that differ too much, then the main text gets visually separated from the icon, as if it’s a separate label. Moreover, italic is not a real font style in most writing systems; American print maps get away with it because they always use romanizations rather than the original writing system.
|
|
When localized to Hebrew: I assume this is a tagging error? |
|
According to both OSM and Wikidata, “שיכון סקווירא” is New Square’s name in Yiddish. According to Wikidata, the town has a different name in Hebrew, “ניו סקוור”, which is what you’re seeing outside the parentheses as the main text when setting the preferred language to Hebrew. #586 tracks the lack of a dedicated Yiddish name field in the vector tiles. |
Replaced the general-purpose function for generating string replacement expressions with a function for generating an expression that specifically scans a string for semicolon delimiters, escaped semicolons, and space padding after a semicolon. Compared to #666, this change decreases the overall minified style JSON size1 (a rough proxy for style complexity) from 954,393 characters down to just 932,343 characters.
With this optimization in place, a city’s local-language name gloss now omits any name that matches the city’s name in the user’s preferred language to avoid repetition. This brings the size back up to 943,759 characters. Unfortunately, every multilingual
place=cityis currently tagged with anamethat contains delimiters other than a semicolon, making this enhancement rather pointless. To make this deduplication worthwhile, this PR also enables a local-name gloss ontowns too.Previously, I mentioned in #471 (comment) that American maps and atlases only gloss major city labels, but we’ve already been glossing every
citylabel. Spot-checking shows that label density isn’t suffering too much from the more verbose town labels, and in any case we support zooming in. The one downside to enabling glosses on town labels is that the town label layer has to repeat the massive expression that we’ve been using for cities: we’re back up to 952,745 characters – still less than we started out with, but only slightly./ref #592 (comment) #666 (comment)
Footnotes
JSON.stringify(map.getStyle()).length↩