JavaScript animated shields

[yakra]

For cantch, CHM had animated gifs for Provinces where the route number changed, such as ON, QC or NS. ISTR (rustier here) usapa was similar for routes that has "PA Turnpike ##"-shielded segments.

TM does SVG instead of GIF. Maybe add some JavaScript to shieldgen.php to continually swap out some innerHTML, SVG to SVG to SVG...?

https://forum.travelmapping.net/index.php?topic=288.msg22010#msg22010

[jteresco]

I am confident the JS idea would do it. If and when this gets implemented, we'll also need a way to know which routes need which alternate shields. This seems it would mean additional info in the .csv files for each system.

[rickmastfan67]

Well, usafl could use this if ever implemented, due to some routes using the toll shield & regular shield (FL-528, FL-414 as a few examples).

But this would also mean the routes that are solely use the TOLL shield would need it as well. So, maybe we'd need a line for 'alt shields', as well as multiple shields? Could then make it easier to implement stuff like the recent addition of the ON-QEW shield and others in Ontario that have special shields that are unlike the normal shields.

[yakra]

@jteresco wrote:

I am confident the JS idea would do it. If and when this gets implemented, we'll also need a way to know which routes need which alternate shields. This seems it would mean additional info in the .csv files for each system.

ISTR you touched on this idea on the forum or in another GitHub issue. I'm not finding the discussion right away; got a link? I'd wanna review that before doing too much brainstorming.

@rickmastfan67 wrote:

But this would also mean the routes that are solely use the TOLL shield would need it as well. So, maybe we'd need a line for 'alt shields', as well as multiple shields? Could then make it easier to implement stuff like the recent addition of the ON-QEW shield and others in Ontario that have special shields that are unlike the normal shields.

I think the new .csv info Jim suggests could be one new field, with comma-separated values like we already do with AltRouteNames in a chopped routes CSV or roots in a connected routes CSV. Each comma-separated value would be a code for a shield template (e.g. canonf,canont,onqew). These could be defined in a new top-level file, shields.csv or shield_templates.csv or whatever. This should be able to take care of different shield types for different routes within a system, and multiple shields on a single route. No need to introduce the concept of "alt shields".

I expect that most systems would only use a single shield template all the way down the line, with only a small minority using 2 or more on a given route. Therefore I like the idea of putting the new column before the current final column, be it either

• before AltRouteNames in chopped CSVs (452 lines across 68 files) or
• before roots in connected CSVs (1338 lines across 104 files)

IDK whether this new field is a better fit for the chopped or connected routes CSVs.

A blank field could mean the default template that we see for canabs, canmb, canmbp, etc.

---

If we do make changes to the CSV format, it might be worthwhile to at the same time remove the system / systemName column, a vestigial CHM relic that's no longer useful.

---

A potential snag: The traveled & clinched shields pages would potentially have a lot of different elements with different innerHTML...

[jteresco]

A forum post reminded me of this issue. For anyone who might take it on before I decide it's a high enough priority for me to try it, I think function called periodically via setTimeout would be all it takes, once we knew which shield SVG files to rotate through for each route. Though as noted in the "potential snag" by @yakra above, for some pages we display a lot of shields. We probably don't want hundreds or thousands of setTimeout function calls being triggered continuously on such pages.

[michihdeu]

@denishanson interested? next summer or later?