Roadmap / strategic discussion

[matthijsmelissen]

With the road update rolled out, a large part of the style sheet has now been modified since the stylesheet development has been taken up by the current tram. Roads, buildings, landuse colours, and icons have all been changed to a greater or lesser extent.

I think that makes it time again to have a look at the bigger picture.

What should development concentrate on over the next year or so? What are the issues that need improving most at this point?

This discussion should lead to an update of the roadmap in README.md.

CC @gravitystorm @pnorman @matkoniecz.

[matthijsmelissen]

Some more questinons:

• Which zoom levels need attention most?
• Are there any particular issues in the issue tracker that are of importance?
• Are there particular types of features that need attention?

To start off the discussion, some potential points of attention (some of which might overlap):

• Reduce number of points of interest (POI)
• Adding more POI
• Adding more landuse
• Improving landuse colours
• Improve layering/rendering order
• Improve rendering of admin borders
• hstore support
• Improve performance (compilation and rendering)

[pnorman]

I'm going to split my comments up, since they'll be on a few different issues and I don't want to lose partial posts (again).

Compilation performance

1947 and #1944 helped here, but we're still about 10 seconds. We used to be under 2.5 and were still one of the slower stylesheets to compile.

I recently compiled osm-carto, Stamen Toner, CartoDB basemaps, Humanitarian, OSM Bright, and the unnamed Wikimedia OSM Bright 2 derived style. Nothing was close to us in compilation time, even with the Humanitarian bug that prevented compilation on carto 0.15.0 (hotosm/HDM-CartoCSS#277).

This graph is a based on a blog post but updated to include current changes and expanded where we were a long time between releases, using git checkout $(git rev-list --merges --first-parent -n 1 --before="$TARGET_DATE" master).

This increases the delay between saving a style change and seeing its effects, and at high zooms working with an extract the style recompilation is the biggest part of the delay. One of the big advantages to switching to a Tilemill/Kosmtik workflow is you could make changes and see them right away. We've lost that, and at 15-20 seconds we were actually slower than saving a change to Mapnik XML, restarting renderd, and hitting reload in the browser.

[pnorman]

Rendering performance

No one has done any rendering performance profiling in over a year. I don't know if we're IO bound, PostgreSQL CPU bound, or Mapnik CPU bound. I don't know which layers have slow SQL statements, and there are even tools for analyzing this.

I have no idea if we're slower than two years ago, given the same OSM data, and the same extends to a per-layer level.

[imagico]

From a design perspective i think the following broader issues are the most important:

• The availability of additional keys. Many people probably see this primarily as a possibility to render additional stuff - both in the good and the bad sense. But it will also offer possibilities to make better decisions, after all keys currently not available are largely secondary keys that detail properties of features.
• The matter of pre-processing data. The most recent example where this came up are the boundaries. The problem here is this is largely outside the scope of this style but the fact that you can essentially only do things with the data that can be done on the fly during rendering is one of the most serious design limitations.
• Improvement of results at low and high latitudes. This is difficult since it requires largely departing from fixed zoom level based styling decisions.

More specific issues of importance are IMO:

• Label placement and prioritization
• POI prioritization to reduce arbitrariness in appearance of icons
• Re-evaluation of the boundary colors - the semitransparent purple causes a lot of problems and getting rid of it would offer important room for other improvements, in particular on the footway/cycleway/path matter and roads (motorways).

[matthijsmelissen]

The matter of pre-processing data.

We need to consider this very carefully. I like the idea that the database is rendering-agnostic: you could in principle use one rendering database for different stylesheets. How well this works in practice, and if anybody uses this in production, I'm not sure about.

Re-evaluation of the boundary colors

+1

[gravitystorm]

I'm happy to see the routine improvements to colours, icons etc continue - they are the main thing we need to do. I still think there's a few big areas of work there, around changing some more colours to fit in the points/lines/polygons hierarchy (for example, sports centre polygons are more saturated than most POIs, and almost all lines). My main zoom levels of concern are 8-12. They are high enough to contain significant numbers of distinct features (unlike e.g. z4) and low enough that they are often indistinct in what they are showing (and use tiny text too). They are also low enough that, for me at least, they are a complete pain to design since re-rendering them takes forever on my laptop. My approach to these zooms is often to look at them and think "is this the best map possible of this area? If not, what would it look like if it was better?"

In saying this, my personal goals for the next 12 months are around technology, not really cartography:

• Complete the upgrade to mapnik 3
• Sort out the migration to hstore
• Move to vector tiles

We've started with the first two of these, but they need to be completed. The third is more open for discussion and has impacts beyond the stylesheet, but I believe it's the right thing to aim for.

[mboeringa]

We need to consider this very carefully. I like the idea that the database is rendering-agnostic: you could in principle use one rendering database for different stylesheets. How well this works in practice, and if anybody uses this in production, I'm not sure about.

This is the basis of my work on the ArcGIS Renderer during the past two years: the ability to arbitrarily swap styles, only adding new keys to an existing database when needed to fulfill specific render rules requiring certain keys not yet available.

Swapping entire styles and viewing the latest results isn't a one-second operation though, as it requires to reload layer files and, as said, potentially to extract keys from ESRI's implementation of an "hstore-like" key-value storage, which can be a rather lengthy operation (minutes to potentially hours or days depending on the size of the OSM extract and the number of keys to add).

It is not "dynamic" like hstore is: you can't run a SQL statement against the key-value storage in ESRI's implementation, you need to extract the key and add a new field to the table containing the "hstore-like" column (1). I have fully automated this key extraction process though, by writing a routine that evaluates SQL statements of render rules, and automatically adds the required keys. This works like a charm, albeit limited to basic "WHERE" clause style statements like "X IN ('1','2'), as this is a limitation of standard ArcGIS layer file's Definition Queries (there are Query Layers in ArcGIS that don't have this limitation and can contain arbitrary SQL, but I don't use them, and they have other limitations, like not being editable in ArcGIS).

That said, simply changing basic symbology, labelling, or a SQL Definition Query of an ArcGIS layer file of already "rendered" data, can be done instantaneously in ArcGIS if it doesn't require new keys (and with rendering in my concept I don't mean creating raster tiles but creating ArcGIS vector layers and the underlying needed database structure to support them, from this basis, you can export to a number of useful formats, e.g. Adobe PDF or TIFF, or setup a webservice).

