Add casing-width-add support #5
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: organicmaps/kothic#5
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "pastk-noeval"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
To be able to use e.g.
instead of
To solve issue with eval()'s use https://github.com/organicmaps/organicmaps/issues/4258
and to simplify mapcss files' syntax too.
Made
casing-width
to have precedence overcasing-width-add
as its more logical. Has no effect on current styles.@vng
lets keep 4 spaces tab
@ -362,3 +374,4 @@
dr_line.width = round((base_width + st.get('casing-width') * 2) * WIDTH_SCALE, 2)
dr_line.color = mwm_encode_color(colors, st, "casing")
if '-x-me-casing-line-priority' in st:
dr_line.priority = int(st.get('-x-me-casing-line-priority'))
Hm, looks strange here. Why does width depend from ::dash or ::default ?
@ -362,3 +374,4 @@
dr_line.width = round((base_width + st.get('casing-width') * 2) * WIDTH_SCALE, 2)
dr_line.color = mwm_encode_color(colors, st, "casing")
if '-x-me-casing-line-priority' in st:
dr_line.priority = int(st.get('-x-me-casing-line-priority'))
Because railways have inner ::dash line and outer ::default line. And railway bridge evals were taking it from the first one. If there are several style object with the same param (e.g. width) then the eval() code was taking the last one - probably in order they were declared in the file (::dash lines are declared later).
I think it'll be better to hardcode it to take width from ::default always but that would mean rewriting all railway bridges casing-width-add params which were inherited from evals. And it could possibly break some other declarations that were relying on this order. So I preferred not to touch it for now.
fixed!
@ -362,3 +374,4 @@
dr_line.width = round((base_width + st.get('casing-width') * 2) * WIDTH_SCALE, 2)
dr_line.color = mwm_encode_color(colors, st, "casing")
if '-x-me-casing-line-priority' in st:
dr_line.priority = int(st.get('-x-me-casing-line-priority'))
Hm, the logic looks very unclear here. What about taking max width (for all ::XXX tags) when referencing?
@ -362,3 +374,4 @@
dr_line.width = round((base_width + st.get('casing-width') * 2) * WIDTH_SCALE, 2)
dr_line.color = mwm_encode_color(colors, st, "casing")
if '-x-me-casing-line-priority' in st:
dr_line.priority = int(st.get('-x-me-casing-line-priority'))
Yeap its possible, an ultimate question is how we define the base/core width - is it the first/default defined line? Or the inner-most (narrowest) line? Or the outer-most (widest) one?
@ -362,3 +374,4 @@
dr_line.width = round((base_width + st.get('casing-width') * 2) * WIDTH_SCALE, 2)
dr_line.color = mwm_encode_color(colors, st, "casing")
if '-x-me-casing-line-priority' in st:
dr_line.priority = int(st.get('-x-me-casing-line-priority'))
ATM railways' bridge rules are based on
::dash
lines which are narrower, so we'll have to re-do them if we change to the widest line. Hence I left it as is.Change: look up for base_width in other style objects if its missing for use in simple
casing-width
calculation.PTAL!