[patch] Allow MapCSS to style right and left side casings differently

[cmuelle8]

Note, it does not break compatibility to casing-* properties of a MapCSS style. Basically, the casing code path is reused by making the prefix more generic - prefix is now used as a parameter to createImpl directly.

This aids in the creation of styles that visualize *right* or *left* oriented tags on ways.

Example usage is Styles/Cycleways

[bastiK]

You can use the 'offset' property to achieve the same, see e.g. Styles/ParkingLanes.

[cmuelle8]

Replying to bastiK:

You can use the 'offset' property to achieve the same, see e.g. Styles/ParkingLanes.

True, but

eval(0 - 4 - (prop("width") * 0.5) - (prop("width", "default") * 0.5));

is not very user-friendly for inexperienced style writers. You also have to know how to introduce different layers when writing a style. Right/left oriented tags are omnipresent in OSM, visualizing these should be easier than hacking at MapCSS using its full flexibility.

Having a property that precalculates the offset to be on the right or left edge of the corresponding line feature takes the burden of calculating these very common offsets themselves _each_ time used. Also, the style sheet gains "readability".

I agree, it can be done - Styles/ParkingLanes being a good example, but having both variants

• one for the more experienced or more demanding users, especially when things grow yet more complex than left/right features
• another for easier coding of style sheets if the flexibility of multiple mapcss layers is not needed

does not hurt.

A style writer also benefits when using relative values to "offset:". Stuffing all of this in an eval instruction leads focus to writing good eval expressions and takes it away from writing styles.

Simply put, precalculated offsets are one less thing to worry about. If you need more flexibility, your solution stands.

[bastiK]

Ok, then.

I tried left-casing-offset, but it does not shift the left casing relative to its original posistion.

[cmuelle8]

Replying to bastiK:

Ok, then.

I tried left-casing-offset, but it does not shift the left casing relative to its original posistion.

Can you post a mapcss snippet for me to test on my machine? Styles/Cycleways uses left-casing-offset and it works as it should on my machine, but maybe I do something differently, need more info..

[cmuelle8]

Replying to bastiK:

As for the logic I coded: a relative offset of "+4" moves the casing in question away from the center line, i.e.

• four pixels more to the left on any left-casing and
• four more to the right on any right-casing

E.g. ..

way[cycleway=track]
{
	left-casing-color: eval(prop("cycleway-weakinfo-color"));
	left-casing-width: eval(prop("cycleway-weakinfo-width"));
	left-casing-dashes: list(16,3);
	left-casing-offset: +4;
	right-casing-color: eval(prop("cycleway-weakinfo-color"));
	right-casing-width: eval(prop("cycleway-weakinfo-width"));
	right-casing-dashes: list(16,3);
	right-casing-offset: +4;
}

..renders like this

Negative values are ignored, this is because

• a RelativeFloat literal is only recognized if a plus sign is preceding the number
• getWidth() is reused, which discards negative absolute values

I think this is desireable - or would you like to see negative offsets work? After all, it does not seem to make much sense to shift a feature to the left, that was tagged "right" - if done, then probably by error.

So actually, it seems to be a good thing that this is prevented by current code..

[cmuelle8]

cycleways-mapcss-relative-offset.png

[cmuelle8]

Replying to bastiK:

Ok, then.

I tried left-casing-offset, but it does not shift the left casing relative to its original posistion.

Did you have the chance to have a 2nd look at this?

[bastiK]

Sorry for the delay, I'll review it soon.

[bastiK]

Hi, here are some oddities, I noticed:

way {
    left-casing-color:blue;
    right-casing-color:green;
}
way[maxspeed=30] {
    width:20;
    offset:5;
    left-casing-width: 7;
    right-casing-width: 7; /* asymmetrical */
}
way[maxspeed=40] {
    width:20;
    left-casing-width: +2;  /* results in value of 22, probably not intended */
}
way[maxspeed=50] {
    width:20;
    left-casing-width: 12;
    left-casing-offset: 10;  /* should be the same as "+10" ? */
}

[cmuelle8]

Replying to bastiK:

Hi, here are some oddities, I noticed:

way {
    left-casing-color:blue;
    right-casing-color:green;
}
way[maxspeed=30] {
    width:20;
    offset:5;
    left-casing-width: 7;
    right-casing-width: 7; /* asymmetrical */
}

Acknowledged - I need to take the offset of base line into account when pre-calculating left/right-casing-offsets.

way[maxspeed=40] {
    width:20;
    left-casing-width: +2;  /* results in value of 22, probably not intended */
}

Currently this is intended - all casing-widths inherit base width (if needed), be it left-, right- or normal casing. But I do not insist on this behavior - we could give it another sensible default - width/2 && >=1 - or similar. Your idea?

way[maxspeed=50] {
    width:20;
    left-casing-width: 12;
    left-casing-offset: 10;  /* should be the same as "+10" ? */
}

In latest version of the patch I add the base line offset after any other offset calculation is done. So

• "10" is essentially base_offset += 10 and
• "+10" will be (wrt example) base_offset += (base_width/2 + left_casing_width/2) + 10 i.e. base_offset += (pre-calculated offset) + 10

..

[cmuelle8]

mapcss-allow-left-right-encasing.patch

[cmuelle8]

The offset bug should be fixed - I have not changed the default left/right-casing-width yet, that is referenced when just a relative float is given in the MapCSS source. If you think half the width of the base line is a better default, I'd ask you to code this yourself, while you're at it. Thanks for testing,

Christian

[bastiK]

In 5206/josm:

applied #7624 - Allow MapCSS to style right and left side casings differently (patch by cmuelle8)