Hello, there.
Could you make this key rendered? It is used on ways, to say that they are bordered by trees; its main use is for waterways and highways, but it can be used on any OSM way. It is useful as a landmark, as it highlights linear features in a landscape, and is more practical than natural=tree as it does not necessitate a node per tree, or natural=tree_row which makes the tree line a feature by itself whereas, in these cases, the the row merely go with the way.
Its main value is yes, which means that the way is bordered by trees, implying that trees are present on both sides of the way; it can also be explicitly stated using the value both. The value can also be right and left, to model trees on one side only, and no, to explicitly represent the absence of trees.
A rendering example is this one used in France, i.e. like this
for waterways and like that
for highways. It could be simpler, though, to render this as green dots on the side or sides of the way, to clearly state these are trees.
Regards.
I would not expect that it is possible to get reasonable rendering for that as distance of tree line from feature may strongly vary.
I also think that such feature should be mapped at least as natural=tree_row, mapping tree row and waterway on a single object seems to be a poor idea.
In addition tag is not properly documented on OSM wiki.
Usage is not extremely low (3k uses) but is also not high.
I would recommend to decline supporting this tag.
For highways and rivers, I understand your opinion, but, for streams, which are modelled as a simple way, with trees directly along its sides, the problem is that there is no distance between the row and the stream, so one can't model it as a natural=tree_row way along the stream, as the distance between them will be inherently false. One could draw the row directly on the stream, but that would still not represent the reality.
I think that we here hit the limits of the modelling scheme of OSM: by representing, as zero-width ways, non zero-width linear features, modelling features along them will be, IMO, inherently faulted: either we draw the last along the first, and the distance between them is false, as it is zero in reality, or we draw both along the same path, and they are modelled as confounded whereas they are not in reality.
tree_lined=* is a compromise between the two, making the trees an attribute of the linear feature, hence circumventing the question about the distance. One could argue that trees along highways are directly on the edge of pavement, and that this problem also applies to highways; that may be why this tag is also applied to highways. This possibility may not be the best, but, IMO, it is the less bad, and other users of this tag may reason the same way.
the problem is that there is no distance between the row and the stream
I don't understand this argument. OSM coordinates with 7 decimal places allow resolutions down to few centimeters
One could draw the row directly on the stream
why?
2018-01-21 23:20 GMT+01:00 Mateusz Konieczny notifications@github.com:
I also think that such feature should be mapped at least as
natural=tree_row, mapping tree row and waterway on a single object seems to
be a poor idea.
actually what Penegal first wrote about was not mapping the tree row and
the waterway on the same way, but stating on the waterway that it is lined
by trees. Might seem nitpicking, but it is important to be precise in the
wording (IMHO). I believe this concept is working in theory, but I agree it
is in concurrence with natural=tree_row which is used 100+ times more, so
not rendering this variant (implicit trees) until it gains some traction
seems ok.
In addition tag is not properly documented on OSM wiki. ... I would
recommend to decline supporting this tag
+1
Therefore I close this issue, but discussion might continue. It just means that currently we don't see the need to do it as there are more accurate ways of showing tree lines already.
In addition tag is not properly documented on OSM wiki.
Good point here; I'll try to correct that.
the problem is that there is no distance between the row and the stream
I don't understand this argument. OSM coordinates with 7 decimal places allow resolutions down to few centimeters
And how would you count the distance? From the bank to the tree's bark, which is practically zero, as it grows on it? From the trunk's center to the stream's one? One problem, when making these features separate, is how to precisely measure the distance between them; whatever method and distance you use, it will always be questionnable. Besides, as you increase precision, the amount of work and data will skyrocket, which does not seem acceptable. This aspect problem vanishes when you keep the features single with tree_lined=*.
P.-S.聽:聽hope this answer is not too OT; I'm unsure about where the limit is.
There is no need to "count" any distance. You place the stream nodes to the middle of the stream, and the tree nodes to where the trees are.
Just for info: Rendering tree lined roads in a distinct form but not showing the individual trees has been fairly common in many historic maps, especially in maps from times were planted trees along roads was standard for higher quality built roads in large parts of central Europe (usually until about the mid 20th century). See for example
http://geoportal.geodaten.niedersachsen.de/legende/wms_pl25.gif
How to map tree lined roads and how to render them are two completely different questions of course.
@Penegal Whilst I'd agree with @matkoniecz that it's not going to be straightforward to implement, it's far from impossible. Technically there are a couple of different ways you could do it:
One might be to reuse the "bridge" code in the style to create a rendering for "tree-lined" streams. I recently did something similar in another style (https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT) to handle roads, railways and waterways on embankments.
Another might be to use lua to split the waterways you're interested in at the lua stage into "non-tree-lined" and "tree-lined", and have different pseudo-tags-values for each (duplicate the existing style code and change the rendering). This is something that OSM Carto doesn't do in lua currently, It does make the style changes easier but would require a database reload to see everything, and may be inappropriate here for that reason. That's how https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT handles roads with sidewalks and verges.
If you want to have a go and get stuck drop me a message (or ask a help question about it or something).
2018-01-22 15:39 GMT+01:00 Christoph Hormann notifications@github.com:
Just for info: Rendering tree lined roads in a distinct form but not
showing the individual trees has been fairly common in many historic maps,
especially in maps from times were planted trees along roads was standard
for higher quality built roads in large parts of central Europe (usually
until about the mid 20th century). See for examplehttp://geoportal.geodaten.niedersachsen.de/legende/wms_pl25.gif
How to map tree lined roads and how to render them are two completely
different questions of course.
+1. From you knowledge, in those historic "Messtischbl盲ttern" (your link),
would such a point (simple case) or tree icon (excellent case) symbolize an
actual tree, or would it have to be read as just a symbolic signature?
Because I would expect it to represent actual trees.
+1. From you knowledge, in those historic "Messtischbl盲ttern" (your link), would such a point (simple case) or tree icon (excellent case) symbolize an actual tree, or would it have to be read as just a symbolic signature? Because I would expect it to represent actual trees.
I don't think that is the case for tree lined roads. Keep in mind there were no aerial images at that time, these maps were fully surveyed on the ground. I don't think individual trees were mapped at that time unless they were individually significant.
And i have never seen an irregularity in this kind of signature on such a map (i.e. a missing tree or a change in tree spacing) - even for smaller or older roads were this was not uncommon.
I would rather use natural=tree_row in these cases.
Just for info: Rendering tree lined roads in a distinct form but not showing the individual trees has been fairly common in many historic maps, especially in maps from times were planted trees along roads was standard for higher quality built roads in large parts of central Europe (usually until about the mid 20th century). See for example
http://geoportal.geodaten.niedersachsen.de/legende/wms_pl25.gif
How to map tree lined roads and how to render them are two completely different questions of course.
Side note: What an absolutely lovely hand drawn legend! ;)
Most helpful comment
I would not expect that it is possible to get reasonable rendering for that as distance of tree line from feature may strongly vary.
I also think that such feature should be mapped at least as natural=tree_row, mapping tree row and waterway on a single object seems to be a poor idea.
In addition tag is not properly documented on OSM wiki.
Usage is not extremely low (3k uses) but is also not high.
I would recommend to decline supporting this tag.