Improve tree_row rendering

[nebulon42]

Current tree_row rendering looks too similar to hedges. At least I have seen this association in OSM notes several times already. I also first thought it might be a hedge and had to use the data analysis tool on osm.org to find out what it was.

This has been discussed in #215 already, but I'd like to bring this up again.

First I wanted tree_row to resemble the style of individual trees as you can see below.

This has the obvious drawback that we give the impression of a certain number of trees that are not represented by data. Something similar could be said about cable car aerialways and pylons, but there the pattern is more abstract.

I'd like to use this issue to discuss improvements to the initial idea of the preview above, where the impression of a certain number of trees is not given or at least reduced, but which does not resemble the hedge-like style.

Some ideas I had are:

decrease the space between individual "trees"

add an additional line connecting the "trees" (note the problem with line endings)

keep the hedge-like line but add "trunks"

Personally I like the separated trees most, but the impression of a certain number that are not represented by data is a problem that cannot be neglected.

[dieterdreist]

sent from a phone

Am 16.08.2015 um 10:28 schrieb Michael Glanznig notifications@github.com:

I'd like to use this issue to discuss improvements to the initial idea of the preview above, where the impression of a certain number of trees is not given or at least reduced, but which does not resemble the hedge-like style.

IMHO this issue demonstrates that there is a general problem with this tag: we can't render something sensible because we are missing the required information (how many trees, distance between them, individual positions, eventual gaps because some trees are not there anymore or have been deliberately kept away for some other reasons).

Yes, stating there is a tree row makes sense when describing something with words, and it is faster to draw a line than mapping individual trees as nodes, but it isn't a very suitable way for a map to represent this kind of feature, and it comes for the expense of much fewer information.

[imagico]

I think the problem here is that the dots still somewhat imply specific data and add unnecessary clutter. You could try a fairly weak line pattern above the plain line that structures it a bit to make the distinction between tree_row and hedge.

Swiss topographic maps for example use a mixture of larger circles and smaller dots to illustrate hedges:

For tree tows you could use just the circles in regular intervals.

In any case i'd probably make it significantly thinner than the individual tree icons at the higher zooms.

[dieterdreist]

sent from a phone

Am 16.08.2015 um 11:16 schrieb Christoph Hormann notifications@github.com:

For tree tows you could use just the circles in regular intervals.

which would suggest both: regular intervals and a specific distance you don't actually know if it's true

[mboeringa]

which would suggest both: regular intervals and a specific distance you don't actually know if it's true

I think we've had these discussions before in other contexts:

1) - do you want to recreate "exact" feature densities and spacings by complex tagging and very complex automated processes 2) - do we go for cartographic abstraction, meaning a given symbol of tree rows does not necessarily have to exactly represent the number of trees present.

Personally I think 1) is too high ambition in many cases like this one, difficult to achieve in code, prone to tagging errors and might be difficult to maintain in the long run if tagging practices change.

I would go for the pragmatic cartographic abstraction, as employed by generations of cartographers and also shown beautifully here by @imagico... (this is also what I implemented in my ArcGIS renderer).

Some things are just not worth the effort (of course that is my wholly personal opinion ;-) )... but feel free to write the pull request that does the magic...

[dieterdreist]

2015-08-16 12:45 GMT+02:00 mboeringa notifications@github.com:

1) - do you want to recreate "exact" feature densities and spacings by complex tagging and very complex automated processes 2) - do we go for cartographic abstraction, meaning a given symbol of tree rows does not necessarily have to exactly represent the number of trees present.

I suggest we map individual trees of a tree row. This put actual detail information into the db and is easy to visualize (as well as to map).

[SK53]

I also like the Swiss hedge symbology. I believe Wainwright used something slightly similar in his books.

