On Friday 29 June 2018, Paul Norman wrote: > > I had a go at fixing the roads code with > https://github.com/gravitystorm/openstreetmap-carto/pull/2869, but > didn't have free time. Based on that work, I'd estimate that the > roads code is twice the size and complexity of what it needs to be. > > With the surface code merged, I would be unwilling to tackle a > cleanup like that. I like the surface code as a technical demo, but > find it's too much complexity for the style in a part of the style > which is already difficult to understand.
But the surface rendering from Lucas is something you could fairly well re-integrate into a reworked road rendering framework afterwards - and this is probably also the way i would approach it. By the way roads rendering would be a really good test case for designing a rendering framework that would allow addressing the fundamental needs of rendering (in particular getting everything drawn in the right order and combining polygon and line features) with little complexity and at the same time allow flexibility in design (with casings, patterned fills, additional center lines etc.) I have the impression that giving up the idea of fixed layers and database queries being directly attached to them in favour of a free modularization of how the data is queried and defining how it is drawn in what order independent of that could make this significantly easier and more intuitive. How to implement something like that in an actual renderer is of course not a trivial task. -- Christoph Hormann http://www.imagico.de/ _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
