[Tagging] Estimated values for height

Tue Nov 13 20:58:20 UTC 2018

I like the ideas using height:source or height:accuracy, but want to point
out that they could imply different things.

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).

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.

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.

tl;dr: I really like metric:source=*.

Best,

Nick

On Tue, Nov 13, 2018 at 8:37 AM Kevin Kenny <kevin.b.kenny at gmail.com> wrote:

> On Tue, Nov 13, 2018 at 10:09 AM Sergio Manzi <smz at smz.it> wrote:
>
>> Yeah, agreed. And I think in our context "*estimate*" should be more
>> taken as "*quesstimate*", i.e. "*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*" [1].
>>
>> Now... how do we tag this... "*thing*"?  :-)
>>
>> My personal idea is that it should be:
>>
>> *either*
>>
>> *measure*:accuracy=estimate (e.g.: height=10 +
>> "height:accuracy=estimate")
>>
>> *or*
>>
>> accuracy:*measure*=estimate (e.g.: height=10 +
>> "accuracy:height=estimate")
>>
>> *and*
>>
>> get rid of all the est_* tags (e.g.: est_height=10)
>>
>>
>  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.)
>
> 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: https://8thlnt.wordpress.com/). 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:
>
> - 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.
> - 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.
> - frame the tree with stadia marks in a transit and tape off the distance
> to the tree
> - (I've never done this!) Climb the tree and drop a weighted tape.
>
> 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.)
>
> 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.)
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181113/e9fbfe67/attachment.html>