<div dir="ltr">I like the ideas using height:source or height:accuracy, but want to point out that they could imply different things.<div><br></div><div>I think we're mostly talking about situations where we're eyeballing some measurement - like the height of a building or the width of something (e.g. I'd really like something like width=3 and width:source=eyeballed for a sidewalk). For this, I'm using height:source because, to me, 'accuracy' is about knowing the error range, which is something we probably can't reasonably get from users. I have no idea what my personal accuracy would be - maybe I'm off by 1 meter and you're off by 0.5, but I wouldn't know off-hand. But I do know what 'eyeballing' it means (or some similar common speech term).</div><div><br></div><div>Measurement accuracy seems like a tag to use when you have a real accuracy estimate to write down, like when using surveyor's tools and maybe even multiple measurements from which to derive statistics, and would hopefully have some real mathematical meaning, like a += a 95% confidence interval according to company Z in the same units as the measurement.</div><div><br></div><div>Finally, I really like using metric:source for QA purposes, as it's much easier to look up (en masse) tags associated with nodes/ways/relations than it is to look up changeset info. Let's take an example where I want to find all 'eyeballed' building heights, because I have a great new surveying tool to get more accurate numbers. If the source info for the width is only in changesets, I need to: (1) retrieve all buildings in the AOI, (2) Request the full changeset histories from OSM for each one, (3) Filter to the most recent changeset that changed the height value, (4) check its source tag, cross my fingers that they knew the right values to add. In contrast, if one used width:source, all I'd need to do is run a single OverPass Turbo query (one API call) or download buildings and check their tags. Both of these options are mostly data-equivalent (assuming mappers remember to use the right source=* tag on changsets), but the changeset-based one restricts who can QA the data to programmers. The changeset-based one would also be amenable to on-the-ground tasking apps like StreetComplete.</div><div><br></div><div>tl;dr: I really like metric:source=*.</div><div><br></div><div>Best,</div><div><br></div><div>Nick</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 13, 2018 at 8:37 AM Kevin Kenny <<a href="mailto:kevin.b.kenny@gmail.com">kevin.b.kenny@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 13, 2018 at 10:09 AM Sergio Manzi <<a href="mailto:smz@smz.it" target="_blank">smz@smz.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p>Yeah, agreed. And I think in our context "<i>estimate</i>" should
      be more taken as "<i>quesstimate</i>", i.e. "<i>a first rough
        approximation pending a more accurate estimate, or it may be an
        educated guess at something for which no better information will
        become available</i>" [1].</p>
    <p>Now... how do we tag this... "<i>thing</i>"?  :-)</p>
    <p>My personal idea is that it should be:</p>
    <p> <b>either</b></p>
    <blockquote>
      <p><tt><i>measure</i>:accuracy=estimate (e.g.: height=10 +
          "height:accuracy=estimate")</tt></p>
    </blockquote>
    <p><b>or</b></p>
    <blockquote>
      <p><tt>accuracy:<i>measure</i>=estimate (e.g.: </tt><tt><tt>height=10
            + </tt>"accuracy:height=estimate")</tt><br>
      </p>
    </blockquote>
    <p><b>and</b></p>
    <blockquote>
      <p>get rid of all the est_* tags (e.g.: est_height=10)<br></p></blockquote></div></blockquote><div><br></div><div> I'd mostly agree. When this gets wikified, let's make it clear, though, that the ruleis "map what you know" rather than "don't map until you have all the detail." (Too many discussions here come up with schemes where mappers have to do additional research beyond what they can see in the field before they can map in a conformant way. We don't want that.)<br><br></div><div>Now, as to the height of a tree. I've been tempted to map a few locally spectacular examples, particularly of _Tsuga canadensis_ (and decided to refrain: <a href="https://8thlnt.wordpress.com/" target="_blank">https://8thlnt.wordpress.com/</a>). I had been thinking in terms of just putting in the number of metres - but if I were to map such a thing, ought I to distinguish:<br><br></div><div>- step back and simply visually estimate how many copies of my six-foot hiking partner it would take to make the height of the tree.<br></div><div>- pace back a known distance (with the usual inaccuracy of pacing off a distance) and use a clinometer to measure the angle subtended by the tree.<br></div><div>- frame the tree with stadia marks in a transit and tape off the distance to the tree<br></div><div>- (I've never done this!) Climb the tree and drop a weighted tape.<br><br></div><div>The accuracy of these techniques varies by 4-5 orders of magnitude. The simple visual method is probably going to have a standard error of a few metres on a big tree (because I'm reasonably skilled at such things), which can be reduced to tens of cm with the clinometer, a few cm with a transit and tape, and sub-cm using direct measurement with a tape.  With the specific example of a tree, nobody cares about a few cm, because trees flex, and grow, and measurements aren't going to be repeatable to that level (With a tower, it might become significant.) <br><br></div><div>At that point, for a tree, the only significant difference becomes "are measurement errors of the same order of magnitude as the natural variation in the measured quantity?" With a visual estimate, the answer is most likely "no", with a clinometer and pace count, it becomes "yes," and everything more sophisticated is mostly "wasted precision". So for a tree, "measured" and "estimated" really are the only two categories that matter. (And perhaps the date of the measurement. Trees grow, and the big ones all eventually take storm damage and die back.)<br></div><div><br></div></div></div></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>