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

First- and second-level routes of Iran #464

Open
claysmalley opened this issue Jun 28, 2022 · 7 comments
Open

First- and second-level routes of Iran #464

claysmalley opened this issue Jun 28, 2022 · 7 comments
Labels
enhancement New feature or request internationalization mapping Changes needed to OpenStreetMap shields

Comments

@claysmalley
Copy link
Member

Iran has two levels of road numbering underneath freeways (#463). First-level roads have a white-on-green rectangular shield, and second-level roads have a black-on-white rectangular shield.

These two networks are conflated by the tag network=ir:national. For support to be added for these shields, the tagging scheme would need to be changed to distinguish first- and second-level routes.

Iran_First_Level_Road_44 Iran_Second_Level_Road_122

@1ec5
Copy link
Member

1ec5 commented Jun 28, 2022

I’ve asked for help in the OSM Asia Telegram chat.

@seav
Copy link

seav commented Jun 28, 2022

Looking at this Wikipedia article, I'm willing to bet 1st-level are always 2-digit codes while 2nd-level are always 3-digit codes.

@claysmalley
Copy link
Member Author

That would make sense, though we don't (and won't) support switching shield appearance based on the number of digits. We expect that network=* is enough to determine what the shield should look like.

There are limited, explicitly documented exceptions to this, where we override the shield for a network=* based on its ref=* value. But we do this on an individual basis, not for a whole range of numbers.

@seav
Copy link

seav commented Jun 29, 2022

But I imagine changing the tagging scheme, which seems to work well for Iranian mappers given how it's structured and how it seems there won't be any overlap between 1st- and 2nd-level ref=* values, just to suit your renderer as a classic case of tagging for the renderer. It's not Iranian mappers' fault that the shield colors are different.

@1ec5
Copy link
Member

1ec5 commented Jun 29, 2022

But I imagine changing the tagging scheme, which seems to work well for Iranian mappers given how it's structured and how it seems there won't be any overlap between 1st- and 2nd-level ref=* values, just to suit your renderer as a classic case of tagging for the renderer.

A charge of “tagging for the renderer” shouldn’t be leveled against a suggested change solely because a tagging issue has been exposed by a renderer. Essentially, it’s our understanding that network has been misunderstood as a differently formatted version of operator, whereas in fact the national road authority operates two different highway systems. Indeed, they communicate this distinction to the public using distinctly colored shields. The color is color-coding, not a mere splash of decorative color.

This project is designed to make shield display a data-driven process, giving local mappers more autonomy to fix common problems and even some edge cases without having to learn Git and JavaScript. That requires minimizing the amount of hard-coded heuristics in the renderer. But we aren’t suggesting a purely presentational tagging scheme like osmc:symbol.

It's not Iranian mappers' fault that the shield colors are different.

No blame is being cast. This is only about understanding the problem and working toward a resolution in good faith, hopefully at some point in cooperation with mappers familiar with the country. Similar efforts are underway in a number of countries, as you can see in this issue tracker. In most cases, the original tagging was an oversight, or a mistaken assumption by remote mappers, rather than an intentional decision by local mappers.

This is the natural result of OSM Americana being only the second major consumer of the network key on road route relations in OSM’s history. The first is OsmAnd, but that project has not been as proactive in reaching out to local communities about getting their countries’ shields rendered correctly. (It hasn’t managed to work around these tagging issues either.)

@seav
Copy link

seav commented Jun 29, 2022

I would like to question the assumption that "different shields" = "different network".

Granted that I'm not very familiar with the Iranian national road network, but the way they separate routes into 2 levels ("First Level" and "Second Level") but with all routes having the same naming format, "Road XX" (unlike in the U.S.: "Interstate X" vs. "U.S. Route YY"), and with the "XX" values being unique for all routes regardless of level implies that all routes are considered as part the same network.

In the Philippines (for which you guys have already merged the shields, thanks!), the national highway agency also classifies our national highways into three classes: "Primary", "Secondary", "Tertiary". Primary routes are given 2-digit codes while secondary routes are given 3-digit codes. (Tertiary routes aren't numbered.) The difference with the Iranian system is that PH uses the same shield format for both numbered classes while IR uses two shield formats.

I understand the philosophy behind going for a "data-driven process" that empowers mappers to be able to properly display the correct shield format by tweaking tags in the database instead of code in the renderer. But maybe we can make the renderer smarter with not much loss of generality? Can the renderer use other tags aside from network=*. Maybe if we introduce a designation=* and use the combination of network + designation to select the correct ShieldDef?

My point is it might not be wise to force tagging different network=* values just because they use different shields, when the routes themselves form part of the same uniquely-numbered network.

@1ec5
Copy link
Member

1ec5 commented Jun 29, 2022

In the Philippines (for which you guys have already merged the shields, thanks!), the national highway agency also classifies our national highways into three classes: "Primary", "Secondary", "Tertiary". Primary routes are given 2-digit codes while secondary routes are given 3-digit codes. (Tertiary routes aren't numbered.) The difference with the Iranian system is that PH uses the same shield format for both numbered classes while IR uses two shield formats.

As I understood the discussion in #195, the Philippines classifies roads into the three classes, but the routes are either expressways or national routes. In some cases, the road classification had been added to the network value, while in other cases it was set on a separate nhn:class key. network ended up getting simplified not just because the shields were alike, but rather because network had previously been conflating two orthogonal concepts. (designation can be added to the constituent ways.)

The identical naming scheme and lack of numerical overlap are not unique to Iran or the Philippines. Other examples include the Canadian provinces of Alberta (#227), Manitoba (#272), and New Brunswick (#275), and the U.S. states of Missouri (#284) and Virginia. In all these cases, the routes are called “Route 123” regardless of the network, but there are multiple shields and they are understood to represent multiple systems. On the other hand, each of the routes in Yukon (#252) has a different-colored shield, but nonetheless they collectively form a single system.

In other words, a distinct shield design is not the determining factor in distinguishing a route network, but it is one of several factors, along with any naming difference or numeric overlap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request internationalization mapping Changes needed to OpenStreetMap shields
Projects
Development

No branches or pull requests

3 participants