Closed ZeLonewolf closed 2 years ago
I've looked into this, of course.
The shield renderer that I have (for raster tiles) uses SVG icons, they're just not the simplified ones from Rebusurance.
Note that 3 digits are not enough. New York has routes numbered 100A, 100B, 100C, 104A, 104B, 120A, 146A, 146B, 157A, 170A, 248A, 365A, 439A, 961F, 962J, 990L, 990V. (The last four are reference route numbers that were promoted to touring routes, possibly by mistake.) Texas farm-and-market roads are mostly four digits. Several counties have four- and five-digit route numbers, as do USFS roads.
We should also be prepared for West Virginia's fractional route numbers. https://www.flickr.com/photos/andrew-turnbull/5904974507
What I've found is that shield rendering requires up to three fields, whose names I inherited from Phil! Gold: num
, suf
and mod
.
num
is the base number of the route. (Some routes, such as the New Jersey Turnpike or the Garden State Parkway) have distinct shields but don't have numbers. suf
is a suffix to the number. It's sort of optional for localities like Arkansas or NY, where it's used because a route like '9W' has the 'W' in a smaller font on the signs (and Phil! was a perfectionist in that area). But it's essential for its use in the two-numbered West Virginia roads. mod
is used for making large images of the shields, where it gets the county name on county roads that use the blue pentagon or white square (and similar situations), or a BUSINESS, ALTERNATE, TRUCK, ... banner on routes that require them. (Some states place this banner INSIDE the shield rather than adjacent to it.) WIth a minimal amount of work, this could be eliminated, but we should ask ourselves if we want to limit ourselves to shield placement on the map, or whether we want to provide a larger set of harmonious rendered shields that could appear, for instance, in navigational prompts on a mobile device.
The current code (as I said, Phil! is a perfectionist) also allows for the possibility of 1.5, 2.5, 3.5-digit numbers; that is, numbers that can pack in a narrower shield because the contain one or more '1' digits. (This would be irrelevant if we are using a font where the digits are equal width, but for fonts like Roadgeek makes a difference to the appearance.) I'd say not to rule it out.
If anyone wants to provide simplified SVG templates, make pull requests to modify files in the templates
directory of https://github.com/kennykb/osm-shields and I'll be happy to show you what they look like on a map. The SVG files simply contain text ttems with %num%
, %mod%
and %suf%
that are replaced with the values. (At the same time as the replacement, the code also produces raster images at a range of nominal sizes, but this can be adapted to the rendering pipeline.)
Here's what the current OpenMapTiles can do out of the box:
We'll need to explore whether all of these variants are reflected in the "ref" data served up by OMT and if not, generate customized layers.
I've added the WV "fractional style" route designations as a separate ticket #13, so let's split discussion of that edge case there.
The current code (as I said, Phil! is a perfectionist) also allows for the possibility of 1.5, 2.5, 3.5-digit numbers; that is, numbers that can pack in a narrower shield because the contain one or more '1' digits. (This would be irrelevant if we are using a font where the digits are equal width, but for fonts like Roadgeek makes a difference to the appearance.) I'd say not to rule it out.
This probably no longer needs to be a server-side consideration, apart from providing the necessary half-width sprites, because the Mapbox Style Specification’s expression language supports counting the number of characters in a string and finding a substring in a string.
An initial pull request #14 does the base importing of rebusurance shields, using the 2 digit versions. They are horizontally scaled on the client side and a scripted edit was made to make the Interstate highway shield crowns pointier, which was favored by folks looking at screenshots in Slack. This is an initial cut that will support a wider integration of rebusurance shields once design work is complete (provided that they remain consistent with what ends up being designed).
In recent highway shield work, I've been moving away from rebusurance shields in favor of a more craft approach that satisfies the visual expectation of local map users in the US. I've found that based on the adjustments that were needed to make the shields look right on an appropriate map scale, it's just easier to cuomize each shield on a case-by-case basis. Thus I'm closing this issue in favor of other tickets in the style of #13 to be posted where contributors can propose specific shields to be added to the style. I thank @1ec5 for the important stylistic influence that the rebusurance project has had on the visual appearance of shields in this style.
Current work on highway shields is happening on a separate branch, which is blocked from merging until OpenMapTiles 3.13 is released: https://github.com/ZeLonewolf/openstreetmap-americana/tree/openmaptilers-new-features-test
True-to-life highway shields are not optimized for map display. We should consider using simplified shields, specifically: http://github.com/1ec5/rebusurance
Integrating these shields early in the project timeline has the following advantages:
The following integration process is proposed:
This will allow the shields to be automatically integrated into the style sprite sheet without replicating them in the repository.
There are two possible strategies for scaling that need to be investigated:
rsvg-converter
to pre-generate 2- and 3-digit versions of shields