> 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_...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
