magnacarto
magnacarto copied to clipboard
omniscale
openstreetmap-carto
Please note that openstreetmap-carto relies on a few advanced Mapnik features that are not supported by Mapserver. Future versions of Magnacarto might work around these limitations.
What are these features? If there's reasonable ways to work without them, we could consider changing the style.
Are there any features that don't work with Mapnik?
From the top of my head?
group-bylayer property- Variable substitutions in file names, e.g.
primary_[width]x[height].svg
The group-by could be moved into he SQL query and the complete filename could be constructed inside the SQL as well.
Mapnik 3 in general allows variable substitutions everywhere. This is not supported by Magnacarto nor Mapserver.
Are there any features that don't work with Mapnik?
Mapserver has support for move advanced (and datadriven) symbols. But they are currently not supported by Magnacarto anyway.
- Variable substitutions in file names, e.g.
primary_[width]x[height].svgthe complete filename could be constructed inside the SQL
I've been thinking about this. If we get pictorial shields then it makes sense to do the filename substitution in SQL to avoid large numbers of style rules.
Of course, by then we might be using a groupsymbolizer for shields.
group-bylayer propertyThe group-by could be moved into he SQL query
@math1985 knows the complex roads queries better than I do, but is this possible? Of course, every time I try to use group-by I have to relearn it. It's not something I use often enough.
Sorry for the late response, I only got to this now.
No, it's not possible to move group-by to the SQL query, neither in general nor in the particular roads example from openstreetmap-carto.
Mapnik sorts by 1. layer, 2. group-by, 3. attachment, and 4. order from the SQL result set. Moving the group-by to the SQL would result in sorting by 1. layer, 2. attachment, 3. group-by 4. rest of the order from the SQL result set.
In the concrete road example, we currently render first casing and fill for bridges on layer 1, then casing and fill for bridges on layer 2, then layer 3, etc. Moving the order-by to the SQL would result in first rendering the casing for all layers, followed by the fill for all layers, which is obviously wrong.
Mapnik 3 in general allows variable substitutions everywhere
In particular, as part of zoom filters:
[feature = 'amenity_atm'][zoom >= @useful] { ... }
Should I open a new issue for this?
Mapnik 3 in general allows variable substitutions everywhere
In this context variables are values from an SQL query, etc.
In particular, as part of zoom filters: [feature = 'amenity_atm'][zoom >= @useful] { ... } Should I open a new issue for this?
And this is an actual variable from CartoCSS. So yes, please create a new issue.
Since CartoCSS is no longer developed after 1.0.0 release, it would be good to test if OSM Carto could make the switch to Magnacarto. What are possible obstacles? Could anybody test how it works with the current OSM Carto code (sounds non-trivial to me)?
Given the major features missing (e.g. group-by) and lack of other deployments I wouldn't recommend using magnocarto over cartocss unless you had other compelling reasons like wanting to deploy to mapserver, particularly for a complex style like osm-carto.
group-by is working, but there will be likely a few other obstacles. Right now, I wouldn't recommend it either as I don't have time to help out.