Proposal talk:Second opinion correctness survey

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Proposed features/Second opinion correctness survey here:

See also mailing list and forum posts about this proposal. Primary channel is this discussion page

Distinguish between data and metadata

What about distinguishing between data and metadata with a key like : _survey rather than survey? So the survey key could be kept for data. --FrViPofm 09:03, 25 September 2010 (BST)

Bad idea

The username is already part of the API transactions (and history, dumps, etc). I've never seen a proposal asking to put the username a second time in a tag. Better create something like "last_surveyed=date" if you like. But since the element itself is not modified, it could be even something to put as an additional property in the API itself. Could be proposed for API0.7 --Pieren 12:45, 25 September 2010 (BST)

I agree with Pieren. All information is already in the db. The proposal also doesn't specify a method to express, which part has been verified. Is the verfication for a single part or all tags, is it for the geometry / topology? On the german ML there were suggestions how to overcome these problems with source:amenity=xy (and similar). Still I don't think this information should be tagged on the geometry, but should be added as changeset comment. -- Dieterdreist 12:18, 27 September 2010 (BST)

Sketch of putting that into the API

I think, it's a good idea to establish some kind of quality assurance which allows users to state the correctness of map elements added by others. But I'm not sure, whether it's a good idea to solve this issue simply by using ordinary tags.

There are several reasons for that opinion:

  • Tags can be easyly changed by everyone else. As it's often the case with source-Tag deleted by other users this mechanism also should not rely on correct usage. This proposal can be misused by (fictional) user "bad-guy" by adding other usernames to the tag, too. With that in mind it's not possible to reliably check for the correctness as mentioned as a target of this proposal.
  • What's correct? What to do, if I don't know the correctness of every attribute? I know a church exists, I can check the name and state it's correctness - but I have no idea what's the correct denomination, service_times or height. With this proposal I can say, I know the correctness of most of these tags and add my name - what's not entirely correct; or I have to not add my name - and that's less quality assurance as it could be.

Most of the time I think, there are single tags at an object being wrong - or the position being incorrect. If I know of that, I can fix it or add a fixme or note tag - and propably that's not more work than adding my name to "this is correct". But one thing is correct - and should be solved slightly different: We need a mechanism to "touch" an object; to "change" a tag to the same as before.

Short sketch of this idea:

  • Let's assume the api allowes to "change" a tag to the same value as before with an additional flag "yes, that's correct".
  • The usage in (as an example) JOSM could be:
    • I want to add access-tags to a street already mapped in OSM.
    • select the street
    • add the new tags in the JOSM tag editor
    • I see, there are other tags as well - name="main street", highway="secondary"
    • next to each tag there is a small checkbox. If I know the tag is correct, I can check this saying "yes, I know the name is correct.
    • My changeset includes the new stuff I added, the changes I made and the statements about correctness of others.

--Jongleur 09:28, 26 September 2010 (BST)

Yet another meta source tagging idea

A lot of people use the source tag for this purpose. e.g. something like source=GPS survey on 03/10/2010 . But increasingly people are using Changeset comments or other changeset tags instead. It seems unlikely to me that you'll gain wide adoption for a brand new idea along these lines. This kind of idea is not just another tag proposal, but an idea for something mappers should do when they're tagging all their edits.

But let's not forget that for beginners (that is, most mappers on the long tail) these ideas add an extra layer of complexity which they should not need to bother with. Indeed I often don't bother with source tagging myself, because it would slow me down. If I were to manipulate more tags across all objects I edit, that would take extra time which I could be spending adding more data. There's some parallels with the idea of 'reviewed' tags on imports. See Talk:Import/Guidelines#reviewed tag. It becomes just a waste of time, and confusing for new users.

Well that's my first thoughts on the idea anyway. It might be great if a large enough proportion of the mapping community adopted it in a consistent way. I'd suggest that the only way you have a hope of making that happen, would be to create a rendering showing the tag (and different colours for dates over time perhaps, like OSM Mapper)

-- Harry Wood 12:41, 3 October 2010 (BST)

Avoid editing original object - use a relation until editors/API facilitate it?

Ideally, this should be something in the API - a mechanism such that a changeset could reference the existing version of an object and say that this was verified as correct.

Additional tags could then be used on the changeset like:

  • date:survey=yyyy-mm-dd [unless there's already another way to tag this?]
  • verified=yes [I verified all tags on every object mentioned in this changeset (except those with verified:x=no)]
  • verified:name=yes [I have verified the name of all objects in this relation]
  • verified:geometry=no [Didn't specifically check that the entire shape/position of every object was correct]
  • etc.


Until or unless the API supports referencing the existing version of an object as "all correct, nothing needed changing", I'd think it a bad idea to modify an object in order to add tags simply to state that the existing tags on the object are correct - anyone "watching" an area would see a large number of objects changing, and it would make the task of identifying and verifying NEW changes much more difficult.

However, there is an existing mechanism that could be leveraged to reference an object without modifying it - a relation.


So when verifying stuff, one could create a relation e.g.

  • type=survey
  • date=yyyy-mm-dd (date of survey if it differs from date of changeset)
  • name=Checked by [name] on [date] (leverage existing UI where list of relations is displayed!)
  • verified[:...] - inherited from changeset. verified=yes assumed if there are no explicit verified tags either on the changeset or on the relation.

For members with a blank role (or an explicit 'all'), this is stating that all specified tags on the object have been corrected, or verified as correct at time of the changeset. For members where only certain fields have been verified, the field name could be used as the role, or 'geometry' [or other standardised term?] if the shape/position was verified rather than [or in addition to] certain tags.

Whether members which are already modified by the changeset are also added to the relation might be a matter of personal preference.


If the API and/or editors later allow for an object to be referenced [in a different way] by a changeset without modifying it, and/or the data structure representing a changeset is enhanced with a relation-like 'role', this separate relation could become deprecated, and potentially existing relations used in the manner described could be merged into the changeset data structure.

Worth kicking this idea around a bit more to come up with something workable?

banoffee 13:17, 11 August 2011 (BST)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Second_opinion_correctness_survey&oldid=2517389"