> Better rendering of tree_row on OSM Carto Please go to http://github.com/gravitystorm/openstreetmap-carto/issues/new and explain the problems with the current rendering, then we can discuss how to fix it. On Tue, Feb 12, 2019 at 6:43 PM Peter Elderson <pelder...@gmail.com> wrote:
> Netherlands have very extensive use of tree rows. Lets take the roads. > Roads in our polders are almost always lined with tree rows, exept for the > many crossings, roundabouts, tunnels, bridges etcetera. These roads stretch > many kilometers. The lining is often not singular, but lines each direction > separately. Most of the time there are separate bicycle lanes, often lined > with tree rows. For water drainage there are drainage ditches on both > sifes, again often lined with tree rows. > > A motorway will often have double or triple tree rows on both sides and in > the middle. On both sides of the motorway there usually is a parallel road, > again lined with trees. > > Areas are often lined with trees. Even wood areas are often lined with > tree rows. Water areas and waterways have tree rows most of the time. > > In cities, you will find rows of trees almost everywhere, not just lining > roads. > > You can't map the individual trees. It's just too much and it changes > faster than you can enter them. So most of the time, they are not mapped at > all, for lack of properly rendering tree_row tag. The current fat green > band rendering on Carto is worse than no rendering at all. Double and > triple tree_rows are now often mapped as pieces of forest, and because of > the regularity of appearance, orchards. > > For long single lane roads with single tree rows on each side, no bicycle > and pedestrian ways on the sides and not too many interruptions, a > tree-lined tag could be used. Most of the time, you would have to cut the > road into many short pieces just to tag the tree lining variations correct. > I'm not in favor of that. > > IMO the way to go is: > - Better rendering of tree_row on OSM Carto (not our concern, but...) > - Then, and only then, decent tagging of tree rows is an option. > > Tagging for the renderer? Well. Rendering is about the only use case for > tagging tree rows, so how could it be anything else? > > Vr gr Peter Elderson > > > Op di 12 feb. 2019 om 06:01 schreef Mark Wagner <mark+...@carnildo.com>: > >> On Mon, 11 Feb 2019 15:55:50 +0200 >> Tomas Straupis <tomasstrau...@gmail.com> wrote: >> >> > Two things to add: >> > 1. At least in Lithuania cartographic (topographic) "tree row" is >> > defined as "a row of trees groing alongside a road or railway". That >> > is random trees somewhere in a field do not become a "tree row" even >> > if they are in a row. >> > 2. If (1) is true in other countries, maybe "tree_row" should be an >> > attribute of a road/railroad? Say >> > highway=residential+tree_row=left|right|both. This way it would be >> > much more convenient to create cartographically correct maps in 25k >> > 50k scales without resorting to complex generalisation operations like >> > displacement? >> > >> >> Tree rows in the United States are usually planted as windbreaks. As >> such, they're usually either perpendicular to the prevailing winds, or >> run along the edge of someone's property line. Occasionally they're >> planted for shade purposes, in which case they run east-west. Tree >> rows planted parallel to a road are uncommon. >> >> "tree_row" as an attribute of a road might make sense, in the >> same way as "sidewalk" tags do. As a replacement for >> "natural=tree_row", it excludes a lot of the existing uses. >> >> -- >> Mark >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging