Modify

Opened 7 years ago

Closed 7 years ago

#7624 closed enhancement (fixed)

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

Reported by: cmuelle8 Owned by: cmuelle8
Priority: normal Milestone:
Component: Core Version: latest
Keywords: mappaint mapcss casing Cc:

Description (last modified by 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

Attachments (2)

cycleways-mapcss-relative-offset.png (35.9 KB) - added by cmuelle8 7 years ago.
cycleways-mapcss-relative-offset.png
mapcss-allow-left-right-encasing.patch (13.6 KB) - added by cmuelle8 7 years ago.
mapcss-allow-left-right-encasing.patch

Download all attachments as: .zip

Change History (14)

comment:1 Changed 7 years ago by cmuelle8

Description: modified (diff)

comment:2 Changed 7 years ago by bastiK

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

comment:3 in reply to:  2 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by bastiK

Ok, then.

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

comment:5 in reply to:  4 Changed 7 years ago by 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..

comment:6 in reply to:  4 Changed 7 years ago by 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

cycleways-mapcss-relative-offset.png

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..

Last edited 7 years ago by cmuelle8 (previous) (diff)

Changed 7 years ago by cmuelle8

cycleways-mapcss-relative-offset.png

comment:7 in reply to:  4 Changed 7 years ago by 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?

comment:8 Changed 7 years ago by bastiK

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

comment:9 Changed 7 years ago by 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" ? */
}

comment:10 in reply to:  9 Changed 7 years ago by 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

..

Last edited 7 years ago by cmuelle8 (previous) (diff)

Changed 7 years ago by cmuelle8

mapcss-allow-left-right-encasing.patch

comment:11 Changed 7 years ago by 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

Last edited 7 years ago by cmuelle8 (previous) (diff)

comment:12 Changed 7 years ago by bastiK

Resolution: fixed
Status: newclosed

In 5206/josm:

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain cmuelle8.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.