<div dir="ltr"><div dir="ltr">Mateusz Konieczny:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
<div>Value in from and in to are not necessarily the closest named object to<br></div><div dir="auto">terminal locations, therefore adding them has some value as deriving<br></div><div dir="auto">them automatically is not feasible.<br></div><div dir="auto"><br></div><div dir="auto">Even if deriving them automatically was possible then adding redundant<br></div><div dir="auto">tag is preferable if that discourages adding fake descriptive name tags</div></div></blockquote><div><br></div><div>True. Loads of people put descriptive elements in the name, because the name is what you see in applications. Telling people not to do that because <valid OSM reasons> will not work, because <valid usability reasons>.  What may work is supporting a better method. If we agree upon and document a better method, people have no valid reason anymore to (ab)use the name tag.</div><div><br></div><div>If the data in some of the tags can be derived from the start and end location, and if start and end location can be determined by the application software, and if proper names are available for those locations, that could be the better method, but I am afraid this is not yet the case.<br>Many applications calculate the length of a route and display that for the user. That is why I do not use the distance tag for route relations. Still, many route names contain the distance, e.g. because there are two city trails with the same name, only one has an extra loop adding a few kilometers. </div><div><br></div><div>From and to I do use for many routes I maintain, and after a trial period I have started to remove these data elements from the names. Most of the from and to location names are assigned by the operator and cannot be determined easily and with certainty from the geolocation. </div></div></div>