(1) * EDIT * : Although this may be considered, or is, a limitation compared to hstore, there is also a positive side: SQL statements can remain much more "standard", due to operating against ordinary database fields, and thus cross-database compatible. Since ArcGIS supports multiple databases, this is desirable feature.

[pnorman]

HStore

There's nothing published about moving a style to hstore and making schema choices based on data. We know the german .style file reduces performance, and that using hstore should increase performance in the right conditions.

Because I feel the main pressure for hstore is just to increase the number of features we render, I have not had it at the top of my priority list.

[pnorman]

The matter of pre-processing data.

We need to consider this very carefully. I like the idea that the database is rendering-agnostic: you could in principle use one rendering database for different stylesheets. How well this works in practice, and if anybody uses this in production, I'm not sure about.

Andy does, see comments about ele text vs some numeric type. I believe Geofabrik also does.

However, using a non-render specific database and pre-processed data are orthogonal issues. Right now we use a non-specific database, but use preprocessed data in the form of shapefiles for coastlines and Antarctica ice.

pre-processed data has two problems

1. It normally involves a slower update cycle, breaking immediate feedback
2. It makes it harder for people to use the style themselves, as it's another thing to keep updated, or another set of tools to run.

Right now most of my time is going into a database schema which is very much not osm2pgsql with C tag transforms

[kocio-pl]

Because I feel the main pressure for hstore is just to increase the number of features we render, I have not had it at the top of my priority list.

It's much more than this to me: it also means better granularity, which helps making rendering more sane, as not all objects are equal regarding to rendering.

