-
Notifications
You must be signed in to change notification settings - Fork 62
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
Shields of Kentucky #119
Shields of Kentucky #119
Conversation
The Kentucky parkway system has a standard shield that bears the entire official road name, but shields on a map should show the unsigned route ref, which is based on the official road name. Pull the way name into the image name and map it to a hard-coded ref.
"Cumberland Pkwy": "LN", | ||
"Hal Rogers Pkwy": "HR", | ||
"Mountain Pkwy": "MP", | ||
"Purchase Pkwy": "JC", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I extracted these initialisms from KYTC’s internal alphanumeric route numbers. Some of them are pretty recognizable, but some like “JC” are more obscure. (It’s from the namesake in the official name.) For the benefit of non-locals who don’t remember the older, more usable shields, I’d be open to changing it to something more intuitive, like “P”, but such ad-hoc abbreviations definitely shouldn’t go into OSM.
#121 implements Kentucky state highway shields, which would limit this PR to just the AA Highway and parkway shields. |
It seems like we have three options here.
A separate question is whether these are tagged correctly, as we do not want to do an end run around correct tagging if there's a problem in the map. Because this series of parkways has a common shield background, I think it's correct that they share a common network. I can't think of any case where road networks with a common shield series have different network values which we could use as an comparable case. In New Jersey, we tagged their parkways with different networks because each one had completely different shield designs. In New York, the consensus (possibly not yet implemented at this point) was that each of their parkway shield series (the green ones vs the white Long Island ones) should have separate network values. So I think the pattern of common shield design = common network value is correctly preserved in NJ, NY, and KY cases. I also agree that the long text names in the KY shields is not a ref, which is reserved for coding schemes. These are clearly names. Additionally, the KY internal 2-letter codes are not signed (with the exception of AA), so it is probably appropriate to tag those So this leaves us with the decision of what to draw on the map. I think drawing the shield blank with no text would be somewhat lacking, and drawing a real-world shield with unreadable text would just be graphic noise. The use of initials seems like a reasonable compromise that gets recognizable, differentiated shields on that map that map users are likely to understand. By that rationale, the Purchase Parkway code should be "PP" to be consistent with the "MP" initials of Mountain Parkway. I vote map user understandability over KYDOT coding schemes. I would like to hear additional opinions, but so far I have not heard a better way to handle it, nor a consensus to tag these roads differently. |
Fourth option: Don't render shields for these since they don't have ref values. Instead figure out how to render the names prominently at the zoom level where a shield would start displaying. Under this option, AA Parkway would be an exception since it is signed in a way where "AA" makese sense as a ref value, so it would get a shield. This is what Apple Maps does. |
The objection I have to this idea, is that these roads have shields in the real world, so I would expect to have shields in the map. |
Yes, the parkway signs are shields, however unwieldy. Over the years, they have evolved from (much more attractive) ad-hoc signs similar to the ones used in New Jersey, to a color-coded, lettered scheme similar to New York City’s, to the more uniform shields today. Here are some of their previous shields for comparison: Today’s signs continue to function as shields, appearing everywhere the MUTCD calls for shields to be used on a numbered highway: on guide signs, trailblazer assemblies, and reassurance markers, replete with cardinal direction auxiliary plates. The “alt text” I referred to above is standard KYTC practice on any named road, because many state highways are better known by their road names. In this context, the AA Highway’s shield is less of an exception than a holdover from one of the previous shield designs. It does need to be tagged separately, anyhow, because it isn’t part of the parkway system. |
Fair enough. I'm convinced these are indeed shields, so disgregard the fourth option I proposed. I still feel that the best path forward here is to have the initialisms in an OSM field rather than hard coded into this style, though. I get that they aren't technically refs so it would be better not to use that field. How about working on including short_name in the OpenMapTiles transportation layer? I doubt this will be the last case where that field is useful. |
The good news is that I think |
The |
I don't know about examples outside the US, but it's arguable that Conversely if it's not a problem for these parkways to have their initials in the |
Here are a couple of examples from Toronto that seem like a similar situation. The generic case seems to be routes where:
These factors make an initialism a reasonable choice. Although I've yet to see any examples like this outside of North America, it doesn't seem to me like these Kentucky parkways are entirely unique. Personally I have no issue bending the meaning of |
I think your synopsis of the issue is correct, although I think we need to keep digging for situations similar to the Kentucky parkway situation:
Basically, there are a lot of ways to make shields usable, some of which used to be used in Kentucky, but KYTC has doubled down on unreadable shields for some reason. The Palisades and HCTRA shields give a logo more prominence than the road name. For those routes, could ignore the name entirely, giving every route within the network the same exact shield with the logo in the middle. But for the Kentucky parkways, a blank box would look like a bug, especially since “BG” and “WK” would be the common-sense things to put in there, based on the old shields. Even though I’m quite certain that the Kentucky parkway shields are shields, I wouldn’t completely rule out replacing them with text labels, as the KYTC paper maps do, if we can find a way to do that reliably. Text labels would collide out a lot of nearby shields for intersecting routes, but I don’t think that’s a huge problem for most of these roads. |
To me there is no distinction between this situation and the Kentucky shields. I find it quite a stretch to say that it's definitely wrong to put an initialism in a |
Looks like the Oklahoma Turnpikes shields are similar to the Kentucky Parkways. They all use the same shield design, with only the name varying, and no ref. The difference is that most of them are concurrent with a numbered Interstate, US, or State route, but a few are not. |
There is also the MassPike: It's not currently mapped at all, and it's concurrent with I-90 in Massachusetts. |
The Oklahoma turnpikes are similar to the Palisades parkways and HCTRA in that the text is a minor part of the design, so the second point in #119 (comment) may not apply. For these networks, we have a choice as to whether to remove all text from the shield for simplicity (effectively matching what drivers perceive on the ground) or to emphasize the text more than the actual shield does (so that the user can more easily distinguish different routes in the same network). The Massachusetts Turnpike has a one-off shield. The second point in #119 (comment) definitely doesn’t apply in that case. |
Out of context, those terrible ideas look a lot more attractive than what the Kentucky parkways actually use. Wonder if they’re soliciting redesigns. 😏 To recap, here are the options proposed so far for Kentucky parkways:
Options 1, 4, and 5 are all solvable purely within this repository. Each of the options except 4 allows the user to discern the individual routes at a glance. |
Data consumers should be able to have confidence that whatever appears in
It’s a stretch to use A much better case for Footnotes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on copious Slack discussions, I believe the consensus is:
- We should not tag
ref
with fictional values to support shield rendering. Instead these should go in other tags appropriate for initialisms. - The approach here is probably performant enough that it scales to the likely number of special cases that we might encounter worldwide.
- The render samples look good and the author has local knowledge that suggests that the shields are likely to be locally understood.
A technical note - planetiler does not currently do road suffix abbreviations, so Pkwy
would get expanded to Parkway
if we transition to a planetiler-based tile source (and planetiler doesn't implement that functionality in the meantime). In that case, we would need to add the fully-spelled out versions to the special case list as well.
To add further to this - the solution in this PR is understood to be a temporary fix until other tagging can be added to the vector tile source (such as |
Ignore refsByWayName when there is a ref.
- **`textColor`** – The color of the inscribed text to superimpose on the background. | ||
- **`textLayoutConstraint`** – A strategy for constraining the text within the background image, useful for shields of certain shapes. | ||
|
||
Additionally, **`refsByWayName`** is an object mapping way names to text that can be superimposed on the background as a fallback for a missing `ref` value. (`refsByWayName` implies `notext`.) This temporary fallback is designed for use in [limited situations](https://wiki.openstreetmap.org/wiki/United_States/Unusual_highway_networks) that meet each of the following criteria: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a pass on instructions for crafting a shield definition object. As part of these instructions, I detailed the rationale for refsByWayName
with enough conditions that hopefully it won’t open the floodgates to any end-runs around OSM.
"Audobon Parkway": "AU", | ||
"Bluegrass Parkway": "BG", | ||
"Bluegrass Pkwy": "BG", | ||
"Cumberland Parkway": "LN", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The inclusion of these spelled-out versions is for forward-compatibility with any Planetiler-generated vector tiles. Once onthegomap/planetiler#14 is implemented, we can delete these extra entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's include this note as a comment here or open a new ticket so we don't lose track of it.
Co-authored-by: Brian Sperlongano <[email protected]>
Added shields for Kentucky state highways and parkways.
For now, the state highway shield is a circle for simplicity. As tail work, it should be replaced by an ellipse or the rounded rectangle that KYTC posts on signs: #117 (comment).
The parkways are more complex. Each of the parkways uses a uniform shield that bears the state tourism logo and the road’s entire official name. Unfortunately, most screens don’t come with enough pixel density to legibly display the namesake’s middle initial in a small shield. Each parkway has an official two-letter initialisms and four-digit route number that is used only in KYTC publications, so we can’t tag them as refs in OSM. Even so, I think users would recognize the initialisms on a map, because they’re derived from the road name’s initials (or the namesake’s first and last initials). Some of the routes, like the Western Kentucky Parkway (WK), used to bear these initialisms on their shields.
The Wendell H. Ford Western Kentucky Parkway’s shield is so poorly designed that KYTC has to stick alt text next to it.
In order to display shields for the parkways, I had to plumb the way name through to the shield definition and map way names to hard-coded display refs. In general, it’s a very bad idea to conflate route shields with road names, but I don’t think we really have a choice with Kentucky’s parkway system. To head off abuse of this mechanism, I’ve made it so that it can only map way names to refs, not background images. In theory, we could hard-code logic in OpenMapTiles to expose the Kentucky parkway route relations’
short_name
s in theroute_*
properties. However, it’s my understanding that OpenMapTiles would prefer to avoid such regionally targeted logic.As a special case, the AA Highway has a shield that resembles the parkway shield, but it does have a signposted ref of “AA” along with a unique
network
tag. Thenetwork=US:KY:AA
tag was introduced less than a month ago, so it hasn’t propagated to OpenMapTiles yet. For now, it’ll render as a lettered state highway shield, but here’s a jury-rigged preview: