Shields of Kentucky

[1ec5]

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_names in the route_* 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. The network=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:

[1ec5]

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.

[1ec5]

#121 implements Kentucky state highway shields, which would limit this PR to just the AA Highway and parkway shields.

[ZeLonewolf]

It seems like we have three options here.

1. Render all of these KY parkways with a common shield
2. Render parkways with unsigned internal KY initialisms
3. Render parkways with unsigned internal KY initialisms with an exception for the JC one so it's more sane to map readers

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 unsigned_ref=XX. We could promote those to ref, but that would be tagging for this renderer, which I don't think we want to make a precedent for.

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.

[zekefarwell]

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.

[ZeLonewolf]

Fourth option: Don't render shields for these since they don't have ref values.

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.

[zekefarwell]

these roads have shields in the real world

Well, I guess that gets into the philosophical question of what makes a sign a "shield" vs a sign with a name on it. I think we can all agree that this is just a sign with a name on it, not a shield:

To me, the Kentucky Parkway signs don't seem very different, though perhaps the design is a bit more unique:

Does that make them "shields"? Can't say I can answer that question, and rather than attempting to, it seems simpler to make the criteria for whether we display a shield on the map be that there is a signed shortcode we can sensibly call a ref. In the case of AA parkway, there is. In the case of the others, there isn't. Although, I guess roads like the Garden State Parkway and NY Thruway have unique sign designs that we use instead of refs, so maybe these Kentucky signs can be considered similar.

[1ec5]

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.

[zekefarwell]

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.

[1ec5]

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 short_name is already tagged on these route relations. For these parkways, it would make a lot of sense for OpenMapTiles’ route_* properties to fall back from {network}={ref} to {network}={short_name} if the route relation has a network but no ref. However, we should probably think about the applicability of this approach beyond Kentucky, since OpenMapTiles is pretty lean on regional special cases.

I think short_name could be justified for other cases where an initialism isn’t signposted but would still be useful for search indexing and plain-text rendering. For example, mappers routinely put initialisms in the refs of bicycle route relations, so that people can search for the route by that initialism and so that the routes get labeled by renderers such as OpenCycleMap. This makes it more difficult to tell when the ref should actually appear on a shield. Overloading ref in this manner will complicate any future work to render recreational route shields in Americana.

[ZeLonewolf]

The short_name coalesce that Minh suggested would be easy to implement in OMT, technically, but I think it would be hard to justify if Kentucky Parkways is the only case where it's needed. I would think we'd need multiple examples to rationalize extra processing globally.

[zekefarwell]

I don't know about examples outside the US, but it's arguable that short_name would be more appropriate for initialisms of parkways and toll roads like many in New York, New Jersey, and Texas. Most of these use the ref field currently. Like FBP and SHT (lol 💩) here:

Conversely if it's not a problem for these parkways to have their initials in the ref field, I think it would be fine to do the same for the Kentucky parkways.

[1ec5]

Texas is more complicated. Some of the toll operators use the short names as conventional refs too. For example, the seven or so named toll roads operated by the North Texas Tollway Authority use reassurance markers with spelled-out road names but initialisms as part of shields on guide signs and trailblazer assemblies . I think it’s appropriate for the NTTA route relations to be tagged with identical short_names and refs.

On the other hand, I would argue that the Houston-area toll roads only have initialisms of convenience, not actual reference codes. As with the Kentucky parkways, they should be tagged short_name, if not a one-off network value, whereas tagging ref would be optimizing for a particular renderer.

[zekefarwell]

Here are a couple of examples from Toronto that seem like a similar situation.
https://en.wikipedia.org/wiki/Don_Valley_Parkway
https://en.wikipedia.org/wiki/Gardiner_Expressway

The generic case seems to be routes where:

• Real world shields display a full name rather than a number, code, or abbreviation
• Real world shield design without the name is not unique or recognizable enough
• Name is too long to fit on a map sized shield

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 ref to include initialisms of convience (as many mappers have), but if you feel strongly that this is the wrong thing to do, I'll help promote short_name as the proper place for them. I think we'd be able to come up with enough of these cases that the short_name coalesce is justified in OMT.

[1ec5]

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:

• The New York City and Long Island parkway shields now rely on letters, so ref is correct.
• The New York State parkway shields bear the full name, but at least they do suggest initialisms using drop caps, so ref is OK.
• The New York Palisades parkway shields rely on inscrutable text for distinguishing one route from another. ✔️
• The Houston-area Harris County Toll Road Authority (HCTRA) shields rely on inscrutable text for distinguishing one route from another. ✔️
• The Toronto-area shields are identifiable by colors (similar to the Pittsburgh-area color belts).

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.

[zekefarwell]

The New York State parkway shields bear the full name, but at least they do suggest initialisms using drop caps, so ref is OK

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 ref tag under normal circumstances, but if the initialism is suggested by drop caps then it's perfectly OK 😁.

[zekefarwell]

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.

[ZeLonewolf]

There is also the MassPike:
https://en.wikipedia.org/wiki/Massachusetts_Turnpike#/media/File:Mass_Pike_shield.svg

It's not currently mapped at all, and it's concurrent with I-90 in Massachusetts.

[1ec5]

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.

[zekefarwell]

Here's an abstract rendition of the Kentucky parkway shield design that is a bit more visually interesting than a blank rectangle. This could be used if we were to choose option 1 (render all KY parkways with a common shield).

Kind of a joke, but maybe it actually would work? 😄 I don't know. I'd say it is a reasonable approximation of what drivers perceive from a distance.

[ZeLonewolf]

Some more terrible ideas:

[1ec5]

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:

1. Hard-code initialisms in the style as implemented in this PR.
2. Introduce logic to OpenMapTiles that coalesces ref with short_name when calculating route_* properties.
3. Retag the route relations with ref, holding our noses while tagging incorrectly for this renderer.
4. Design a common shield for the entire parkway system that doesn’t distinguish individual routes, taking some artistic liberty.
5. Add a special case to label motorways from z7 or z8 instead of z10 if the index of US:KY:Parkway within route_1 is 0.

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.

[ZeLonewolf]

So when I look at the green-style NY parkways:

...I agree that equating the larger font of the first letter of each word as the "ref" is something that we probably just did to make it show up on osm-carto. Extending this to doing the same on the KY parkways is barely different. If the next rev of the KY parkway signage switches to a style that emphasizes the first letter of the words -- does that really suddenly make it a ref?

If we're going to make manufactured refs in NY, I think we can make them in KY. Or vice versa, if we went with the short_name versions here, that should apply in the other places too.

Can anyone articulate what the negative consequence of ref initialisms in KY would be on data consumers that isn't already a problem on NY parkways that are doing the same thing?

[zekefarwell]

Here's a closer crop of the horses head, modified for better pixel alignment. I think I turned it into a dragon. 🤨
1x: 2x:

The original horse works better 🤦‍♂️. Still really too detailed for such a small image.
1x: 2x:

[1ec5]

Can anyone articulate what the negative consequence of ref initialisms in KY would be on data consumers that isn't already a problem on NY parkways that are doing the same thing?

Data consumers should be able to have confidence that whatever appears in ref is something that can be announced or displayed on its own if necessary. Overloading ref for initialisms of convenience can have an adverse effect on the guidance instructions generated by routers. For example, when a route turns onto this way tagged name=Lake Ontario State Parkway ref=LOSP, part of this relation tagged similarly, a router would reasonably say “Turn right onto Lake Ontario State Parkway, L O S P”.¹ In a more urban, higher-stress parkway context, that amusing redundancy can turn into confusion and missed turns. In fact, on motorways and expressways, a router is likely to skip the name in favor of the ref under the assumption that ref is just as meaningful but more concise: Project-OSRM/osrm-text-instructions#51.

If we're going to make manufactured refs in NY, I think we can make them in KY. Or vice versa, if we went with the short_name versions here, that should apply in the other places too.

It’s a stretch to use ref for the initialism of a standard green New York parkway shield like the Korean War Veterans Parkway, but at least “KWVP” obviously visually relates to the shield, which is why I haven’t argued against it so far.

A much better case for ref is the NTTA toll roads in #119 (comment), which happen to use the initialism as if it’s a route number. If a router skips “President George Bush Turnpike” in favor of “PGBT” even when there’s no time pressure, great.

Footnotes

1. This is what OSRM does in its voice instructions. OSRM only uses way refs, but the same challenge would remain if it were to incorporate relation refs into guidance instructions. ↩

[ZeLonewolf]

Based on copious Slack discussions, I believe the consensus is:

1. We should not tag ref with fictional values to support shield rendering. Instead these should go in other tags appropriate for initialisms.
2. The approach here is probably performant enough that it scales to the likely number of special cases that we might encounter worldwide.
3. 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.

[ZeLonewolf]

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 short_name, colour, or some other initialism/abbreviation tagging) which can be used to more properly construct these shields in a systematic way.

[1ec5]

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.

[1ec5]

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.

[ZeLonewolf]

Let's include this note as a comment here or open a new ticket so we don't lose track of it.