Add Asian Highway Network shields - #749
Conversation
| "case", | ||
| // Azerbaijan, China, Iran | ||
| ["within", AsianHighwayBorders["az-cn-ir"] || nullIsland], | ||
| "green", | ||
| // Japan, South Korea | ||
| ["within", AsianHighwayBorders["jp-kr"] || nullIsland], | ||
| "white", | ||
| // Indonesia | ||
| ["within", AsianHighwayBorders.id || nullIsland], | ||
| "white_id", | ||
| // India | ||
| ["within", AsianHighwayBorders.in || nullIsland], | ||
| "green_in", | ||
| // Armenia, Cambodia, Malaysia, Myanmar, Philippines, Russia, Thailand, Vietnam | ||
| "blue", |
There was a problem hiding this comment.
Ideally, the vector tiles would indicate the country code of each feature, as the Mapbox Streets source does. In lieu of that convenience, I manually drew polygons that cover the major signage regions, saved them in GeoJSON format, inlined each one into a within expression (to test whether the feature lies within the polygon), and finally embedded this expression inside each image component of the text-field expression representing one shield in a concurrency.
This bloats the style JSON to a whopping 0.99 MB (1,034,181 bytes), far above the high water mark set in #666. Part of the problem is that this expression gets repeated six times, since we support up to a six-way concurrency. Unfortunately, GL JS requires the within expression’s argument to be a literal object and refuses to evaluate it as an expression, so we can’t bind a variable to the GeoJSON object and reuse it multiple times within the overall expression.
We could optimize the GeoJSONs a bit more, for example by reducing coordinate precision, but I’ve already simplified each country’s borders very aggressively. Most of the polygons are essentially a convex polygon around the country’s international border crossings, with some extra buffer to include the country’s trunk road network in full. Clearly our support for this network would benefit from either more granular tagging or more thorough postprocessing.
| Color.shields.black | ||
| ), | ||
| }; | ||
| shields["AH"] = shields["AsianHighway"]; |
There was a problem hiding this comment.
This wiki page specifies network=AsianHighway for Asian Highway routes (along with int_ref, grr), but a significant minority of routes are tagged network=AH instead. I can’t find any discussion of using AH anywhere, so it’s probably just a lack of awareness about the AsianHighway standard. A two-letter code like AH would be problematic anyways, because it would be easily confused with a (nonexistent) ISO 3166-1 country code.
There was a problem hiding this comment.
Sounds like a strong case against supporting network=AH. I would rather leave it out to encourage mappers to use a standard tagging scheme.
There was a problem hiding this comment.
Indeed, I’m definitely planning to remove support for it before merging. For now, though, it is necessary for demonstrating some of the cross-border differences in shield designs, because they happen to coincide with cross-border differences in how some route relations have been tagged. (I suspect it’s an oversight rather than anything intentional.)
Added shields for the Asian Highway Network that depend on the country. Added GeoJSON files for line-in-polygon tests.
| ], | ||
| [ |
There was a problem hiding this comment.
This polygon has two outer rings. It should be a multipolygon geometry instead. GL JS has no problem with this weirdly-formed polygon, but for instance GitHub’s GeoJSON previewer makes a mess of it.
Added shields for the Asian Highway Network.
Unlike the United Nations’s Economic Commission for Europe (UNECE), which manages the international E road network, the Economic and Social Commission for Asia and the Pacific (UNESCAP) has yet to harmonize Asian Highway route signage in each of its member countries. As a result, a single route can alternate among multiple different appearances along its length. We need to preserve some of the distinctions in this style, because for instance some countries reserve the color blue for AHs while others reserve blue for non-AHs.
Fixes #122.