I have done some experimentation with trying to add something similar to the suggestions of @nebulon42, largely based on using an assumed 10-20m spacing of trees (the spacing in most tree rows is fairly constant, but this is just an assumed conventional value, in Windsor Great Park the long avenues have a spacing ~17.5m). The significant problem is if the row has a kink in it, this either distorts the pattern, or looks odd because no tree is shown at the kink itself.

I used the previous tree symbol, spaced conventionally, but additionally represented the whole tree row with a thinner green dash array at around 30% opacity.

Two queries for tree row:

1. select "natural", tags->'taxon' taxon, tags->'species' species, tags->'genus' genus, st_length(way) len, way from planet_osm_line where "natural" = 'tree_row'
2. select "natural", tags->'taxon' taxon, tags->'species' species, tags->'genus' genus, st_length(way) len, way, (dp).geom split_way from (select * , st_dumppoints(st_segmentize(way,75)) as dp from planet_osm_line where "natural" = 'tree_row') x )

Carto:

`

tree_row {

[natural='tree_row'][zoom <= 18] { line-color: #44aa22 ; line-width: 3; line-dasharray: 2,2; line-opacity: 0.3; } }

tree_row_point {

[natural='tree_row'][zoom >= 16] { point-file: url('symbols/tree.png'); point-placement: interior; } `

These were very early experiments which I did not take further as I had enough material for the talk at Karlsruhe already.

It is also likely that the natural=tree_row tag may be used in association with mapping of individual trees (particularly in parks tree rows may be obvious to the eye, but difficult to extract programmatically from individually mapped trees).

[kocio-pl]

I was always wondering why there is no option for tagging the number of trees in the row. For me it's a logical extension and can help when there is too many trees to try to start drawing them now, but the numbers are known.

[SK53]

@kocio-pl I wouldn't want to do it at Clumber Park, the tree rows are about 6-7 km long, but its an interesting suggestion. I would actually suggest tagging the typical spacing interval which only requires checking say 3-4 trees, something like tree_row:spacing=17.5 or tree:count=1000 (assuming Clumber type conditions). Perhaps we should add something to the wiki.

[matkoniecz]

We may also want to check whatever natural=tree_row should be teated similar to highway=road - a special kind of fixme waiting for detailed mapping.

[HolgerJeromin]

The wiki says: "Usually, however, it's not necessary to map the individual trees in a tree row."

[SK53]

@matkoniecz I think tree_row stands very much alone and in most cases no one will ever map the individual trees. Even when individual trees in a row are mapped it may still be very useful to map the row as a distinct item (it may be too complex/computationally expensive to identify them on the fly).

[dieterdreist]

sent from a phone

Am 18.08.2015 um 11:19 schrieb Holger Jeromin notifications@github.com:

The wiki says: "Usually, however, it's not necessary to map the individual trees in a tree row."

I propose to delete the "not" to make sense of this sentence ;-)

[Robou]

Hi, there are many tree rows where the trees can not be counted and separated. See the image below, with two tree_rows along a road:

In my area, most tree rows are usefull to map because they separated crop fields and thus are landmarks. But they can not be mapped as barrier=hedges because they are real very tall trees. Their goal is to make a barrier against the wind wich is very strong in the area and always in the same direction.

I like the third image of the original post from @nebulon42 :+1:

"add an additional line connecting the "trees".

but maybe without the trunks drawn and the circles closer to each other?

Or there could be 2 separate ways of rendering :

• the tree_row is uncountable (e.g. rural areas), with the trunks not rendered and some randomness on the diameters of the trees, a continuous line connecting them.
• the tree_row is countable (e.g. botanic gardens, public parks...) : the rendering show some kind of individual trees, almost like a dotted line.

[dieterdreist]

sent from a phone

Il giorno 02 ott 2016, alle ore 11:58, Robou notifications@github.com ha scritto:

there are many tree rows where the trees can not be counted and separated. See the image below, with two tree_rows along a road:

separating trees is easy, you have to look at the trunks. While it might not be possible with this particular aerial image, it would be easy to do with a photo from a winter survey.

