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