WIP: [style/kothic] Suggestion for a big simplification of .mapcss style files #36

bmgru commented 2026年03月11日 19:09:59 +01:00

This is a suggestion + a working example for proof of concept, that you may find interesting ... or not .

There are currently a lot of redundancies in .mapcss files : the same patterns are repeated many times ... just because we must provide different values for lines width and dashes, depending on zoom

The idea is to define generic patterns like line|z11-[highway=path][_path_grade=difficult] {width: @WIDTHdifficult; } where a .csv file will define the appropriate value for @WIDTHdifficult depending on the zoom

Benefits:

• less redundancy
• much less lines in .mapcss files
• easier tuning of values
• it is easier to have a 'global view' by viewing the .csv with an Excel-like reader

Notes:

• the impact on Kothic code is very limited and well isolated
• it is very easy to check that using this mechanism generates exactly the same result ( see README )
• using this new mechanism can be done step by step

Example
Hereafter the example, inside Roads.mapcss, applied on highway-path-difficult and highway-path-expert for the outdoors style

/*---------- demo for Csvcss mechanism ----------------*/
/*
line|z11[highway=path][_path_grade=difficult],
line|z11[highway=path][_path_grade=expert],
{width: 1; dashes: 1,2; opacity: 0.7;}
line|z12[highway=path][_path_grade=difficult],
line|z12[highway=path][_path_grade=expert],
{width: 1.1; dashes: 1,2; opacity: 0.8;}
line|z13[highway=path][_path_grade=difficult],
{width: 1.3; dashes: 1.5,2.5;}
line|z14[highway=path][_path_grade=difficult],
{width: 1.6; dashes: 1.5,2.5;}
line|z15[highway=path][_path_grade=difficult],
{width: 2; dashes: 2.5,4;}
line|z16[highway=path][_path_grade=difficult],
{width: 2.6; dashes: 2.5,4;}
line|z17[highway=path][_path_grade=difficult],
{width: 3.3; dashes: 3.6,5;}
line|z18-[highway=path][_path_grade=difficult],
{width: 4; dashes: 3.6,5;}
line|z13[highway=path][_path_grade=expert],
{width: 1.3; dashes: 1.4,5;}
line|z14[highway=path][_path_grade=expert],
{width: 1.6; dashes: 1.4,5;}
line|z15[highway=path][_path_grade=expert],
{width: 2; dashes: 2.3,9;}
line|z16[highway=path][_path_grade=expert],
{width: 2.6; dashes: 2.3,9;}
line|z17[highway=path][_path_grade=expert],
{width: 3.3; dashes: 3.5,11;}
line|z18-[highway=path][_path_grade=expert],
{width: 4; dashes: 3.5,11;}
*/
line|z11-[highway=path][_path_grade=difficult]
{width: @WIDTHpathgrade; dashes: @DASHpathdifficult; }
line|z11-[highway=path][_path_grade=expert]
{width: @WIDTHpathgrade; dashes: @DASHpathexpert; }
line|z11-12[highway=path][_path_grade=difficult],
line|z11-12[highway=path][_path_grade=expert],
{opacity: @OPACpathgrade;}

Next improvement
We are currently obliged to redefine dashes values, each time the line width changes ...
I guess that defining dashes as percentages of line width, might greatly simplify this

Implementation Notes

• The style directory provided in this example, contains files to be copied to the appropriate location in data/styles

I have applied a similar mechanism for a personal clone of www.cyclosm.org ... and the result was there : 3000 lines of .css code deleted !

Signed-off-by: bmgru bmgru@noreply.codeberg.org