[dieterdreist]

sent from a phone

Il giorno 02 ott 2016, alle ore 11:58, Robou notifications@github.com ha scritto:

But they can not be mapped as barrier=hedges because they are real very tall trees. Their goal is to make a barrier against the wind wich is very strong in the area and always in the same direction.

sounds actually like a hedge. Tall trees do not exclude that it's a hedge.

[polarbearing]

Separate rendering for countable vs. uncountable would need a specific tag. However, once the survey allows to map individual, i.e. countable trees, such as the winter image @dieterdreist mentioned, or ground survey, mappers will have a tendency to do so anyway. I see a lot of street tree mapping in Berlin. Consequently, I would be against any simulated drawing of trunks in a tree_row.

[marczoutendijk]

Recently the Dutch community encounterd a situation where the mapping of the tree_row really was some overkill.

This discussion is now running for almost 3 years. There have been some good ideas earlier in this thread (e.g. by nebulon42). Personally I don't think that the tree_row should represent the exact number of trees. When using landuse=forest, the number of tree-icons used to render the forest don't represent actual trees either. Rendering the tree_row as a simple dotted green line (with the dots not too small) would allready be an improvement.

[kocio-pl]

Would you like to prepare a testing code?

[marczoutendijk]

I haven't done that before, but mathhijsmelissen knows how to do that. He is a member of the Dutch community and he is also an osmcarto-style maintainer. I'll ask him to join in.

[Kogacarlo]

How about rendering a series of trees with fixed length in between and some randomisation in diameter. That would generate a realish-looking tree_row. The fixed length would generate problems at the ends of the row though that will have to be countered.

[matthijsmelissen]

There are nearly 400 open issues and I have limited time so unfortunately I need to make choices in what I work on. There are issues that have higher priority to me than this one (for example improving the pook of the low zoom levels), so I dont think I will have time for this isssue now.

[kocio-pl]

That's our main problem currently - lack of time and/or coders. We have lot of ideas, so we need new people to try writing the code and i can help with that.

[marczoutendijk]

OK, before I say "yes": I have coding experience as the developer of OpenPoiMap and am willing to devote time to this project.

• What tools do I need?
• Where can I see (and learn from) examples?
• How and where can I start?

Being retired, one would expect that I'm 24/7 available, but mysteriously I now seem to have less time then when they paid me to do nothing :) So, don't expect results within one week.

[kocio-pl]

No problem, we have no deadline for this.

You can start reading general description:

https://wiki.openstreetmap.org/wiki/Standard_tile_layer

and install Docker environment:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/DOCKER.md

If you will have any problems or questions, just let us know.

[pelderson]

I bumped the issue in the dutch osm community forum. Now I find that many of my thoughts were voiced two times before. I'm a newb, that's for sure, still I think I might add some insights. Is it an idea for me to compile everything about the keys and the visuals in a proposal wiki page? I understand that the main problem is time and coding capacity, and I'm happy that Marc is digging in.

[kocio-pl]

Yes, when talking about tags, the first thing is to go to the Tagging list and discuss things and then make a proposal if needed. Coding is a secondary issue, we have to be sure that tags we are about to use are documented and popular enough.

[kocio-pl]

You might be interested to hear about this discussion on a Tagging list:

https://lists.openstreetmap.org/pipermail/tagging/2018-April/thread.html#35849

It's about proposed spacing=* key, which could improve tree_row definition and rendering.

[pelderson]

I have published a tagging proposal wiki page and announced it on the Tagging list. It was well received, and useful comments have been processed. The documentation is not complicated: spacing=, apply to a way or area when applicable. Unit is m by default, otherwise add .

The section about adaptive rendering is tentative, of course. I figured you would maybe map the given value to a 3-point or 5-point scale and design a pattern to match this symbolically. The middle of this scale would be the default rendering style which we are talking about in this thread.

