Concluding remarks on tree rendering
Concluding remarks on tree rendering

Concluding remarks on tree rendering

| 1 Comment

This is part four of a four part series of blog posts on the depiction of trees in maps – see part 1 for a discussion of tree rendering in traditional maps and plans, part 2 for mapping of trees in OpenStreetMap and rendering in OSM based maps and part 3 for the discussion of a new concept of tree rendering.

The tree rendering implementation i showed and explained in the previous part is essentially just a sketch demonstrating a few of the design concepts you can explore once you truly disregard the technical constraints of common automated map rendering tools. Is this too much for a general purpose map style? Maybe.

As i mentioned recently again the whole world of automated rule-based map design is, once you leave the pre-made paths scouted already by tech companies and tool developers working for them, largely unexplored territory. Working on the tree rendering once more made me realize how much that is true especially for large map scales and high zoom levels. Once you start truly designing maps specifically for z19/z20 you are well into the traditional domain of architectural drawings and site plans – which is a whole new field of considerations and design ideas, as i tried hinting at in the first part with some examples. Most digital interactive map designers so far simply treat this scale range as an extrapolation of the smaller scales. This even more applies to all the modern vector tile maps where everything above z16/z17 is literally just the same rendering blown up to larger scales plus more POI symbols and labels.

And i think this series of blog posts also once more demonstrates that the inherent, high level capabilities of currently available map rendering tools are very limited compared to what in principle would be possible and desirable to have to produce well readable maps. The CartoCSS + Mapnik toolchain i use here has the advantage that it provides the means (via PostGIS code) to implement this on a low level by hand but practically such low level techniques are probably beyond reach for many map designers. And using this method has its own limitations – apart from the obvious efficiency issues you also cannot combine this kind of manual symbol processing with use of symbol/label collision detection and prevention for example.

So once again my strong suggestion to the OSM and the FOSS community that i have already stated on various occasions: You need to strategically invest in advanced map design tools for automated rule-based map rendering. And if you do so while looking at things purely from a software developer perspective or following the footsteps of big tech companies you will fail. The proprietary software producers have learned this lesson. They actively involve and actively listen to map designers in their strategic planning and research. Their target users so far are predominantly still the traditional map creators to whom map design means manual processing of concrete data and not the development of automated rules to process generic data like i discuss it here. But this is going to change. So do not miss this window of opportunity.

Flowering tree

One Comment

  1. Pingback: weeklyOSM 621 | weekly – semanario – hebdo – 週刊 – týdeník – Wochennotiz – 주간 – tygodnik

Leave a Reply

Required fields are marked *.

By submitting your comment you agree to the privacy policy and agree to the information you provide (except for the email address) to be published on this blog.