Drop legacy dependencies

[nebulon42]

Sorry for bringing this up again, but I think this is important for the project.

Currently we are supporting several Mapnik versions and several Carto versions. This makes the use of new features that are only available in recent versions quite difficult or impossible. This burden hinders the progress in my opinion.

I think we should only support Mapnik 3.x and Carto 0.16.x from a near point in the future on. This would require a new major version, which would be 3.x. The database reload would then be 4.x.

Style consumers would not get an unusable style, but they would be stuck with the last 2.x version until they upgrade their software.

Style contributors that use Kosmtik would be ready for the update as Kosmtik comes with Mapnik 3 and carto 0.16 by default. Style contributors that use Tilemill would run into problems, but it might be possible to upgrade node-mapnik and carto by hand to the required versions. (I should test this probably.)

What would we gain?

Mapnik 3

• improved control of shield placement (easily fixing New city labels sometimes overlap #2378)
• SVG patterns
• ... more?

Carto 0.16

• support of YAML MML (no need for yaml2mml any more, solving yaml2mml not compatible with python 3.5 #2447 and similar) -> TileMill?, Kosmtik ok
• support of HuSL, a perceptual colour space with no colours that cannot be represented in RGB (unlike LCh, but with some compromises), we could directly do colour math in a perceptual colour space removing the need for generate_road_colors script (for a proof of concept see https://github.com/gmgeo/osm-carto-gmgeo/blob/master/style.mss#L138)

The last two points reduce complexity and also make it easier for new contributors to understand the style and get going.

What are the risks?

The biggest problem is TileMill and has been so for months/years. Recently, there was some movement and I appreciate the effort. But I'm still not sure if there will be substantial progress. There have been concerns that Kosmtik is not easy enough to install and by excluding TileMill we will lose some potential contributors. This is a valid concern, but I think we should take the risk.

I'd like to know how many contributors are using TileMill. Please speak up.

[matthijsmelissen]

I support this.

[imagico]

The most significant issue i see here is that carto documentation is extremely poor - it essentially consists only of

https://github.com/mapbox/carto/blob/master/docs/latest.md

which is just a feature list. Documentation of YAML MML syntax seems also non-existent by the way (unless i seriously missed something here). The most significant body of documentation around carto are the various instructions and examples involving Tilemill. Moving away from that will make the whole framework become less accessible and more cryptic. HuSL is a good example here - unlike Lch/Lab which have a well established theoretical basis and plenty of related literature the only thing i can find about HuSL is some superficial explanations on the purpose and implementations of conversion functions in various languages. The claim that you can do proper color math in this color space, which seems to be implied, appears fairly dubious to me considering saturation is defined as percentage of the sRGB limit. Perceptually uniform color space means perceived color differences are proportional to the euclidean distance in color space - this does not appear to be the case with HuSL.

I am not opposing this idea in general but i would suggest to be careful to not just base this on some perceived convenience advantages. The clearest substantial advantages i see that would allow doing things you can't do right now are improved label/shield placement and SVG line patterns.

[nebulon42]

Documentation of YAML MML syntax seems also non-existent by the way

Documentation of the JSON MML is missing too. :) And YAML is just another syntax anyway. But, yes, this is missing.

By the way, Carto could use help to improve the documentation.

HuSL and the like were just examples. I don't want to expand on this as this a bit off-topic here, but for me at least LCh is pretty useless for a design-purpose at least where you have to represent colours in RGB in the end. You frequently end up with non-representable colours which makes finding a colour a trial-and-error process and tedious.

[pnorman]

My concern with maintaining compatibility with Mapnik <3.0.0 is that we're not properly testing for that target or checking that we don't include new features.

[kocio-pl]

Related to #2198 (but wider in scope).

[imagico]

Documentation of the JSON MML is missing too. :)

Among the blind the single-eyed is king... 😄

for me at least LCh is pretty useless for a design-purpose at least where you have to represent colours in RGB in the end.

In principle this is what color management is for.

I don't consider the fact that LCh can represent colors outside sRGB a disadvantage - on the contrary, it makes the fact that sRGB has ultimately arbitrary limits explicitly visible while otherwise it is disguised and hidden. Just becase you don't happen to run into a problem does not mean it is not there.

Practical example - you have a fairly saturated tone and you want to create a number of matching tones at the same saturation/chroma and lightness but with different hues. When you do this in LCh you will likely run out of sRGB gamut somewhere. But this just means you cannot do what you want to do. This is simply due to the fact that in sRGB (or in any other RGB color space for that matter) hues near the primaries can be represented to a much higher saturation/chroma than in between.

[kocio-pl]

@nebulon42

I think we should only support Mapnik 3.x and Carto 0.16.x from a near point in the future on.

What deadlines do you propose?

[nebulon42]

In principle nothing would stop us to tag 3.0.0 immediately instead of 2.45.0, because nothing changes yet. It is just a warning that we may start adding backwards incompatible changes from now on.

[kocio-pl]

I was asking not about tagging, because it's a technical detail, but rather when we say we don't want to support old stuff. When do you want to issue this warning?

For example I would prepare a PR dropping MML file for a start and then we should think how to tag this release, but first I need to know we agree that from given MM-YYYY such code could be merged at all.

[nebulon42]

Tagging here is not so much a technical detail, but is the warning. See http://semver.org/ for details:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

But you can do this in two ways. Either increment the major version without incompatible changes or increment it after there have been incompatible changes merged. Either way is ok, but I prefer the former because having a major version increase means that one can expect breaking changes in current master even if there are none yet.

For example I would prepare a PR dropping MML file for a start

This would need accompanying changes such as documenting that Carto 0.16.x is required.

I need to know we agree that from given MM-YYYY such code could be merged at all

My personal opinion here is: immediately. Why wait? But others might object here.

[nebulon42]

Interestingly, #2470 would require Mapnik 3 already.

[kocio-pl]

This would need accompanying changes such as documenting that Carto 0.16.x is required.

Of course - I didn't mean just deleting the project.mml... 😄

My personal opinion here is: immediately. Why wait? But others might object here.

Thanks, that is exactly what I was asking. Others might always object, but it's good to start with something to avoid endless loop (everybody deadlocked waiting for what somebody else would say). I support your proposition.

Any comments?

[sommerluk]

I also think it’s good to move on. It reduces testing work (only one supported version) and makes things envolve.

[matthijsmelissen]

My personal opinion here is: immediately. Why wait?

+1

[pnorman]

Tagging here is not so much a technical detail, but is the warning. See http://semver.org/ for details:

We're not a software library with an API, we don't follow semver. We do need to bump the major version if upgrading either Mapnik or Carto requirements, but that's because of our versioning policy