Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autofill "operator:wikidata" using the Operator field #5484

Closed
BjornRasmussen opened this issue Nov 12, 2018 · 7 comments · Fixed by #8305
Closed

Autofill "operator:wikidata" using the Operator field #5484

BjornRasmussen opened this issue Nov 12, 2018 · 7 comments · Fixed by #8305

Comments

@BjornRasmussen
Copy link
Contributor

Currently, when typing in an operator for an object in iD, all I can enter is plain text. Could a wikidata search be used to find the operator that the contributor is looking for and suggest it to them?
For example, in the image below, I am editing a bus stop and trying to add the operator. Instead of just including the text "Chapel Hill Transit", iD could autofill a tag, "operator:wikidata"="Q5073024".
image
I think that something like this could be very useful if implemented.

Also, for anyone super interested in the image, it is of this location.

@1ec5
Copy link
Collaborator

1ec5 commented Nov 12, 2018

The Operator field’s suggestions currently come from taginfo based on existing tag usage. The Wikipedia field suggests article titles from Wikipedia, which makes it straightforward to autofill a Wikidata QID in that case.

To autofill operator:wikidata, we’d need to switch the Operator field over to suggesting Wikipedia article titles. So autofilling operator:wikidata would come at the possible expense of helpful suggestions. Whereas taginfo’s suggestions for operator are all valid (if irrelevant) values of operator, Wikipedia’s suggestions for wikipedia can be just about anything, and there isn’t a clean way to filter the suggestions down to just organizations using a single API call. Normally, operator is much less likely than wikipedia to contain the name of a notable organization, so we’d also need to retain the ability to enter a value other than one of the suggestions.

@Nakaner
Copy link

Nakaner commented Nov 12, 2018

Automatically adding operator:wikidata=* is an automated edit which has to be discussed on the Talk mailing list and documented according to the Automated Edits Code of Conduct.

There are local communities in OSM which don't have a consensus (i.e. don't agree with) on the automatic addion of *:wikidata=*. Please respect their decision.

@bhousel
Copy link
Member

bhousel commented Nov 12, 2018

Automatically adding operator:wikidata=* is an automated edit which has to be discussed on the Talk mailing list and documented according to the Automated Edits Code of Conduct.

@Nakaner - This is simply not true, and I'd appreciate it if you stop spreading such a nonsense view on what "Automated Edits" means. iD already will add wikidata tags automatically in some cases, and we will continue to automatically set tags for users where it makes sense. This is no different than other kinds of automatic tag assignment that all editor software must do sometimes.

@matkoniecz
Copy link
Contributor

matkoniecz commented Nov 12, 2018

@Nakaner What is your definition of "automated edit"? Because one appearing at https://wiki.openstreetmap.org/wiki/Automated_edits

Automated edits and semi-automated edits (sometimes called mechanical edits) are changes made to OpenStreetMap content with no or very limited human oversight

would apply only in case where adding operator:wikidata would happen without oversight of a human (and selecting whatever specific Wikipedia article matches counts as an oversight).

Whatever adding operator:wikidata is useful/desirable enough to implement a special interface is a separate issue.

@BjornRasmussen
Copy link
Contributor Author

I doubt that Wikidata has good enough coverage for this to work, and people might think that their operator value they entered is not valid if it didn't show up in the autofill dropdown, so I'll close this issue for now

@bhousel
Copy link
Member

bhousel commented May 4, 2019

I doubt that Wikidata has good enough coverage for this to work, and people might think that their operator value they entered is not valid if it didn't show up in the autofill dropdown, so I'll close this issue for now

Oh! don't close it yet... I was thinking of expanding name-suggestion-index to do operator:wikidata too. Random musings here. It already does such a good job with brand:wikidata.

The idea would be that instead of just expecting contributors to know all the operator operator:wikidata operator:wikipedia tags, they could pick them from a list, and get logos and stuff for assistance.

@bhousel bhousel reopened this May 4, 2019
@1ec5
Copy link
Collaborator

1ec5 commented May 4, 2019

osmlab/name-suggestion-index#2243 (comment) seems to be focused on operators of public transportation networks. But operator can be used on just about anything. If the intention is to autofill operator:wikidata on anything where operator can appear, then it would be simpler to draw the autocompletion suggestions from the Wikidata Query Service than to go through name-suggestion-index. After all, it would be quite unmanageable for name-suggestion-index to index all the school districts (for operators of schools), all the parks districts and cities (for operators of parks), all the healthcare companies (for operators of hospitals), etc. Unlike Wikidata, WQS can filter results down to certain classes of organizations for instance, but I’m not as sure about its suitability for autocompletion.

On the other hand, if this issue is strictly limited to public transportation presets, then yes, operator might be a small enough set that name-suggestion-index could be manageable. In that case, network and network:wikidata would also be just as useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants