Rendering (unpaved) surface is a real need. Judging from the map notes users don't get the distinction and conflate track symbol with unpaved. Mappers do it too.
In Poland (and maybe somewhere else) wrongly tagged tracks (what should be residential+unpaved) are a big problem, almost intractable in scale. We have more tracks by length than any other highway type. The road pattern was a solution conceived AFAIR because we have tons of other decorations in place. Tunnels, embankments, and so on. If we can develop alternative solution to render unpaved roads, that's fine too. pt., 29 cze 2018, 12:00 użytkownik Paul Norman <penor...@mac.com> napisał: > I've been involved in OpenStreetMap Carto less and less, partially > because I work with CartoCSS setups enough for work. > > > On 2018-06-29 2:06 AM, Christoph Hormann wrote: > > And you are wrong that "nobody seems to be even noticing" complexity of > > the roads code. At least Lucas, Paul and me have a very good idea > > about this. And the unpaved roads rendering is not the problem here, > > the problem is the complexity of roads rendering in general. > > 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. > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
