[Tagging] Estimated values for height

Nick Bolten nbolten at gmail.com
Tue Nov 20 22:41:31 UTC 2018


> on the object it-self height=3 group all objet with this source, and put
on the changeset :
source=survey source:height=estimated or eyeball

Yes, but this makes it far harder for a standard mapper to do QA - they now
need to create the convoluted set of requests and filters I mentioned in
the previous post. As a result, it raises the bar for participation to
someone who's good at web requests and data processing. An alternative is
for the OSM website API to support deeper / simultaneous queries for
features + changesets at once.

> let's assume that Bart is naive enough to believe that he has such
accuracy
On the object it-self height=3.465839124

This is a good assumption. The average person is not deeply familiar with
error estimates nor significant figures (if there's any conversations going
on), and I doubt you could tell me the correct number of digits to use -
after all, you don't know the exact imagery that Bart used, nor at what
zoom level. But the tool, i.e. the OSM contribution UX, tells Bart the
distance is 3.465839124.

> group all objet with this source, and put on the changeset : source=imagery
imagery_used=the_name_of_this_aerial_imagery but Bart being an osm
contributor, we can hope he doesn't be so stupid and so he can round his
own measure.

Calling the user stupid usually points to a bad UX, and that is certainly
the case here. The barriers to entry are high enough already. What level of
intimacy with error estimates and the internal workings and standards of
OSM should be required to create an initial estimate of the width of a
road? Let's say the source imagery is Mapbox Satellite, the location is in
Montreal, and zoom level is 18. Quick: how many places after the decimal
should be used? I certainly can't answer that without knowing the
meters:pixel ratio at that zoom level, the relative ppi accuracy of someone
clicking on their particular computer, and their ability to discern street
from non-street features from satellite imagery.

In reality, it's just a guess with many potential sources of error and the
accuracy is also being guessed at.

> it's currently impossible given the lack of quality tags on the changeset (we
still see too often changeset without even a source tag).
but if the contributors added them, we could easily analyze them, a bit like
geocropping to determine the poi that probably need to be confirmed.

Define "we", because this sounds like a substantial amount of GIS, OSM, and
data processing (likely programmatic) just to know whether a piece of data
was guessed at.

> but if tags are missing for this analysis, please don't try to solve this
by encouraging source tags on objects that are in no way the
guarantor of the current source of the object.

Why not? It's far easier to investigate and fix as a tag on the feature
than these elaborate (and therefore nearly entirely unused) schemes using
changeset tags.

> Neither do you invent a new tag to describe exactly the same thing as
what exists like
source:<tagname>=thesource

Except source:tagname=whatever is ambiguous and poorly documented for this
situation. Any of the fictional people I mentioned could put down
source:width=satellite or laser, etc. and be perfectly accurate - but
difficult to parse by everyone else.

On Tue, Nov 13, 2018, 2:55 PM marc marc <marc_marc_irc at hotmail.com wrote:

> Le 13. 11. 18 à 23:30, Nick Bolten a écrit :
> > My primary concern is in being able to distinguish estimated values that
> > are "guesstimates" of different types from something where someone took
> > the effort to use something more precise. Examples:
> >
> > (1) Jessica is walking along the street and is prompted to estimate a
> > nearby building's height in meters. They eyeball it and says it's about
> > 3 meters wide and we record it. What's the best way to make a note that
> > this was acquired through visual inspection so that it can be 'flagged'
> > in later efforts for measurement with a ruler or laser or offset
> > satellite imagery, etc?
>
> on the object it-self height=3
> group all objet with this source, and put on the changeset :
> source=survey source:height=estimated or eyeball
>
> > (2) Bartholomew is armchair mapping an area they are personally familiar
> > with and wants to estimate the width using JOSM's built-in distance
> > calculation tool. The tool tells them that it is 3.465839124 meters
> > wide, and they write that down in the tag. Of course, their error range
> > probably only justifies writing down "3.7 meters" at best, but we can't
> > ask Bart to know that for sure. How do we know that Bart's width
> > estimate is only from aerial imagery + a tool, and temper expectations?
>
> let's assume that Bart is naive enough to believe that he has such accuracy
> On the object it-self height=3.465839124
> group all objet with this source, and put on the changeset :
> source=imagery imagery_used=the_name_of_this_aerial_imagery
> but Bart being an osm contributor, we can hope he doesn't be so stupid
> and so he can round his own measure.
> one day editors may be more advanced and will automatically
> add a changeset tag like imagery_used:resolution=10cm/pixel
> one day also one can expect that editors + evolved automatically shows
> next to each tag the changeset and the source of the changes and who
> last modified it
>
> > (3) Katie is high tech and uses fancy laser and computer vision to get
> > centimeter-precision readings. How does she know which places are in
> > need of more accurate measurements, and how do we know her measurements
> > should be given the appropriating weighting vs. guessed numbers? i.e.,
> > how do we know which height/width/etc values need accuracy improvements?
>
> it's currently impossible given the lack of quality tags on the
> changeset (we still see too often changeset without even a source tag).
> but if the contributors added them, we could easily analyze them, a bit
> like geocropping to determine the poi that probably need to be confirmed.
> but if tags are missing for this analysis, please don't try to solve
> this by encouraging source tags on objects that are in no way the
> guarantor of the current source of the object. Neither do you invent
> a new tag to describe exactly the same thing as what exists like
> source:<tagname>=thesource
>
> Regards,
> Marc
> _______________________________________________
> 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/20181120/a57e676d/attachment-0001.html>


More information about the Tagging mailing list