Two examples: we could show domestic and private airports later than international, once we have the scheme for it (https://github.com/gravitystorm/openstreetmap-carto/issues/1143; using way_area for it would be just intermediate solution) and make the memorial plaques less obtrusive than currently by pushing them later and rendering with smaller and more accurate icon (https://github.com/gravitystorm/openstreetmap-carto/pull/1605#issuecomment-110222481; in my city there are so many of them, that I'm reluctant to map them until I'm sure they won't eclipse too many things).

[matthijsmelissen]

My main zoom levels of concern are 8-12.

Agree.

[pnorman]

Roads

I can see some tweaks coming to road styles, but I'd like like to see improvements to the technical side.

We have 3k lines MSS and 7 layers: tunnels, casing, fill, bridges, ref, roads name, path name + low zoom stuff. Four of these layers are giant 120 line 5.5kb queries, so there's a lot of complexity there too.

Mapbox Streets has 700 lines and 4 layers, the new WM style has two layers and 150 lines. I think the WM style gets layering, bridges, and tunnels horribly wrong, but I haven't seen problems with MB Streets.

Are we handling complicated cases they are ignoring? Are we doing something wrong? Are their vector tiles limiting what kind of street styling people do?

Maybe there's some cascading that we could do to cut back on the MSS.

The WM style has an interesting comment

// Roads have a "is" field that specifies what it is: 'road', 'bridge',
// or 'tunnel'. Each road segment will only belong to one of them. The
// 'bridge' sublayer makes use of Mapnik's group-by rendering mode;
// attachments in this layer will be grouped by layer for appropriate
// rendering of multi-level overpasses.

I'm not sure that I trust that, since it doesn't seem to be accurately reflecting what's going on, but could we do this, reducing the number of layers?

https://github.com/omniscale/magnacarto/issues/7#issuecomment-160335907 for an explanation of group-by.

[mboeringa]

// Roads have a "is" field that specifies what it is: 'road', 'bridge', // or 'tunnel'. Each road segment will only belong to one of them. The // 'bridge' sublayer makes use of Mapnik's group-by rendering mode; // attachments in this layer will be grouped by layer for appropriate // rendering of multi-level overpasses.

Where is that "is" field coming from? It isn't a regular key, like "bridge" or "tunnel", so must be some pre-processed field.

I'm not sure that I trust that, since it doesn't seem to be accurately reflecting what's going on, but could we do this, reducing the number of layers?

Well, whether you trust it, or whether it is an accurate description of the process, the

// "Each road segment will only belong to one of them.

statement isn't always right in reality. There are rare but real road segments tagged as both bridge and tunnel, and they aren't necessarily wrong, a famous example is the https://en.wikipedia.org/wiki/Conwy_Railway_Bridge near Conwy, see also this comment by me in another issue:

Render covered=yes on bridges too if they are under a building https://github.com/gravitystorm/openstreetmap-carto/issues/930#issuecomment-54849564

Of course, whether these rare cases need rendering support is another matter..., and @math1985 closed the old issue due to its rarity, so that question is probably actually answered.

[matthijsmelissen]

Are we handling complicated cases they are ignoring? Are we doing something wrong? Are their vector tiles limiting what kind of street styling people do?

I suspect our code handles various layering issues that Mapbox Streets are ignoring. The most problematic of these, I suspect, are highway areas, like pedestrian areas. We render highway area fill in between casing and fill of layer 0-highways. As bridges are rendered above layer-0 fills and tunnels are rendered below layer 0-casings, we cannot really merge bridges and tunnels without breaking highway area rendering.

Is there somewhere a demo of Mapbox Streets on the web? I'm interested to see how they are handling highway areas.

[nebulon42]

Is there somewhere a demo of Mapbox Streets on the web?

e.g. https://www.mapbox.com/mapbox.js/example/v1.0.0/

[matkoniecz]

Are we handling complicated cases they are ignoring? Are we doing something wrong? Are their vector tiles limiting what kind of street styling people do?

Our road style styling is quite complex - from quick looking at https://www.mapbox.com/mapbox.js/example/v1.0.0/ - they have one colour (white) for all roads, footways and cycleways. Some highway values are displayed in the same style (or nearly the same) - for example there is no distinction between cycleway and footway, between highway=pedestrian and highway=construction.

All displayed railway=* values seem to be rendered in the same style, the only difference is zoom level where features appear.

It is may not be the biggest reason for this difference in code length but it certainly contributes.

[matthijsmelissen]

We render highway area fill in between casing and fill of layer 0-highways.

Illustration:

Mapbox Streets gets around this by neither rendering casing of areas, nor of pedestrian roads. I think we could perhaps drop casings of areas, but dropping casings of pedestrian roads results in rather ugly cartography. Would it be worth it to do this? Note that simply adding pedestrian casings to their rendering wouldn't work, because the ending of the casings would be visible on top of the area, giving the impression that the pedestrian streets end in dead-ends on the area.

WM does not render areas at all, with he given established tagging I think this rendering is really counterintuitive:

[pnorman]

are rare but real road segments tagged as both bridge and tunnel, and they aren't necessarily wrong

I've been trying to decide how handle bridge+tunnel objects in another project, and came to the conclusion I shouldn't.

Mapbox Streets gets around this by neither rendering casing of areas, nor of pedestrian roads.

I see that MBS vector tiles have lines, polygons and points in the in the roads layer. Would this help?

cc @ajashton, in case he has any insights into how MBS is handling this

[matthijsmelissen]

I see that MBS vector tiles have lines, polygons and points in the in the roads layer. Would this help?

Yes, it would make things a lot easier. It would make the query more complicated, but it would allow to reduce the number of queries (and thus the amount of duplication).

[dieterdreist]

2015-11-29 21:09 GMT+01:00 Paul Norman notifications@github.com:

are rare but real road segments tagged as both bridge and tunnel, and they aren't necessarily wrong

I've been trying to decide how handle bridge+tunnel objects in another project, and came to the conclusion I shouldn't.

+1, I'd give priority to bridge. Tunnel objects are really interesting in cases where they are hidden / cross a mountain / a river etc., otherwise it's just a particular way of constructing the bridge (not very different e.g. to a roof covered bridge, besides the architect took the view off the utilizers).

[mboeringa]

+1, I'd give priority to bridge.

I wasn't suggesting to give them special priority, just to show there are "those exceptions...", which is always good to know. Actually, the current rendering for the Conwy Railway Bridge, isn't bad, the labelling though must take care of the "covered" part of the story:

http://www.openstreetmap.org/#map=18/53.28004/-3.82427

[matthijsmelissen]

Some more comments from my side:

• In the next period of time, we should aim to reduce complexity of the stylesheet. The stylesheet is growing larger and larger, which is undesirable for reasons of rendering time, maintainability, and legibility of the map.
• One way to reduce complexity would be by solving problems at the right place. We should not try to solve problems that are better solved in for example Mapnik, Carto, Osm2pgsql, or the map data. If we can solve the problem in these packages (or the data) in a reasonable way, we should aim do so.
• Too many difference symbols make the map hard to read, and the meaning of the symbols hard to guess. In addition, it increases the complexity of the code. With symbols I don't only mean icons, but also dash patterns for roads, line width, use of colours, etc. However, dropping features is often not an option because of the mapper feedback loop. In that case, we should consider rendering multiple types of features with the same symbol.
• In addition, to reduce clutter, features should not be rendered at zoomlevels earlier than necessary.
• To make the aforementioned mapper feedback loop work effectively, we should aim to render most of the commonly used tags, and at least these that are useful for the general audience. I believe there are quite a few tags that would be useful to add despite our intention to reduce complecity. In particular, we should also allow rendering currently unused keys with hstore, such as craft and office. I believe the lack of ability to render craft and office keys in this project is in many cases holding back the process to settle on a tagging scheme, such as is the case for office=estate_agent/shop=estate_agent, shop=travel_agency/office=travel_agent, shop=tailor/craft=tailor, etc.

Of course, also non-maintainers are more than welcome to contribute to this discussion.

[nebulon42]

One way to reduce complexity would be by solving problems at the right place.

I agree. E.g. some complexity of the SQL could be reduced by using a custom database schema. I also think that not having hstore available holds us back from making proper cartographic decisions, which I see as major problem. Unfortunately there is nothing I could contribute to the transition to hstore currently.

[kocio-pl]

Any examples how hstore could help us (other than more granular objects)?

[nebulon42]

Examples are rendering communication masts only, improvements for airports, replacing deprecated tags with new ones (ford, emergency phone), render very small memorials on z19, and more. Regarding more granular objects hstore does not mean that each category has to be distinguished by e.g. an icon, it could also be used to drop rendering for some sub-category.

[matthijsmelissen]

Improvement of results at low and high latitudes. This is difficult since it requires largely departing from fixed zoom level based styling decisions.

I wouldn't like to add a lot of additional (and duplicated) code to this project to support this. I think if we want to do this, we'd need support for this in either Mapnik or Carto, or perhaps in an additional preprocessor. The same holds for latitude-based size decisions.

[nebulon42]

In the spirit of solving problems at the right place this might be relevant here too: https://github.com/mapbox/carto/issues/424.

[imagico]

Regarding

We should not try to solve problems that are better solved in for example Mapnik, Carto, Osm2pgsql, or the map data.

in combination with what has been said in https://github.com/mapbox/carto/issues/424#issuecomment-171797031:

I strongly believe that these are the way forward and strongly believe that CartoCSS has some deep flaws that are corrected in those technologies.

It seems this creates a kind of problem. The tools employed here (mainly Carto, Mapnik, Osm2pgsql and PostGIS) are not necessarily used exactly for the purpose they are primarily intended for and even if they originally were this might have changed over time like in case of CartoCSS. So it cannot generally be expected for these projects to adapt to the requirements of this style. Of course these are all open source tools that can be adapted to individual needs by anyone but i for example would have no interest in working on Carto to add new language features or to add support for new Mapnik features since it is IMO a dead end because:

• most key users have moved on and use different techniques,
• it is unlikely that Carto applications can be expanded beyond the original scope of a Mapnik preprocessor so the usefulness of any work put in there is strictly limited,
• if there is an universal map styling language broadly used by map designers everywhere in the future it is unlikely this is going to be CartoCSS.

Beyond that it is imperative for a high quality style that people can contribute with improvements without having to delve into the inner workings of the programs used for making any non-trivial changes. The fairly dynamic development this style has experienced in the last years is largely because it was fairly easy to productively contribute in a lot of fields.

If this was my own project i would probably start looking into re-evaluating the choice of tools used which would probably make sense to do in connection with considerations for vector tiles. This will however likely create two possibilities both not really attractive:

• Adopt tools developed for purposes that differ in priorities from this project and that will likely further diverge from it in the future which will make it likely the same situation as right now with Carto will re-emerge at some point.
• Engage in planning and development of new standards and new tools that are either tailored for the needs of this project or broad in scope so they clearly encompass the needs of this project now and for the foreseeable future.

[nebulon42]

I don't think that there is the necessity for any contributor to bother with internal workings of any tools used here if s/he does not want to. What I understood was that those who can and want should try to solve problems at the right place instead of working around them here.

if there is an universal map styling language broadly used by map designers everywhere in the future it is unlikely this is going to be CartoCSS.

This is an interesting statement and the natural question here would be: Which ones are in your opinion the most likely candidates? If we take for example Mapbox GL JS, of which my knowledge is superficial and maybe I'm also preoccupied with my CSS background, I don't see how JSON might be a good choice to express a styling language. In this regard even CartoCSS might be too verbose as the example of SASS (activate the SASS tabs) shows.

[imagico]

I don't think that there is the necessity for any contributor to bother with internal workings of any tools used here if s/he does not want to. What I understood was that those who can and want should try to solve problems at the right place instead of working around them here.

The problem arises if contributions here are rejected or discouraged because they should better be implemented elsewhere. IMO it is important for ensuring a high quality map that changes that are desirable in the outcome can be implemented within the framework chosen in ways that are acceptable for the maintainers.

This is an interesting statement and the natural question here would be: Which ones are in your opinion the most likely candidates? If we take for example Mapbox GL JS, of which my knowledge is superficial and maybe I'm also preoccupied with my CSS background, I don't see how JSON might be a good choice to express a styling language. In this regard even CartoCSS might be too verbose as the example of SASS (activate the SASS tabs) shows.

This goes somewhat beyond the scope of this issue but since you ask: I don't think any of the currently existing style languages is likely to become an universally accepted standard. This is probably not primarily a question of the superficial structure of the language (CSS, JSON, XML etc.) although this might play a role in acceptance by users. It is more a matter of being sufficiently generic to be usable for a broad range of applications but still being practically usable and understandable for a designer in specific use cases. Considering the huge variety of situations in which map data is styled in some way i am unsure if a common language for that will come up at all. In the short term i assume it is much more likely that many specialized languages will turn up each for its own niche like for styling the limited feature set of a certain vector tile product.

When comparing map styling to HTML+CSS also keep in mind that the latter works also because if it does not work you can always use Javascript to do things by hand. The equivalent to that here in the style at the moment is more or less doing things in SQL which can serve as a general purpose language for data processing. But in contrast to Javascript in websites which is on top post processing using SQL to do styling is 'from the wrong side' and therefore even less elegant.

[nebulon42]

FYI: since the development of carto IMO has pretty much stalled I have forked it and released a version 0.16.0 (https://github.com/gmgeo/cartocss). I did not take that step light-heartedly as I don't want to fragment the language, but I wanted to make some progress. New features include support for reading YAML MML, the ability to target Mapnik API versions from the command line and support for perceptual colours (HUSL).

[matthijsmelissen]

Wow, great work! Out of curiosity, did you also submit these changes as pull requests?

[nebulon42]

Yes, I did. I also asked if there is help needed in maintaining carto.

[nebulon42]

Another thing, regarding compile time this might be interesting: https://github.com/omniscale/magnacarto/pull/19.

[pnorman]

If this was my own project i would probably start looking into re-evaluating the choice of tools used which would probably make sense to do in connection with considerations for vector tiles. This will however likely create two possibilities both not really attractive:

I cannot see a future where OpenStreetMap Carto switches to any other language. I can see a new style being developed with a new technology, and look forwards to that because it will mean there's been advancements in what's available.

• most key users have moved on and use different techniques,
• it is unlikely that Carto applications can be expanded beyond the original scope of a Mapnik preprocessor so the usefulness of any work put in there is strictly limited,
• if there is an universal map styling language broadly used by map designers everywhere in the future it is unlikely this is going to be CartoCSS.

CartoCSS is now processed into Mapnik XML with two completely different implementations, MapServer map files, and JSON for use in Torque.

CartoCSS isn't perfect for complex basemap design and with this project has taken it beyond anyone else, but at the moment there aren't alternatives.

The current open-source options are

• Mapnik XML (symbolizers)
• MapServer Mapfiles
• Mapbox GL JSON
• GeoServer XML These are all low-level languages. They have their own advantages and disadvantages, but all suffer from the same problems that made us move from Mapnik XML in the first place. The bigger differences are the software they target
• Mapnik XML (layers) Mapnik XML for layer definitions is different than for symbolizers, being equivalent to JSON or YAML MML. and largely being a file format difference
• MapCSS This has the advantage of supporting even more implementations than Carto and having a more formal language specification. But it's tied very closely to OSM data, which would prevent us from doing some logic in SQL for performance and simplification of style coding.
• Glug This is probably the best way to write styles targeting Mapbox GL, but doesn't have significant adoption. It also requires another language for the vector tile generation
• CartoCSS The main language used by basemaps developed in the last three years. Works with version control and multiple contributors when using YAML MMLs.

If starting a fresh raster style today, I would still go with CartoCSS. If vectors with client-side rendering, either YAML layers + Mapnik, Mapnik XML, or Tilemaker for vector definitions, and either Glug or Mapbox GL JSON in YAML for the client-side styles.

[imagico]

I cannot see a future where OpenStreetMap Carto switches to any other language. I can see a new style being developed with a new technology, and look forwards to that because it will mean there's been advancements in what's available.

That makes sense from a certain standpoint but i view this project mostly as the style powering the map on osm.org and less as a certain body of code. Therefore IMO if a new style based on a different language providing continuity in the results takes over as the basis for osm.org i'd consider it the successor of this project.

If starting a fresh raster style today, I would still go with CartoCSS. If vectors with client-side rendering, either YAML layers + Mapnik, Mapnik XML, or Tilemaker for vector definitions, and either Glug or Mapbox GL JSON in YAML for the client-side styles.

That is perfectly reasonable. But you can already see that the range of choices you have is fairly poor and the options you described are a bit like the famous Henry Ford quote - you can have your car in any color you want as long as it is black. The different languages available are essentially different ways to do exactly the same and do not offer significantly different options from a design perspective. Interestingly the client side WebGL rendering is probably the approach with the greatest flexibility in principle compared to the standard rendering libraries which are tightly constrained by what is possible with AGG, Cairo etc. although of course the general restrictions of client side rendering prevent you from making full use of that.

Note i said i'd re-evaluate the choice of tools, that does not necessarily mean i would use different tools right now. But identifying the lack of good choices for the tasks at hand is the first step in improving the situation.

[kocio-pl]

In saying this, my personal goals for the next 12 months are around technology, not really cartography:

- Complete the upgrade to mapnik 3
- Sort out the migration to hstore
- Move to vector tiles

We've started with the first two of these, but they need to be completed. The third is more open for discussion and has impacts beyond the stylesheet, but I believe it's the right thing to aim for.

Just for the record - after almost a year:

• first issue will be resolved in days rather than weeks
• the second one is still being "sorted out" (somewhere in lua testing phase)
• the third one is not discussed too much, however there is an interesting smooth migration fork available lately (README_VECTOR_TILES.md).

[matthijsmelissen]

FYI, @pnorman has written a good blog on various vector rendering options: http://www.paulnorman.ca/blog/2016/11/serving-vector-tiles/

[matthijsmelissen]

Mapbox published a good blog on (their view of) map design:

https://www.mapbox.com/resources/guide-to-map-design-part-1.pdf

[kocio-pl]

I have a question about future Mapnik features which might be interesting for us - see #2962.

[kocio-pl]

What should development concentrate on over the next year or so? What are the issues that need improving most at this point?

Since there are few people active last months/years, it's hard to draft any direction and the need for this is also much smaller, so I guess we could close this ticket.

For me the most important direction is working with low zoom levels, because they are underused currently, but it's not something that needs planning, it's just a set of related elements. Another important thing now is making community active with coding, because without new coders the style development will halt, but social activity shaping is just a soft direction which does not need fixed plans.

[kocio-pl]

There's one strategic goal that is worth tracking IMO - migration to vector tiles, as envisioned by @gravitystorm almost 3 years ago and being discussed lately between team members. I guess it requires separate ticket, as it's big enough in itself.

[kocio-pl]

I'm closing this ticket now for the reasons explained above. Feel free to reopen the issue if there will be some other strategic things to discuss.

[matthijsmelissen]

I gathered some statistics w.r.t. the years in which issues are opened versus the years in which they are closed (first column means 'still open':

   Closed -  2018  2017  2016  2015  2014  2013  2012
Created
2018     47    71
2017     66    26   151
2016     65    18    37   174
2015     78     9    29    57   279
2014     84    18    26    25   112   326
2013     10     4     9     8    25    70    61
2012      0     0     0     0     0     3    13   10 

[kocio-pl]

Do you mean something like that?:

Created/closed	- (still open)	2018	2017	2016	2015	2014	2013	2012
2018	47	71
2017	66	26	151
2016	65	18	37	174
2015	78	9	29	57	279
2014	84	18	26	25	112	326
2013	10	4	9	8	25	70	61
2012	0	0	0	0	0	3	13	10

[matthijsmelissen]

Yes, thanks!

[matthijsmelissen]

Except closed and created swapped.

[kocio-pl]

Fixed now.

[imagico]

This is an interesting statistic but very difficult to read without knowing the reason issues are closed. The distribution of reasons why issues are closed has shifted significantly over time and the patterns in that have a strong influence back on reporting activities.

This may not always be obvious to long time contributors and maintainers here but casual contributors typically react strongly to how issues they report are dealt with. So overall neither the dealing of developers/maintainers with open issues nor the reporting patterns are constant over the time looked at.

What would be rather interesting to look at in terms of development efficiency is how changes made fare in terms of problems solved vs. problems created. This relates strongly to what i mentioned in https://github.com/gravitystorm/openstreetmap-carto/issues/2291#issuecomment-242908868. This is difficult to do because you cannot base it exclusively on issues actually reported, you would need to consider unreported problems as well. This is what in the end decides on if this style improves quality wise or not.

These unreported problems are critical to identify the unknown unknowns so to speak - the changes necessary to fix problems you are not even aware or do not understand. For improving and maintaining quality of this style it is therefore essential to minimize the unknown unknowns and to maximize completeness of the problems reported and documented and awareness of them. IMO strategies for handling issues would therefore need to concentrate on that goal.

[kocio-pl]

All the statistics lie this way or another. Quantity is (mostly) easy to get, quality is not - and one of the reasons is that it's very subjective matter. For me this style keeps getting better at reasonable costs, so the overall quality is constantly rising from my point of view, but for anybody else it might be otherwise.

It always strikes me that you tend to solve unknown problems while avoiding big and visible ones. This is not working for me. Big visions are great at the phase of designing the prototype, but after that the details matter a lot more. Then redesign or competing solution might happen at some point, but in the world of complex systems there are a lot of gotchas which should be addressed to make things better. I want to have a great map, not a great design of the map, even if I like conceptualism. Ignoring details and concentrating on documentation instead of the code and community will hit the map quality in my opinion.