<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Paul,<br> <br>The Mapbox GL styles are very low level, and are like the mapnik XML input files. The Mapbox GL editing tools available don't seem to provide abstractions over the underlying specification.  <br><br>Also, rewriting from scratch the main OpenStreetMap Carto style sheet is not appealing. There has been a lot of work put into it, and whatever happens next, everybody is going to be living with it for a long time.<br><br>I have done some projects with Mapbox GL with client side rendering, and the performance on my tiny style sheet was unacceptable on mobile. Having the main style sheet use client side rendering will need to wait for newer and faster phones.<br> <br>Going back to the problems. Long term it is clear that it would be a good thing if OSM had a client side rendering option. Also, right now, the existing tile servers are overloaded. A victim of the projects ongoing success and CartoCSS baked in performance issues. <br><br>My ambitious thought is that the equivalent of the CartoCSS needs to be invented to provide a human friendly interface to both the Mapbox GL and mapnik rendering engines.<br><br>The language should be at a higher level of abstraction. For example, it should just handle the "layer" key. To broaden the pool of contributors, it should directly use the OSM key and values, and not a foreign intermediate SQL database or tile schema. Lastly, accept that the language is just for rendering normal maps, and assume things like labels are always on top. </div><div dir="ltr"><br>I am not a fan of CartoCSS, but in theory, we could write a new CartoCSS processor to target Mapbox GL to save the main style sheet.<br><br>Jason<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>