Post Reply

Template for standard road lock schemes

Post by
I am about to update a bunch of state pages in my area to include the locking standards, and realized that it is pretty repetitive and could benefit from a template. There's one out there for the Northeast (non-New England), but otherwise, I don't see any out there, so I'm going to go ahead and create one. I could just create a one-off template for New England, but I figured, it might be beneficial to

1) Find out if we would like to standardize on a format, and should it be the Northeast template

2) Find out if we have any standardized locking assignments out there (from the last discussion I recall seeing, not every area has a standard, but most that do are statewide and consistent across road types except ramps)

3) Create a flexible template that can handle a few different options

4) Have one or a few fully standard sets, e.g., Fw,MH,mH,PS,S= 5,3,3,1,1 / 5,4,3,2,1 / 5,5,4,3,1 / 4,3,2,1,1

Any thoughts or should I just get to it and we'll see how it plays out later?

My starting points:

1) All of New England has a standard scheme of 4,3,2,1,1,+R:HC (ramp:highest connection) - I could just make a template for this alone
1a) Could be used as-is including section titling, or just the table, or table with optional/standard text blobs.
1b) Also consider railroad/ferry as required/optional parts of the template, since they're here.

2) All of the "Northeast" region has 5,4,3,2,1 except NYC which has 5,5,4,3,1 - if not for the odd exception in there, the template could be the same, just have to be ambitious enough to make the different lock numbers parameterized, then re-use for any state that standardizes locking by segment type. Or not - each unique combination could just be a template.

3) If I'm ambitious, I could have a single template that support one or two exception areas within the state. Then the exact template could be used almost anywhere that binds segment types to a lock level.

4) if there are schemes that don't involve segment type alone, do we need to account for that? Does anyone know of any?

5) Template naming - the Northeast one uses USA/Northeast/Locking standard. Depending on how it is used, we sometimes use regional template naming in the (main) namespace, and sometimes use the "Template:" namespace. I suspect that the best use in this case would be to use Template space for the main (lowest level) template, but allow regional templates that built on it to use the :USA/REGION naming.

Thoughts? Or just go for it?

Post by kentsmith9
My opinions:

1) I'm fine with that format overall.

2) I believe we came up with a Southwest standard. Details are in the Southwest forum on locking standard if you want to see the history.

3) Seems like it might be better to allow the master template to be programmable as it is called and then each state can create a template with the locks set to a particular rank to keep consistent in all uses and simplifies future updates to a single template update for that state.

Then on your template naming proposal, this template is an example that I would propose is based on the main namespace like {{:USA/Region/...}}. I am open to using the standard Template namespace if people are confused, but the template specific namespace was primarily being used for templates that control content formatting and similar instances, but not typically for content guidelines. If this is unclear I can give examples.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5686
Has thanked: 822 times
Been thanked: 1159 times

Post by kentsmith9
qwaletee wrote:I would like to propose that any template that is intended for use beyond a USA audience should go in Template space.
I don't think the location of use should be the deciding factor, but clearly a worldwide use should not be located in {{:USA/TEMPLATENAME}}.

I can see how this template could be argued as something fit for the template space, but not simply because it is used worldwide.
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5686
Has thanked: 822 times
Been thanked: 1159 times

Post by PesachZ
Hey great work, I love it, but still needs some polishing.

I tried to use this last night and found the doc pages very confusing, not clearly delineated, and not all parameters identified.

I also think we're need some more colspans in there if the locks are identical across different columns. The ramp lock especially if the default is used, makes the table very wide.

I think with some clever if statements the colspan can be automatic.

Ferry and RR are not ankle to be individually set by regional column, is this by design? Why?

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
Posts: 4513
Has thanked: 1381 times
Been thanked: 1617 times
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
The repeated nested of statements was exactly the cleverness I'm referring to. We could draw the code in a spread sheet to assist in filling all the variable, then copy it back into the template.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
Posts: 4513
Has thanked: 1381 times
Been thanked: 1617 times
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
qwaletee wrote:Hmm, I guess we have different definitions of clever.

Even getting the first one right will be fairly obtuse, and not a priority for me. If you would like to take a crack at it, go ahead and expand on what I did. Use a test page please (user, template, or other space). Good luck.
If I get bored or intrigued enough I'll make an attempt in {{Locking Standard/Sandbox}}

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
Posts: 4513
Has thanked: 1381 times
Been thanked: 1617 times
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
while taking a peek at this code I found what I think is a bug. If you have 3 regions, and use the default value for fwy on all of them the third region gets locked at 3 instead of 4.
current code:

Code: Select all

