What are wiki Q-Items (e.g. Q108) used for? Could they be used more?
As far as I know, they are used in iD to link the Wiki page documentation (P31) in your language (if present), also it uses the description in your language and P28 to show a picture.
They are also used in the OpenStreetMap-website to link the Wiki page documentation (P31) in your language (if present):
Do you know other uses?
I think they could be used more. They could be used in QA tools for instance.
For example, Q110 (building:architecture) has P22=Q108 (required key or tag=building). iD could check the Q-Item, and throw a warning if you add a building:architecture tag without a building tag.
Same for P33,P34,P35,P36. If an element has P33=Q8001 (applies to nodes=is not applicable) and you map it as a node, it could throw a warning.
If P6=Q5061 (status=deprecated) iD could throw a suggestion that the tag maybe shouldn’t be used and suggest instead the P17 (replaced by) value.
ecc.ecc.
Do you know if something similar has been proposed/discussed already?
EDIT:
I was looking for Q-Items, but I found out that they are called Data items in the Wiki, so I found this wiki page. I also found out someone made a similar proposal for JOSM. Also Osmose implemented an automatic geometry check in 2012 but removed it later:
“We already tried this in Osmose-QA back but it was a fail. We removed the control. It raises too many false positives.”
That is not really a good idea - as data items have no effective watchlisting or review it would result in anyone being able to edit widely used validator - which by many mappers is treated as instruction from OSM that should be obeyed.
It could be, at most, used to generate list of suggestions that would be reviewed and if accepted, added to QA tool.
Though in my experience quality of data there is quite poor and I would not use it in such way.
If someone is interested they can compare iD presets which already carry such eligibility info and compare it with what data items claim.
Note that iD distinguishes between freefloating nodes and nodes within ways. Are data items capable of such distinction?
(OSM Wiki infoboxes entries are not)
If someone wants they can compare iD deprecation suggestions with that.
But in my experience it is common that someone on wiki edits page to claim that something is deprecated despite not being deprecated. Given that watchlisting of data items is effectively broken, it is likely even worse there. It would get even worse if such changes would be instantly applied without review.
In general, there are already serious problems with people making dubious claim on wiki. Giving them direct write access to powerful QA software is a bad idea.
Some tool of the kind I proposed would work as “watchlist” in a way. People could notice something is wrong and fix the Wiki accordingly. Obviously people abusing the system would be punished as they already are with any other fraudulent activity.
I still think that a tool that creates such suggestions could be useful. I don’t think that people bad faith should be a major reason against this idea. This would give a value to the Data Items and could encourage more people to fix the Wiki, which is now edited by only few people.
The wiki itself also uses data items in a few places besides the infoboxes. For example, if you search for a key that doesn’t have documentation yet but does have a data item, the search results page generates an infobox based on the data item. If you try to access the key description page for an undocumented compound key, such as inscription:haw=*, the 404 message describes each part of the key.
In the wiki’s article namespace, we typically see something less clear-cut. Rather than vandalism, it’s usually an edit that’s plausible but needs broader discussion. Unfortunately, inexperienced mappers sometimes get the impression that changing the wording of the wiki will magically cause the database to change en masse. Much more experienced mappers sometimes suffer bouts of overconfidence as well. I myself sometimes get caught off-guard thinking something is uncontroversial when of course it’s controversial, because OSM.
I agree that this problem isn’t specific to data items, but it does compound with the problem of overzealous mapping for the QA tool. One potential mitigation is to keep data item–based validation checks separate from the usual checks, or in an entirely separate tool. Sophox can even help you spin up an ad hoc QA tool based on data items, with a level of effort akin to writing an Overpass query.
Specialized QA tools, such as this boundary tagging consistency validator, could use similar federated queries to expand coverage beyond the scenarios that they’re currently designed for. They aren’t as tightly integrated with editors, so there’s an opportunity to frame the warnings so that mappers approach them with more nuance.
Q items are also parsed as part of the JOSM tag2link project.
That is then used in JOSM to provide links to web resources.
From a pure programmatic point, the wiki data items are easier to work with than the rendered HTML pages since you don’t have to worry about a regex being fine 99.9% of the time.
I also wrote a validator that used the Q items a few years ago.