This is a suggestion + a working example for proof of concept, that you may find interesting ... or not . There are currently a lot of redundancies in .mapcss files : the same patterns are repeated many times ... just because we must provide different values for lines width and dashes, depending on zoom The idea is to define generic patterns like `line|z11-[highway=path][_path_grade=difficult] {width: @WIDTHdifficult; }` where a .csv file will define the appropriate value for `@WIDTHdifficult` depending on the zoom **Benefits:** - less redundancy - much less lines in .mapcss files - easier tuning of values - it is easier to have a 'global view' by viewing the .csv with an Excel-like reader **Notes:** - the impact on Kothic code is very limited and well isolated - it is very easy to check that using this mechanism generates exactly the same result ( see README ) - using this new mechanism can be done step by step **Example** Hereafter the example, inside `Roads.mapcss`, applied on `highway-path-difficult` and `highway-path-expert` for the `outdoors` style ``` /*---------- demo for Csvcss mechanism ----------------*/ /* line|z11[highway=path][_path_grade=difficult], line|z11[highway=path][_path_grade=expert], {width: 1; dashes: 1,2; opacity: 0.7;} line|z12[highway=path][_path_grade=difficult], line|z12[highway=path][_path_grade=expert], {width: 1.1; dashes: 1,2; opacity: 0.8;} line|z13[highway=path][_path_grade=difficult], {width: 1.3; dashes: 1.5,2.5;} line|z14[highway=path][_path_grade=difficult], {width: 1.6; dashes: 1.5,2.5;} line|z15[highway=path][_path_grade=difficult], {width: 2; dashes: 2.5,4;} line|z16[highway=path][_path_grade=difficult], {width: 2.6; dashes: 2.5,4;} line|z17[highway=path][_path_grade=difficult], {width: 3.3; dashes: 3.6,5;} line|z18-[highway=path][_path_grade=difficult], {width: 4; dashes: 3.6,5;} line|z13[highway=path][_path_grade=expert], {width: 1.3; dashes: 1.4,5;} line|z14[highway=path][_path_grade=expert], {width: 1.6; dashes: 1.4,5;} line|z15[highway=path][_path_grade=expert], {width: 2; dashes: 2.3,9;} line|z16[highway=path][_path_grade=expert], {width: 2.6; dashes: 2.3,9;} line|z17[highway=path][_path_grade=expert], {width: 3.3; dashes: 3.5,11;} line|z18-[highway=path][_path_grade=expert], {width: 4; dashes: 3.5,11;} */ line|z11-[highway=path][_path_grade=difficult] {width: @WIDTHpathgrade; dashes: @DASHpathdifficult; } line|z11-[highway=path][_path_grade=expert] {width: @WIDTHpathgrade; dashes: @DASHpathexpert; } line|z11-12[highway=path][_path_grade=difficult], line|z11-12[highway=path][_path_grade=expert], {opacity: @OPACpathgrade;} ``` **Next improvement** We are currently obliged to redefine dashes values, each time the line width changes ... I guess that defining dashes as percentages of line width, might greatly simplify this **Implementation Notes** - The `style` directory provided in this example, contains files to be copied to the appropriate location in data/styles I have applied a similar mechanism for a personal clone of www.cyclosm.org ... and the result was there : 3000 lines of .css code deleted ! Signed-off-by: bmgru <bmgru@noreply.codeberg.org>

pastk commented 2026年03月19日 18:25:12 +01:00

Thanks, the idea is interesting!

The current syntax is too verbose and repetitive/redundant indeed.
Still, I don't think that reducing the number of lines is a goal in itself.
I.e. when someone tunes widths of highway=path they don't really care that various primary/secondary/etc. roads take a lot of lines in the file as well.
But its important indeed to have a good clutter free overview of highway=path widths, which should be easily editable as well.

Moving widths to a csv makes a better overview indeed. And it makes comparing e.g. widths of various lines easier (but still one will have to manually move lines in the csv to make them adjacent).
But it comes at an expense of the necessity to reference another file (and find the necessary line there) to make adjustments or to just check the current state.

So it might be better to have all the info in the same file still but in a more concise and efficient format?
(e.g. one easy win would be removing repetitive feature type declarations [highway=path][_path_grade=expert])

Thanks, the idea is interesting! The current syntax is too verbose and repetitive/redundant indeed. Still, I don't think that reducing the number of lines is a goal in itself. I.e. when someone tunes widths of highway=path they don't really care that various primary/secondary/etc. roads take a lot of lines in the file as well. But its important indeed to have a good clutter free overview of highway=path widths, which should be easily editable as well. Moving widths to a csv makes a better overview indeed. And it makes comparing e.g. widths of various lines easier (but still one will have to manually move lines in the csv to make them adjacent). But it comes at an expense of the necessity to reference another file (and find the necessary line there) to make adjustments or to just check the current state. So it might be better to have all the info in the same file still but in a more concise and efficient format? (e.g. one easy win would be removing repetitive feature type declarations `[highway=path][_path_grade=expert]`)