As stated in the tagging proposal, my preference for tree_row rendering would be a o - o - o - o repetitive pattern where the o's ar greenish crown-like dots, in any case smaller than the current tree symbol and without the middle point, and the hyphens are dark brown, reminding of tree-stems but not looking like one. The regularity shows that the line is symbolic rather than exact, still it shows that it's about trees because of the colours and the pattern. Important is that the surface below is showing. So if the tree_row is on a paved pedestrian area you should see that the tree_row is on the pavement, not instead of the surface. If the surface is grass, you'll see the darker tree_row on the lighter green grass rather then instead of the grass.

Some of you are really good with patterns and pictures, but I am a total disaster with that. If anyone could make a kind of design illustration for my clumsy description, I would very much appreciate.
I'll try nonetheless. What tools do you use to design a pattern or symbol?

[pelderson]

Sorry I see that I cannot use some characters in the tekst. spacing=number otherwise add space-unit.

[kocio-pl]

For making symbols I use Inkscape and http://www.imagico.de/map/jsdotpattern.php for patterns (although it's for 2D patterns).

Since the tagging is documented, but not yet used, there's no hurry to start rendering it. It should be known that people really use this scheme. However designing process can start right now, if you want.

[pelderson]

I will have a look at inkscape and imagico to see if I can make examples, thanks.

The tagging for adaptive rendering is for the future, so redesign of the default rendering for tree_row does not have to wait for it. However, if possible I think the design should be such that the rendering can later be adapted to represent closer / wider spacing.

Then you wouldn't have to redesign, just adapt.

2018-04-24 12:54 GMT+02:00 kocio-pl notifications@github.com:

For making symbols I use Inkscape and http://www.imagico.de/map/ jsdotpattern.php for patterns (although it's for 2D patterns).

Since the tagging is documented, but not yet used, there's no hurry to start rendering it. It should be known that people really use this scheme. However designing process can start right now, if you want.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/1753#issuecomment-383889527, or mute the thread https://github.com/notifications/unsubscribe-auth/AkrTypp2aafrRd9owH-aKi4kKywevzB_ks5trwR-gaJpZM4FsVMl .

-- Vr gr Peter Elderson

[kocio-pl]

I think the mockups could be made in any graphic app, like Gimp or whatever. Inkscape is good for vector icons/symbols to be scaled and colored. Rendering tests can be even easier, because you just need the testing environment and you can change options in the code and see the results immediately.

[pelderson]

I've used Inkscape to create a very crude impression. Important for me is that the surface below the tree_row is shown. Trees in a tree_row are not landcover or surface, they are placed on the surface. (except for high densities, then it can resemble a thick hedge). For rendering without the proposed key for spacing (default spacing, in my view), just look at the middle of the five in each sample group.

[pelderson]

The effect would be something like this:

[Tomasz-W]

If somebody is planning to work on this issue, please consider also https://github.com/gravitystorm/openstreetmap-carto/issues/2736 (Wood and tree_row should be the same colour)

[pelderson]

Agreed, as long as it's not a continuous fat green band. On the ground, a tree_row is a row of dark brown poles rather than a green line, most of the time. If there is grass on the surface, that should show as grass and there will be a lighter green band on which you see the tree_row. If there is gravel or sand, you should see that, with the tree_row on it.

[yvecai]

I have a mix feeling about using a pattern on natural=tree_row without a better description of the tag. Nothing says in the definition that natural=tree_row describe a rather regularly spaced tree row (apart the picture). On the other hand barrier=hedge allows trees.

So, I'm afraid that if we use a regular pattern, mapper is tempted to use barrier=hedge for an irregular tree row. And if we use something more random, mapper is left to map every single trees for a regularly space tree row. The simple line is not that bad.

[tordanik]

Something to consider: It's explicitly possible to map both the tree row and the individual trees that belong to it (as nodes of the natural=tree_row way). This kind of mapping can easily clash with a regular pattern applied to the way.