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

Add shields for Iran freeways #463

Merged
merged 2 commits into from
Jun 28, 2022
Merged

Add shields for Iran freeways #463

merged 2 commits into from
Jun 28, 2022

Conversation

claysmalley
Copy link
Member

@claysmalley claysmalley commented Jun 28, 2022

Adds shields for national freeways and roads of Iran.

In real life, highways are posted with both Western Arabic numerals and Persian numerals. Since we're emulating an American road atlas style and using English labels wherever possible, I think it's appropriate to stick with the Western Arabic numerals found in ref=*, though the Persian numerals are specified in ref:fa=* which may be helpful when implementing language switching in the future (#21).

Screenshot from 2022-06-27 20-04-03

src/js/shield_defs.js Outdated Show resolved Hide resolved
src/js/shield_defs.js Outdated Show resolved Hide resolved
@claysmalley claysmalley changed the title Add shields for Iran Add shields for Iran freeways Jun 28, 2022
@bgo-eiu
Copy link
Contributor

bgo-eiu commented Jun 28, 2022

Would make more sense to include both where signs in real life

Numerals are closer to symbols than they are to words as far as language is concerned, and it's actually quite rare internationally for highway shields to use the same numerals associated with the local . Treating the Iran shields like this could tentatively mean that one would have to switch languages to see what the shields in Iran look like, then switch back to see what the shields in all the surrounding countries look like, which is counterintuitive. If a math textbook didn't print pi because Americans don't speak Greek, that would likely make it less legible

Also, realistically, anyone doing long distances road travel in this region - which is what route shields are ostensibly for - realistically needs to be able to read both. Unfortunately it's not as common as it used to be for safety reasons, but some of my family used to do road trips to Afghanistan and Iran from Pakistan as tourists, and they would have used paper maps, and understood both numeral systems. (In Pakistan and Afghanistan, the numerals would always be "English" so knowing where they differ is helpful.) So it seems kind of contradictory to the idea of Americana being useful in a similar way to paper maps, as anyone who would be using paper maps in this region would be unlikely to find this interpretation of what numerals are useful for helpful. It's not even that hypothetical that someone doing road trips out of Iran could find Americana useful, things get around quickly online

@1ec5
Copy link
Member

1ec5 commented Jun 28, 2022

If a math textbook didn't print pi because Americans don't speak Greek, that would likely make it less legible

This doesn’t seem to me like an apt analogy. The Greek letter pi has been adapted to other writing systems to the point that Unicode has extra codepoints for pi in a mathematical context. More to the point, the real-world shields feature both numbers, one over the other. (Asian Highway shields in Iran don’t even have Persian numerals on them.)

Even if we wanted to, we have no technical capability to use ref:fa at the moment. The vector tiles don’t include that tag, and none of the currently available fonts contains Persian numeral glyphs. I don’t think it’s strictly necessary to hold off on any support for these shields until all those things are in place, which could take a while. This is a clear case of internationalization on a “best effort” basis: #385.

Copy link
Member

@1ec5 1ec5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let’s ticket out support for national routes, which are more numerous than the freeways.

@claysmalley claysmalley merged commit 1f7b9ea into main Jun 28, 2022
@claysmalley claysmalley deleted the shields-iran branch June 28, 2022 02:17
@bgo-eiu
Copy link
Contributor

bgo-eiu commented Jun 28, 2022

The less bad option would be to not include shields in switching languages if that happens, that's really the main thing that would be more confusing than necessary. Looking at pictures though, there do seem to be signs that show one and not the other and I think it would be helpful to reflect that on the map at some point because it's a noticeable distinguishing feature.

That Unicode did that for pi and that more fonts don't support multiple numeral systems is more just an indicator of Eurocentricism on their part, considering there's more people in the world bilingual with both English and a language which uses Perso-Arabic scripts than there are Americans total (and possibly even just more than monolingual English speakers generally). There's also still no way to see a whole range of common Perso-Arabic glyph representations without installing special fonts for it so Unicode isn't exactly logical in what they encode for.

Road signs are different from pi in that you don't actually need to know what values they represent, because you don't need to do any math with them. What's funny is if you look at the Urdu ref tags on route relations where they exist, the translation for "M-25" literally spells out "em" ام like someone sounding out the letter M using Arabic script, then keeps the numerals the same, which would get sounded out by many as well rather than translated. They don't use م-25 even though that's technically the first letter of transliterated motorway, because you don't actually need to know English to know what the letter M is, and treating numbers and letters as symbols rather than abbreviations or representative of words makes more sense in a multilingual setting where 2 or ‌ ‌‌੨ or anything else could be read differently depending on the native spoken language of the reader.

@1ec5
Copy link
Member

1ec5 commented Jun 28, 2022

That Unicode did that for pi and that more fonts don't support multiple numeral systems is more just an indicator of Eurocentricism on their part, considering there's more people in the world bilingual with both English and a language which uses Perso-Arabic scripts than there are Americans total (and possibly even just more than monolingual English speakers generally).

This is quite off-topic, but no, it’s only for representing certain Greek-derived symbols for certain mathematical purposes, such as symbols for vectors and maps. (Not to be confused with vector maps!) Your elementary school pi is safe; it uses a character from the Greek block.

I get that seeing a transliterated shield in Americana isn’t going to be so useful for roadtripping in certain parts of the world, but keep in mind that this is not a real turn-by-turn navigation map, despite the aesthetic resemblance to some maps that might’ve been used for that purpose in the past. A map that’s actually optimized for turn-by-turn navigation would translate at most place names but not other labels, especially not road names, whereas we’re using all the English translations we can get our hands on.

There may well be other OSM-based projects for which your insights about number systems are spot-on and timely, but it’s a stretch for this repository as it stands. We aren’t even setting the preserveDrawingBuffer option that would allow this map to be printed (at a significant performance penalty).

@bgo-eiu
Copy link
Contributor

bgo-eiu commented Jun 28, 2022

Yes, I'm aware that's what the different pi variant is for, that doesn't change it being reflective of a Eurocentric priority (definitely not implying math is Eurocentric either). It's simply the fact that symbols used in common writing in some parts of the world have never been prioritized, while these characters have. What Unicode is capable of offering for writing math is inherently limited anyway, people wouldn't put up with using LaTeX if they didn't have a really good reason to.

I also don't really see how it's a stretch - the question of what transliterating refs is useful for is not clear. It would be weird operating under the assumption that Americans don't travel or use world maps. I do actually use maps a lot, and I would feel silly maintaining a fork of Americana to make minor tweaks to things like this instead of just doing a pull request. I don't really see the point of this kind of dismissiveness/condescension; there's no way to work on these things that doesn't involve a discussion.

@1ec5
Copy link
Member

1ec5 commented Jun 28, 2022

I’m sorry that my response came across as dismissive or condescending. The fact of the matter is that we don’t have the ability to implement the Eastern Arabic numerals in Iran’s shields at this moment, but for solvable reasons. The font can be changed, the tiles can pull in keys other than ref, we could even maybe convince the Iranian mapping community to relegate the Western Arabic numerals to a different key – all that requires work outside of this repository.

Taking a step back, we’re discussing a pull request for an implementation of shields for Iran’s freeways based on the data that’s available to us, so allegations of the Unicode standard being Eurocentric don’t seem relevant to this repository. If due to the numbering situation you believe this pull request should not have been merged, instead leaving these freeway icons as unadorned Western Arabic numerals, then please open an issue explaining your reasoning.

You may also want to look at #385, which so far is less ambitious than what you seem to be suggesting as the project’s purpose. It’s not that Americans don’t travel using world maps, but there’s historically been a difference between a local guide map and a world map for studying the world at one’s leisure. There are many examples of both kinds of maps introducing some degree of linguistic variety, such as National Geographic glossing place names in (a Latin transliteration of) the local language, but their ambition does not extend to labeling everything as it is on the ground.

It’s a classic tradeoff: the more this map becomes a lesson in linguistics, the less it can serve as a lesson in geography to a broad audience of English speakers in the U.S. Both groups of users deserve to be served by a style, but it doesn’t have to be the same style, or there can be a user preference. We will likely make similar tradeoffs for POI icons, choosing icons that Americans are intimately familiar with at the expense of matching what’s on the ground. If we don’t make such tradeoffs, we will undoubtedly end up in the same analysis paralysis that openstreetmap-carto frequently finds itself in, and no one will be well served.

@bgo-eiu
Copy link
Contributor

bgo-eiu commented Jul 2, 2022

This PR is fine, all I was saying is it's still worth considering showing the full shield at some point given previous discussions on the topic.

It's only a lesson in linguistics to the extent that a "BUS" panel is a lesson in economics. Unlike many (but not all) place names, shields are often understood to be symbolic, especially considering that in most countries that aren't America long-distance travel and cross-country travel are the same thing, and shields are already designed to be understood by foreigners rather than designed in a way that only makes sense to locals. You would be hard-pressed to find a map which displays US interstate shields in another numeral system in world maps for studying at one's leisure produced in any country, and likewise it's impossible to avoid the fact that most contemporary English speakers do not live in America or Europe, and attempts to re-interpret information in multilingual countries as if this isn't the case can result in more confusion than clarity. It would be considered nonstandard to print a map with the name Bombay instead of Mumbai or Nanking instead of Nanjing, or even Ivory Coast instead of Côte d'Ivoire, even though the former in each case is likely more familiar to Americans of not-recent-immigrant-parentage, because it speaks to an antiquated notion of how the English language is used. It's less that it seems like a tradeoff but a rather unorthodox approach which doesn't service geographic or linguistic understanding. (If a non-American map producer were to alter information under the same reasoning, arguably it would come across as uncharitable or even insulting to American English speakers, to suggest that our dialect of English requires a dumbing-down that no other does.)

I was thinking about it, and the true equivalent of "translating" a shield in non-Latin characters would be literally sounding out the name of those characters using Latin characters, like M-5 gets transliterated as ام 5 and not 5-م. That's neither here nor there, but perhaps part of why this seems confusing is that is something which most English-speakers do that Americans oddly don't have much precedent for.

I agree allegations about Unicode aren't relevant here, but what I brought up was an observable fact not an allegation.

@1ec5
Copy link
Member

1ec5 commented Jul 2, 2022

I was thinking about it, and the true equivalent of "translating" a shield in non-Latin characters would be literally sounding out the name of those characters using Latin characters, like M-5 gets transliterated as ام 5 and not 5-م. That's neither here nor there, but perhaps part of why this seems confusing is that is something which most English-speakers do that Americans oddly don't have much precedent for.

Yes, I was casually suggesting in #465 (comment) that we find a way to display Taiwan’s provincial routes with the Latin suffixes instead of the signposted Hanzi, e.g. “2a”, “2b”, “2c” instead of “2甲”, “2乙”, “2丙”. There is precedent for this transliteration not only in official contexts but also in foreign-language documentation, such as on the English Wikipedia. However, it ideally would be backed by tags in the data, similar to what the Iranian mappers have done with ref and ref:fa. Automated transliteration would be far less desirable.

@ZeLonewolf
Copy link
Member

Thanks for the great discussion here, unfortunately it will be lost buried in a PR for Iranian freeways. Could we start one or more new issues discussing the specific classes of issue relating to signage in non-latin character sets? I'm fully in favor of better internationalization but don't want this to get lost here.

@1ec5 1ec5 mentioned this pull request Oct 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

4 participants