Template for standard road lock schemes

Moderator: Unholy

Re: Template for standard road lock schemes

Postby Fredo-p » Fri Jan 16, 2015 8:41 pm

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.
[ img ][ img ]
Arizona Wiki | @Waze_Arizona Twitter
Verizon Samsung Galaxy S8+

Fredo-p
State Manager
State Manager
 
Posts: 2007
Joined: Mon Aug 05, 2013 4:35 am
Location: Everywhere
Has thanked: 269 times
Been thanked: 643 times

Re: Template for standard road lock schemes

Postby Kartografer » Wed Dec 05, 2018 7:16 pm

I know this is a necro-post, but I am proposing an expansion to this template here.
[ img ]
Galaxy S9 running Pie on Mint
SM Ohio, AM New Mexico, South Dakota
Wazeopedia projects
Then you will know the truth, and the truth will set you free.
-John 8:32
Kartografer
Wiki Master
Wiki Master
 
Posts: 1181
Joined: Wed Dec 23, 2015 2:32 pm
Location: Westerville, Ohio, USA
Has thanked: 541 times
Been thanked: 773 times

Re: Template for standard road lock schemes

Postby kentsmith9 » Tue Dec 30, 2014 7:39 am

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.
USA: Now Idaho; previously California (Northern, SF/SJ)

[ img ][ img ][ img ][ img ][ img ][ img ]
PLEASE READ: Waze Map Editor (Start Here) | Editing Quick-start | Best Practices | Junctions
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 5685
Joined: Mon Apr 23, 2012 3:33 pm
Location: Boise ID and SF/SJ Bay Area of Northern California
Has thanked: 1577 times
Been thanked: 1794 times

Re: Template for standard road lock schemes

Postby kentsmith9 » Tue Dec 30, 2014 9:18 pm

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.
USA: Now Idaho; previously California (Northern, SF/SJ)

[ img ][ img ][ img ][ img ][ img ][ img ]
PLEASE READ: Waze Map Editor (Start Here) | Editing Quick-start | Best Practices | Junctions
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 5685
Joined: Mon Apr 23, 2012 3:33 pm
Location: Boise ID and SF/SJ Bay Area of Northern California
Has thanked: 1577 times
Been thanked: 1794 times

Re: Template for standard road lock schemes

Postby orbitc » Fri Jan 16, 2015 9:17 pm

I'm OK with it. There is no harm in adding those fields.
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
[ img ]

USA | MapRaid!
orbitc
Master Raider
Master Raider
 
Posts: 6521
Joined: Mon Jun 25, 2012 1:51 pm
Location: USA
Has thanked: 2655 times
Been thanked: 6614 times

Re: Template for standard road lock schemes

Postby PesachZ » Thu Jan 08, 2015 11:51 am

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: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: Template for standard road lock schemes

Postby PesachZ » Thu Jan 08, 2015 6:51 pm

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: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: Template for standard road lock schemes

Postby PesachZ » Thu Jan 08, 2015 7:49 pm

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: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: Template for standard road lock schemes

Postby PesachZ » Thu Jan 08, 2015 10:29 pm

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: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: Template for standard road lock schemes

Postby PesachZ » Fri Jan 09, 2015 12:21 am

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: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Next

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users