[OSM-dev] Release openstreetmap-carto v2.25.0
chris_hormann at gmx.de
Thu Dec 11 12:10:24 UTC 2014
On Wednesday 10 December 2014, Matthijs Melissen wrote:
> Today, v2.25.0 of the openstreetmap-carto stylesheet has been
> released [...]
First of all these remarks don't have much to do with the changes of
this release in particular, it is mostly that this has confirmed a
number of observations i have made in the last months.
It seems to me that with the more active development of the style in the
past year or so with frequent changes with high visual impact the mode
of development of the style as it is currently practiced has reached a
limit where it becomes very difficult to develop well composed changes
to the style at all.
I am somewhat reluctant to bring up this problem since i think the more
active development is a good thing in total and i don't want to
I have not done a precise statistical analysis but the time for a change
from being designed to actually being deployed is fairly long, usually
there are at least 1-2 releases in between, often several months. This
does not only mean changes need to be adapted to a changed codebase, it
also means that the basis in terms of visual design is often changing
significantly while a change is waiting to be merged.
As a result most changes which are deployed in recent releases are not
really very well aimed. They are meant to address certain issues but
usually introduce at least as many new issues. Other changes are then
made later to address some of these with a similar result. To some
extent this is inevitable due to the complex interactions within the
style but it is also largely a result of 'shooting at a moving target'.
I don't have a real solution for this problem but there are a number of
things that IMO could much improve the situation:
(1) Systematic followups on the success and side effects of changes.
The only case where i remember this happening is with the landcover
labeling  but note that the majority of the issues pointed out there
are not yet addressed now, two month later. IMO development ressources
should in most cases focus on bringing a change to a satisfying overall
conclusion before working on new changes. For most of the recent high
impact changes this is not the case.
(2) Stricter queuing of changes for deployment. The manner in which
pull requests deemed ready for merging are selected for deployment
seems quite random at least to the casual observer. Some are merged
within days, others take several months (the oldest one currently seems
to be from July ) Followups on previous changes should probably be
(3) A test environment with worldwide data. I know this is not a new
suggestion and mostly a problem of ressources. What would already
help, especially for systematic followups on changes and would probably
require much less ressources is a frozen tile cache that allows better
before-after comparisons for changes already deployed.
More information about the dev