pastk commented 2026年03月19日 18:33:13 +01:00

We are currently obliged to redefine dashes values, each time the line width changes ...
I guess that defining dashes as percentages of line width, might greatly simplify this

In my experience style developers usually want to have fine control over width, etc. values.

Otherwise I also had ideas of e.g. defining only start and end widths (like z11: 1.0; z20: 6.0) and have intermediate widths automatically interpolated. But people seem to like to fine-tune values for particular zooms..

Actually Mapbox stylesheets use this interpolation approach so it might be just a matter of becoming accustomed to.
(e.g. check some line-width declarations in https://github.com/mapbox/mapbox-gl-styles/blob/master/styles/basic-v9.json)

> We are currently obliged to redefine dashes values, each time the line width changes ... > I guess that defining dashes as percentages of line width, might greatly simplify this In my experience style developers usually want to have fine control over width, etc. values. Otherwise I also had ideas of e.g. defining only start and end widths (like z11: 1.0; z20: 6.0) and have intermediate widths automatically interpolated. But people seem to like to fine-tune values for particular zooms.. Actually Mapbox stylesheets use this interpolation approach so it might be just a matter of becoming accustomed to. (e.g. check some `line-width` declarations in https://github.com/mapbox/mapbox-gl-styles/blob/master/styles/basic-v9.json)

pastk commented 2026年03月19日 18:34:32 +01:00

@yannikbloscheck WDYT?

@yannikbloscheck WDYT?

yannikbloscheck commented 2026年03月19日 22:18:43 +01:00

Not a fan of this at all. I understand the reasons for it, but I think it complicates things a lot for very limited benefit.
We shouldn't split up things in even more different file formats. The MapCSS style is an established format and based on an existing basis of CSS, that many people know and used to work with. The existing custom deviations from the official MapCSS already have cost me (and other people) many hours when working with it. So the last thing is to put things in an annoying CSV file and complicate our whole workflow further. Having it one file and in CSS is the best.
Also as noted we actually want to fine tune all those things for the different zoom levels. All the small differences are usually on purpose.

Not a fan of this at all. I understand the reasons for it, but I think it complicates things a lot for very limited benefit. We shouldn't split up things in even more different file formats. The MapCSS style is an established format and based on an existing basis of CSS, that many people know and used to work with. The existing custom deviations from the official MapCSS already have cost me (and other people) many hours when working with it. So the last thing is to put things in an annoying CSV file and complicate our whole workflow further. Having it one file and in CSS is the best. Also as noted we actually want to fine tune all those things for the different zoom levels. All the small differences are usually on purpose.

pastk commented 2026年03月20日 08:35:18 +01:00

@yannikbloscheck wrote in #36 (comment):

The MapCSS style is an established format and based on an existing basis of CSS, that many people know and used to work with. The existing custom deviations from the official MapCSS already have cost me (and other people) many hours when working with it.

Its a bit off-topic here IMO, but I'd just add that our styles syntax is based on MapCSS indeed, but for many reasons it had been significantly different (and becoming even more different over time) and its not reasonable/realistic to try to revert the trend and make it up to "official specs".
The confusion comes from the fact that people still keep referring to it as "mapcss" though. We should just stop doing this and better treat it as our custom syntax - remove mapcss mentions from the docs and change style files extensions.

@yannikbloscheck wrote in https://codeberg.org/comaps/kothic/pulls/36#issuecomment-11829282: > The MapCSS style is an established format and based on an existing basis of CSS, that many people know and used to work with. The existing custom deviations from the official MapCSS already have cost me (and other people) many hours when working with it. Its a bit off-topic here IMO, but I'd just add that our styles syntax is **based** on MapCSS indeed, but for many reasons it had been significantly different (and becoming even more different over time) and its not reasonable/realistic to try to revert the trend and make it up to "official specs". The confusion comes from the fact that people still keep referring to it as "mapcss" though. We should just stop doing this and better treat it as our custom syntax - remove mapcss mentions from the docs and change style files extensions.