Extending rendering of trees depending on the additional values

[wmyrda]

I see heated discussion over import mailing list about adding of 150 000 trees for city of Ottawa. IMHO it is a mater of time before this data and similar data as that will be provided or added into OSM therefore it would not be a bad idea to make use of at least some of the additional tags.

Code I attempted to prepare http://bigvo.hopto.org/osm-extra/carto-patches/4.0/021-natural_monument-tree_v5_direct.patch does make use of height, circumference and denotation to further distinguish among trees on the map.

General idea there is for trees greater in size especially to appear sooner and to distinguish natural monuments as those worth extra attention.

I am not the postgis guru therefore code I have prepared fails to work correctly for me due to renderd not being able to find "denotation" among values in the database even when I attempted to get them from the hstore table so help finishing up the code here is welcomed.

renderd[13870]:    reason: Postgis Plugin: ERROR:  column "denotation" does not exist

[imagico]

It would be much more useful (and also easier for everyone to answer your questions) if you'd check in your changes as a separate branch on a fork of this project on github under your account. If you want your modification to be merged here this is actually a requirement - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md

Regarding the change itself - IMO you would need to show some examples why your changes are useful. The current uniform rendering of all trees in the same form as a universally recognizable symbol has great advantages for the map user - changing that will probably make reading the map more difficult. You would need to demonstrate that the advantages outweigh these disadvantages.

Side note: 150k new trees in Ottawa are not really significant in the grand scheme of things - overall we currently have 8 million trees in the database. We also try to base rendering decisions mostly on manual mapping to give mappers useful feedback for their work.

[wmyrda]

I the future I plan to make more use of github and learn it but for now that is above my knowledge level hence the code change proposal is available in the form of a patch which is what I am familiar with.

As for uniformity of the code I do not see any problem there as the code does not change the way the trees as shown currently in the carto and practically changes nothing for the trees will the only tag of natural=tree. Ideas behind the code reflect only the extension of the current method which is affecting very small amount of trees overall

• larger trunk for trees with greater circumference. That tag only have 2.88% of all trees in OSM DB
• greater size of the tree crown cover and earlier appearance for bigger trees with great height and circumference combined - 2% trees have both values and probably only slight number of them reaches the required levels
• use of slightly different color for trees which are natural monuments 0.26% of all trees

Giving that on the map we do distinguish places of greater importance like stations, universities, hospitals etc. even they all are just buildings. Applying same logic here it is reasonable to place more attention on the trees which are exceptional comparing to the rest.

As side effect change also would encourage mappers to gather more data (do manual work You talk about) in the wild as they will see effect of their work.

[kocio-pl]

From my experience as a non-programmer, forking the repo in GitHub is super easy, the basic git set of tools (including GUI-based like gitk and gitg under Linux) is not too hard to use, and creating PRs in GitHub is also piece of cake. I hope you'll try it soon, because it will make your code much more available for the others.

[HolgerJeromin]

You can even click "edit" on every file here in the webinterface and github will make everything for you.
Click "edit", make changes, save, click "make pull request"
It is really that simple!

[pnorman]

I am not the postgis guru therefore code I have prepared fails to work correctly for me due to renderd not being able to find "denotation" among values in the database even when I attempted to get them from the hstore table so help finishing up the code here is welcomed.

You need to extract the tag from the hstore. The style guidelines have a short example of this, for others search for -> in project.mml.

I the future I plan to make more use of github and learn it but for now that is above my knowledge level hence the code change proposal is available in the form of a patch which is what I am familiar with.

We operate on the fork & pull model, so in order to accept your contribution it needs to be in the form of a pull request.

You should keep in mind 3.x compatibility and we can't accept this feature for the next release.

[SK53]

Just for reference I have in the past made some experiments with trying to render different types of trees at large scales. My basic notion was to use an icon of the leaf shape to represent the tree. You can see some of the svg files I created for this purpose in the table here . I enclose two examples of a project I have done nothing with for some time:

I think they do give a little feel for some of the likely issues with trying to render trees differentially.

As @imagico says make a fork on github & then we can all look at it rather than downloading some random code with a .patch suffix. In this form I am unwilling to look at what you propose in detail.

Personally I think that trying to differentiate trees based on size will not work particularly well, and I'm not sure how informative such information really is. For instance you may have a avenues consisting entirely of very large old trees, which are probably generally better represented as tree rows (as per the current style). In many European cities Plane trees and Limes tend to be large, often because the bulk of planting was in the late 19th & early 20thc centuries, but I doubt if they are specifically interesting in themselves. You may also get odd cut-off effects when a group of trees is collectively borderline for a rendering criterion: so for instance an avenue of trees is only shown partially.

In principle the idea behind the denotation tag was meant to help identify which trees might have a priority of interest, but I dont think it is used in ways that are very useful. Furthermore it is not possible to readily add the tag to an imported set of trees.

Tree circumference or diameter is indeed a function of age which is likely to be of interest, but to determine age you also need to factor in the species. The tree register in UK has a "Champion Tree" scheme based on a mix of criteria including species. This is probably far too complex to handle in regular carto, and I doubt if the rules are in a usable open form.

Height & crown spread tend to reflect position (& species again). There is obviously some value in rendering crown diameter at very large scales (probably z20 & above).

One other problem is that relevant parameters may differ significantly by latitude, altitude and climatic zone as well as by tree type.

One approach which might work is something akin to @gravitystorm's rendering of bicycle parking on OpenCycleMap, where large parking amenities are marked out with an additional number on the icon: one could use girth or height for this type of thing.

[dieterdreist]

sent from a phone

On 12. Jul 2017, at 17:00, SK53 ***@***.***> wrote: For instance you may have a avenues consisting entirely of very large old trees, which are probably generally better represented as tree rows (as per the current style)

the thing with tree row is that it hides the interesting aspects like anomalies due to driveways or otherwise missing trees (lost through storm or lightning strikes or cut because ill, etc), also it generally doesn't convey any frequency information or more important, rhythm.

[matthijsmelissen]

I think this proposal is too specific for a general-purpose map. I am therefore going to resolve this bug as 'wont solve'.

[kocio-pl]

I think of using denotation for distinguishing standalone trees from groups. I find this information useful for rendering some special trees earlier. I wish we had something like this for other objects. I propose to reopen it then.