| {{{Fwy|4}}}{{#if:{{{title2|}}}|{{!}}{{!}}{{{Fwy2|{{{Fwy|4}}}}}}}}{{#if:{{{title3|}}}|{{!}}{{!}}{{{Fwy3|{{{Fwy|3}}}}}}}}
I believe the last "3" at the end of the string should be a 4.
PesachZ
Wiki Master
Wiki Master
Posts: 4513
Has thanked: 1381 times
Been thanked: 1617 times
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
qwaletee wrote:For documentation, I provided the rough information. It could definitely use some work. I'm not too worried about the core template (Locking Standard) because I think its doc is OK AND I think in most cases this template would not be used by end users. The Lock Standard State "shell" template would be used instead, because less-technical editors can simply hand off the hard work to someone who knows how to deal with templates. The Lock Standard State documentation needs a lot of work. All the parameters to the core template are fully and clearly documented, though they are pain to use if you have many deviations from the default lock levels. Using the State shell template is comparatively simple: If your area is already defined, just pass the area name as a parameter, e.g., {{Lock Standard State|NORTHEAST}}. If your area is not already defined, then someone who understands the core template has to develop the correct call to the core template, and stuff it in to the shell template with the area name. Ask your wife - stuffing shels takes effort, consuming them is easy and pleasant.

Colspans - complex topic, see below.

As to Ferry and RR, I thought we set a national standard on that. If not, it isn't that hard to swap the fixed values there now for a variable option, with the same three columns as the other types.

Back to colspan, in all its hoary:

This is tougher than you might think, Pesach. It doesn't require any cleverness, just a lot of extra code. Wiki template logic is quite awkward. You don't have any variables (other than the passed parameters), so you have to repeat your full logic statement every time you use it. In this case, you have to play two sets of logic - does the column exist at all, and if so, does it repeat (and how)

For example, this is the existing freeway line definition:

Code: Select all

| {{Freeway}}
| {{{Fwy|4}}}{{#if:{{{title2|}}}|{{!}}{{!}}{{{Fwy2|{{{Fwy|4}}}}}}}}{{#if:{{{title3|}}}|{{!}}{{!}}{{{Fwy3|{{{Fwy|3}}}}}}}}
Let's say to simplify it, we would reduce functionality to 2 columns before implementing automatic column spanning:

Code: Select all

| {{Freeway}}
| {{{Fwy|4}}}{{#if:{{{title2|}}}|{{!}}{{!}}{{{Fwy2|{{{Fwy|4}}}}}}}}
This is how it MIGHT work then (untested, probably not complete and buggy, and does not support 3 columns without lots more code):

Code: Select all

| {{Freeway}}
| {{#if:{{{title2|}}}|{{#ifeq:{{{Fwy|4}}}|{{{Fwy2|{{{Fwy|4}}}}}}|colspan=2}}{{{Fwy|4}}}{{#if:{{{title2|}}}|{{#ifeq:{{{Fwy|4}}}|{{{Fwy2|{{{Fwy|4}}}}}}||{{!}}{{!}}{{{Fwy2|{{{Fwy|4}}}}}}}}}}
That unreadable glob has to be tested, fixed, repeated across all 6 driveable road types, modified for the defaults of each type (which is repeated about five times each), and for the specific variables for each of those types (repeated about 10 times each). That's about 300% of the prior code to do so.

Now, if we wanted to add the third column back, we would have to be repeated that type of code extension, except that logic is even more tortured due to the fact that all three could be the same, or the first and third could be the same, or the second and third. I'd estimate about 25x the current code to complete that.

Right now, I'm not ambitious enough to fix that for the sake of an appearance improvement that is a nice-to-have, not a "need," and could be added in later without breaking anything.

You might be thinking, OK, so go for two columns with a better appearance first, third column later. I don't want to do that, because I think the common use case will be urban/suburban/rural, which requires three columns. In NY, you already have NYC and elsewhere for two columns, and i suspect at some point, we're going to be gracious enough to allow northern and western NY to have New England's even lower level locks, because of the paucity of senior editors and the immaturity of the map.

If we had Lua added to the Wiki, more normal programming could be done, and I could spin this out in a jiffy. Readable code, reuse of code for each row.
I believe I have successfully completed the code for the freeway row using this code:

Code: Select all

|{{#if:{{{title2|}}}|{{#if:{{{title3|}}}|{{#ifeq:{{{Fwy|4}}}|{{{Fwy2|4}}}|{{#ifeq:{{{Fwy2|4}}}|{{{Fwy3|4}}}|colspan=3{{!}}{{{Fwy|4}}}|colspan=2{{!}}{{{Fwy|4}}}{{!}}{{!}}{{{Fwy3|4}}}}}|{{#ifeq:{{{Fwy2|4}}}|{{{Fwy3|4}}}|{{{Fwy|4}}}{{!}}{{!}}colspan=2{{!}}{{{Fwy2|4}}}|{{{Fwy|4}}}{{!}}{{!}}{{{Fwy2|4}}}{{!}}{{!}}{{{Fwy3|4}}}}}}}|{{#ifeq:{{{Fwy|4}}}|{{{Fwy2|4}}}|colspan=2{{!}}{{{Fwy|4}}}|{{{Fwy|4}}}{{!}}{{!}}{{{Fwy2|4}}}}}}}|{{{Fwy|4}}}}}
It handles up to 3 columns, and spans any matches of 2 or more adjacent columns. I ran a series of tests on the doc page with the specific variations of each test listed in the table caption. Please have a look at the sandbox version of the template, and let me know what you think of it.
PesachZ
Wiki Master
Wiki Master
Posts: 4513
Has thanked: 1381 times
Been thanked: 1617 times
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by Fredo-p
I'm happy with that idea. If other states decide to move to having locking standards for PLRs and PVs then it would only make sense to have that option available.
Fredo-p
Posts: 2008
Has thanked: 242 times
Been thanked: 527 times

Arizona Wiki | @Waze_Arizona Twitter
Verizon Samsung Galaxy S8+

Post by orbitc
I'm OK with it. There is no harm in adding those fields.
orbitc
Waze Global Champs
Waze Global Champs
Posts: 6547
Has thanked: 932 times
Been thanked: 4903 times
Regional Coordinator for Northeast & New England
•Tier1 •USA Coordinator •Global Champ & Mentor
•iOS & WME ßeta Tester •Beacon, CCP & Wiki Master
•Master Raiders •Localization •Content Raider


USA | MapRaid!

Post by Kartografer
I know this is a necro-post, but I am proposing an expansion to this template here.
Kartografer
Wiki Master
Wiki Master
Posts: 1244
Has thanked: 462 times
Been thanked: 671 times
Galaxy S20 FE on Mint
Retired SM Ohio
Then you will know the truth, and the truth will set you free.
-John 8:32