-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Rewrite roads layers #2869
Conversation
This sets the framework in place
transportation.mss
Outdated
} | ||
} | ||
} | ||
[highway = 'pedestrian'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing newline above this line
project.mml
Outdated
AND points.highway IN ('turning_circle', 'turning_loop') | ||
AND lines.highway IN ('tertiary', 'unclassified', 'residential', 'living_street', 'service', 'track') | ||
ORDER BY points.osm_id, -- for DISTINCT ON | ||
CASE lines.highway -- Use the most important type for cases where the TC is at an intersection. TODO: Should lines.layer be in here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to simply use z_order instead of this multiline-CASE?
project.mml
Outdated
COALESCE(bridge IN ('yes', 'boardwalk', 'cantilever', 'covered', 'low_water_crossing', 'movable', 'trestle', 'viaduct'), FALSE) AS bridge, | ||
COALESCE(layer,0) AS layernotnull, | ||
z_order, | ||
surface IN ('paved', 'asphalt', 'cobblestone', 'cobblestone:flattened', 'sett', 'concrete', 'concrete:lanes', 'concrete:plates', 'paving_stones', 'metal', 'wood') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn’t this query always return TRUE for everything that is not in the “unpaved” list anyway, making the query for th e“paved” list obsolete?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but there is a bug with values not in either list.
Currently, first comes the code for more important features with high z_order (e.g. highway=motorway) and later the code for less important features with low z_order (e.g. highway=track). Might it be an option to use the opposite order? This would not make any functional change. For the code proposed in #2640 (unpaved roads with dst-out pattern), the opposite order would make it a lot easier. In fact, the diff of #2640 is difficult to read because it needs the opposite order because it uses attachments. The code changes themself are not so heavy. And maybe this is also useful independent from #2640. Indeed the old road code has high z_order features first. But the attachment concept in MSS works the other way around: First attachment drawn first, last attachment drawn last (above the other ones). As we use attachments anyway in our roads MSS code, it could be more intuitive to have the rest following the same logic… |
I find it easier to read from most important to least important.
I'd rather keep it as-is for now, then we can look at changing it if necessary.
Generally we order in descending significance for MSS. It's interesting to note that within the SQL, the order by statements are both ascending and descending, depending on if its drawing lines and fills, or placing labels. |
Good point. |
Will the road layer rewrite resolve at the same time #2595 (construction roads should not be wider than their finished counterparts)? |
I'm not intending to make cartographic changes, but that one will depend on how the construction MSS is structured. |
@pnorman What is the current state of this code? Do you still plan to update it to be mergable (maybe just some part of it, if the task is too big)? |
I've been lacking time and interest.
I don't really see a way to split it down in scope. The best way to help this out would be for someone to pair up with me and we could work on it together. This would also be a good chance for someone to learn more about complex CartoCSS. The new roads code is simpler, but roads are still one of our biggest areas. |
Thanks for the information. Is there anybody wanting to help Paul with this code? |
I'm closing this as currently nobody is interested in working on this. If anybody is interested, feel free to create a new proposal. @pnorman Thanks a lot for the work you put in so far! Hopefully somebody else can pick up. |
Fixes #2046
Fixes #2468
This is a complete rewrite of the transportation code. The primary goals are
planet_osm_line
once for roads and once for railwaysOnce I'm farther along I'll set up a demo, but there are still features not yet implemented.
The layer changes are to move barrier-like features, landuse overlays, and
ferry-routes
before roads, and to moveaerialways
andwaterway-bridges
after roads.Cartographic changes
Remaining work
Long-term I'd like to redo names, but intend to keep that out of this PR
Known issues
I'm not sure what has caused this, but unknown surface footways are lighter.
For testing, areas likely to have problems will involve